作为程序员,该如何去挽救一个失败的项目?

一个很烂的项目，发现以下问题：

      1. 一半的bean用spring管理，另一半的bean自己new或者用单例模式，spring的包扫描配错了，但两年时间一直没人改过来

2.到处都是静态类、静态方法，没法扩展

3.在低基数、低频率的搜索上写优化算法，算法和业务逻辑搅在一起，没有分开为2个层面

4.业务配置文件过于复杂，过度设计，居然是事件模式解析

5.自己写了个Dao，自己手动管理事务，到处拼sql，六七十个字段的表，每个操作都重复拼

6.4000行的大jsp、大类、800行的大方法、多达17个参数的方法，喜欢写万能函数

7.不写注释、不写文档

8.log4j和logbak混用，各占一半

9.混杂的代码风格，花括号行尾、换行都有，缩进用tab、2空格、4空格、8空格，紧凑风格和松散风格都有

10.一些作者喜欢用反射调代码，没办法用ide跟踪

11.很多作者不用开源工具包，喜欢自己搞一套，有炫技嫌疑，实际上搞得很烂

12.分包分得一团糟，既想按照功能分，又想按照业务分，没有把握好，稀里糊涂的

13.方法、变量命名词不达意，经常在getXXX、isXXX的方法里改传入参数，但又反回值，从命名就能看出作者词汇量狭窄、思维局限

14.对spring、spring mvc了解和利用严重不够，框架支持得很好的功能，非要自己写

15.pom依赖关系一团糟，各种重复引包、重复依赖，httpclient竟然多达4个版本

16.大片的被注掉的代码留在项目里，到处都是，许多废弃的类和废弃的配置文件没有删掉

17.每个作者都喜欢自己搞一套，缺乏共识，各自为战，各种约定、各玩各的

18.该打日志的地方没有打，导致一些工单成了无头案，有些地方，又重复打日志，啰里啰嗦

19.到处都是HashMap，而不用java bean；1个HttpServletRequest调了五六层方法；自己手工拼json字符串；拼email的html body，不用模板

20.页面还是jsp，jsp里写了大量的业务逻辑，甚至通过httpclient去抓别的项目，抓回来内容嵌在当前页面里

21.到处都是main方法，不用单元测试

22.代码重复度很高，一段逻辑，到处复制粘贴

23.数据库表设计很烂，导致不好查（比如用逗号分隔的串），较老得表甚至毫无注释（生产环境）

24.整个团队都没有代码质量追求，习惯了烂代码

这个项目，是该公司交易系统的核心，每周大概4次发布，迭代速度很高。
往里面加逻辑异常困难、很容易出问题，开发和QA都心力交瘁，新逻辑都是hack进去的，会加重代码腐烂。

若要重构，可能要同时维护2个版本，而且重构风险很大，一旦出事，将影响TL的前途。

如何摆脱这个困境？

1、程序员：“用心阁”

你应该得到足够的职位或授权，建立共识，你的观察和意见是否能够得到领导和团队成员的认可？如果没有共识，或者无法建立共识，那么要么忍，要么滚。

2、 程序员“fantini,码农”

理智的做法： 辞职。
不理智的做法： 等到改不动再辞职。

3、程序员：“refuseBT”

见困难就跑的，还真不如代码写差点迎难而上的。作为一个新人，可以找时机提方案，在领导的允许范围内主动承担改进任务。你们领导也会一定程度为你提供资源和时间做这件事情。

首先这种事情必须从上往下推，甭说你TL了，TL上层的上层（我们公司是COO和CTO直接支持）都得支持才行。否则你想一个人干就是稳死。而且肯定是先把你干掉。

然后，优化至少得是照着一年去做计划。最少最少。否则根本没有任何可行性。而且之前一定要有非常详细的策略推演，包括先做哪个模块后做哪个模块之类。不一定要立刻动手，但至少得验证可行性，而且的有和你现存新项目的安排一起进行的可行性（这也是为什么必须要有高层支持）。

最后就是所有具体执行这件事情的人要给力。可行的方式是上层追踪单元测试的覆盖率等等参数，同时对员工提供提高代码质量的培训（SOLID和设计方法），然后把这个和员工的成绩挂钩。

当然了，最后的最后是你的员工得是有心思干这种事情的人。否则离职率太高的话这就是谁也救不了了。

 

几点建议：

1.  策略一：

 

你要找公司的相关部门，如过程管理部，质量管理部，或项目管理办公室，得到他们的支持，建立软件开发过程，如：

1. 需求文档及评审
2. 设计文档及评审
3. 代码评审
4. 单元测试

还可以找一些软件系统来帮助这些过程的实施，如Bug跟踪，代码评审，代码静态分析。

 

2、策略二：

1．和leader沟通，需要他支持并承担可能重构失败带来的责任
如果leader支持的话。

2.写分析报告，指出存在的问题和风险，以及带来的维护成本，汇报给公司，ppt会议最佳，让领导知晓并观察态度
如果公司觉得紧张的话。

3.给出重构计划与好处、风险
如果公司支持的话，

4.开工，可以循序渐进地迭代，也可以大刀阔斧，最好先补测试用例，最好两个版本分开

5.总结，告知本次重构的巨大工作量，以及为百年基业带来的好处！

6.培训，软件开发规范，如果所在部门话语权不足，就内部培训，邀请兄弟部门

总之，不要单以技术热情来操作此事！！！

公司不认可，就说明代码还没有烂到他们觉得做手术的时候！！！就说明重构的市场价值不大！！！

公司不发话就别动！

 

如果公司的负责人有能力并且也有意愿来解决这些问题，建议好好跟着他干，做好执行，理解的要执行，不理解的也要执行。这是非常锻炼自身能力，提高经验值的事情。越乱越好，能够把烂摊子理顺，是能力的重要体现。不要因为眼前的这些问题而感到挫折，或者不爽，进而影响工作效率。尽量把事情做得更好。多大一个空格，把括号对齐也是改善。当然，跟烂摊子死扣也仅仅是修炼的一种方式。也可以有别的方式，辞职，换别的不同的公司也可以是种选择。

最后转个小故事：“在高盛期间，一次复杂的重组项目让他真正学习到了东西。当时在国内投资界名噪一时的广东粤海集团重组，高盛足足操作了两年，中间涉及到100多家债权银行，400多家公司，刘每天工作都到凌晨两三点，两年的项目感觉做了四年。但最终完成后，刘也对企业的管理、经营、执行几乎所有流程都都全面了解，“做完这个项目，基本上再做任何项目都觉得容易了。

 

作为程序员，我们该如何去挽救一个失败的项目？如何把难题变成奖品！

文章整理于“知乎”