三年项目复盘

　　之前给公司投的稿，先贴下原文~

　　

　　这是第几个失败的项目了？似乎数不清。

　　“那项目先暂停吧，会议结束。”实施组长这么说道，脸上的黑眼圈似乎更重了。

　　为什么项目总是或多或少的失败？工作已3年多，似乎从未做出过很成功的项目……

　　第一个项目是PMS2.0统推，那时现场提需求给问题处理组，再经过设计、开发、测试、上线；些许功能改动就需要2个月才能反馈给用户。但开发工作也并不轻松，各种线上bug排查、安全代码整改、领导临时加需求...都使人非常疲惫，听说2.0在用户口中的反馈并不好。

　　过慢的需求反应，离真实需求隔了太多层转换，是一种失败。

　　第二个项目是2.0的福建自建，开发、设计、实施、用户都在一个群里，我可以直接听到用户的声音，有专门的仿真环境，开发完就发包给现场，实施演示给用户看，有什么反馈可以立即更改。这样开发出的功能让用户很满意，在群里给予了肯定。

　　但坏处也随之而来，没经过管控组过滤的需求太多，代码被反复更改，需求越来越急，很多时候为了功能实现，只能堆代码实现。这样越到后面，功能需要修改的代价也就越大。

　　为了实现需求而忽略代码质量，导致修改代码的代价越来越大，是一种失败。

　　之后因为一些原因，我们不再做2.0；我被分配去接手华中电能质量，这是个我很少接收到用户反馈的项目；我不知道用户关心什么功能，不知道重点实现哪一块功能。只能根据设计文档去把未完成的功能都实现一遍。做到一定程度后，我又被安排去做别的事了；结果并不出意外，这个项目现在仍在进行中。

　　不断更换人员、项目没有主要目标导致让项目做了很久，是一种失败。

　　再之后便是今年5月的河北五通了，因为软件出错让用户不放心，最后让项目失败。也让我看到很多人失望的模样，真的让人很难受。

　　没有仿真环境，让未经过大量测试的代码上线，是一种失败。

　　从代码角度而言，所有的项目我们似乎都已经做得足够；消除重复代码，低耦合，尽可能提高性能。但项目却有各种各样的“失败”。

　　想了很久，我想我找到了一些原因。如果我一直只关注开发，那就开发不出好的代码。需求、设计、开发、测试、部署、上线。只有每一步都做的尽可能的好，才可能交出一个及格的软件。

　　开发应当在第一次需求会议时一起参加，设计上的不合理之处才能尽早提出，没有技术解决不了的问题，因为都可以换一条道路实现需求；需求设计时多花1分钟，就可以在开发时多节省10分钟甚至1小时。

　　在开发结束后，也并不就是结束了，测试与现场用户的反馈同样重要，重视他们的反馈可以让我们以后的代码越写越好。

　　项目上线后，常常关注日志，观察里面哪些功能是用户常用的，对常用功能进行性能优化，对偶现的报错在测试环境复现、修改。

　　代码开发结束，才是一个项目的起点。

　　五通之后，我们加入了PMS3.0的开发，这次，我们积极参与了需求与设计，设计模型、接口；选择好的数据结构比算法更重要。

　　那么这次会做出好的软件吗？不知道，但一定会比之前的都好。

 

　　然后，是我现在新的一些理解，3.0的开发也遵循了以前的老套路，一开始每一样都弄得很好。但总是会有突如其来的事件，干的好好的人被抽走了，突然间提了很多需求需要实现，测试组又突然加了几个人狂测，说项目还几天就要上线了……

　　这种情况下，很难保证代码如一开始想的那般，第一次对质量的妥协就是无数次了……但在忙完一段时间后，稍微的空闲时间能重构代码吗，重构完以前的功能都要重测一遍，未免代价太大了吧。

　　单元测试并不能解决这些，快速完成功能与代码质量之间必然有个平衡，就像算法中的空间换时间，时间换空间一样。我想，程序员就是这么一群人吧，不断地去想在有限的资源中怎么做好事情。