一个很烂的项目，发现以下问题：
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、策略一：
你要找公司的相关部门，如过程管理部，质量管理部，或项目管理办公室，得到他们的支持，建立软件开发过程，如：
✪ 需求文档及评审
✪ 设计文档及评审
✪ 代码评审
✪ 单元测试
还可以找一些软件系统来帮助这些过程的实施，如Bug跟踪，代码评审，代码静态分析。
2、策略二：
1．
和leader沟通，需要他支持并承担可能重构失败带来的责任如果leader支持的话。
2.
写分析报告，指出存在的问题和风险，以及带来的维护成本，汇报给公司，ppt会议最佳，让领导知晓并观察态度如果公司觉得紧张的话。
3.
给出重构计划与好处、风险如果公司支持的话，
4.
开工，可以循序渐进地迭代，也可以大刀阔斧，最好先补测试用例，最好两个版本分开
5.
总结，告知本次重构的巨大工作量，以及为百年基业带来的好处！
6.
培训，软件开发规范，如果所在部门话语权不足，就内部培训，邀请兄弟部门
总之，不要单以技术热情来操作此事！！！
公司不认可，就说明代码还没有烂到他们觉得做手术的时候！！！就说明重构的市场价值不大！！！
公司不发话就别动！
如果公司的负责人有能力并且也有意愿来解决这些问题，建议好好跟着他干，做好执行，理解的要执行，不理解的也要执行。
这是非常锻炼自身能力，提高经验值的事情。越乱越好，能够把烂摊子理顺，是能力的重要体现。
不要因为眼前的这些问题而感到挫折，或者不爽，进而影响工作效率。尽量把事情做得更好。
多大一个空格，把括号对齐也是改善。当然，跟烂摊子死扣也仅仅是修炼的一种方式。也可以有别的方式，辞职，换别的不同的公司也可以是种选择。
作为程序员，我们该如何去挽救一个失败的项目？如何把难题变成奖品！
不管你是转行也好，初学也罢，进阶也可，如果你想学编程，进阶程序员~
【值得关注】我的 编程学习交流俱乐部！【点击进入】
全栈程序员正在等你加入~
