帖子原文：http://www.zhihu.com/question/35007873
最近到1个新公司，接手一个很烂的项目，发现许多问题：
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.整个团队都没有代码质量追求，习惯了烂代码
开发平均薪资估计12k，居然写出这样的代码。
这个项目，是该公司交易系统的核心，每周大概4次发布，迭代速度很高。
往里面加逻辑异常困难、很容易出问题，开发和QA都心力交瘁，新逻辑都是hack进去的，会加重代码腐烂。
若要重构，可能要同时维护2个版本，而且重构风险很大，一旦出事，将影响TL的前途。
如何摆脱这个困境？
答：
作者：用心阁
链接：http://www.zhihu.com/question/35007873/answer/61031849
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
链接：http://www.zhihu.com/question/35007873/answer/61031849
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
首先，我同意上面的意见，三十六计走为上。
假设，你决定留下来处理这个烂摊子，提供以下建议供参考：
第一，你应该得到足够的职位或授权，一个程序员是没有足够的能力处理这个问题的。不在其位，不谋其政，如果你连项目经理或架构师都不是，连技术高层的认可都没有，那么还是走为上。
第二，建立共识，你的观察和意见是否能够得到领导和团队成员的认可？
在团队目前共识中，你列的这24个问题是项目最重要，最急迫的问题吗？是不是还有更重要的问题，你暂时还没有接触到？
你的问题描述客观吗？还是过分夸大，和带着情绪？很多词看起来都不是平心静气的说的。你看到的问题领导和团队成员看到了吗？他们认可吗？
解决这24个问题能提高你们的生产效率，或节省经费吗？能缩短问题解决的时间，提高客户满意度吗？能减少加班吗？
如果你这24个问题并不是项目目前的项目的核心问题，解决了，又能如何呢？谁会分配资源给你来解决问题，谁会配合你解决问题？
如果没有共识，或者无法建立共识，那么要么忍，要么滚。
第三，产品是过程的产物，你们目前的系统也是过程长时间运行的产物。 IT系统成功的三大要素是：过程，人和技术。想不触动软件开发过程，仅仅从软件技术上解决问题是没有办法解决的。
看到上面你的描述，估计贵公司是没有什么成文的过程（或者没有执行），你要找公司的相关部门，如过程管理部，质量管理部，或项目管理办公室，得到他们的支持，建立软件开发过程，如：
第四，要有合格的团队成员，团队成员要建立起良好的习惯和准备充足的技能，没有合格的人，也是不靠谱的。你不能一个人单枪匹马和风车作战吧。
人的问题一方面要用制度，也就是上面谈到的过程，进行约束和规范，另一方面，还是要进行培训，提高技能。对于那些不愿意改变的员工，只能通过招募更多新员工的方式来解决，在没有文档的公司里，老员工脑子里的知识十分重要。
员工应该学习和提高开发技能，比如：
第五，问题要主次分清，你列的24个问题，是不是一样严重，哪个公司都有这样那样的问题，但是这个问题是不是严重的影响项目当前的运转和按期达到目标？你要找出最重要和最急迫解决（两个维度）的问题着手解决，其他的问题可以先放置。
第六，老代码中的问题可以放置，新开发的代码一定要建立新的技术规范来，避免更多的烂代码出现。在这个基础上，你才能够慢慢改进老的代码。比如编码规范，日志规范等。
第七，解决问题的过程要一步一步走，每一步都尽量取得看得见的进展，解决团队成员和领导的痛点，形成正向反馈。这样支持你的力量越来越大，反对、质疑你的力量越来越小。否则在你进行大手术的过程中就会被团队成员和领导的不满压倒。
第八，建立文档，对于工作压力不大的任务，一定要求写相关的文档，慢慢补上一些材料，特别是模块的接口，库表结构，文件格式，协议等。有些文档可以利用反向工程的工具生成。团队一定要注意知识积累。
在这些文档的基础上，解决遇到的问题，或者进行重构才有可能。
我简单归类一下你问题吧，然后给出了我个人的意见。
重要，目前要着手改变的，建立起过程和规范来。
文档的作用有两个，1. 沟通，2. 技术积累。前一个可以通过口头沟通替代，但是后一个感觉无法被取代。
一般，已有的代码可以忍了，新的代码一定要改。如果这里面有痛点，可以选择一些解决老代码上的问题。
话说没有单元测试，你敢重构吗？没有重构，你敢敏捷吗？
数据库表没有注释一定要解决。否则出了问题怎么查呢？通过反向工程就能够产生E-R图，然后让老员工帮忙回忆，可以放到Wiki中，慢慢补上没有的内容。
琐事，现在完全没有必要着手改已有的代码，只是要建立起技术规范，新代码可以不犯这些错误。已有代码中的问题也很难系统解决。
json字符串完全可以用Jackson，xstream，JAXB之类的技术，操作POJO，生成字符串。
生成HTML这种大段的文本，还是用模板不吧，可以引入模板框架如Freemarker，引导大家使用。HashMap和Java Bean，这是应该改。
其实所有欠下的技术债要么是妥协于当时公司和项目的业务目标（比如工期），要么是管理经验不足。要解决技术债，还是要从管理上着手。
假设，你决定留下来处理这个烂摊子，提供以下建议供参考：
第一，你应该得到足够的职位或授权，一个程序员是没有足够的能力处理这个问题的。不在其位，不谋其政，如果你连项目经理或架构师都不是，连技术高层的认可都没有，那么还是走为上。
第二，建立共识，你的观察和意见是否能够得到领导和团队成员的认可？
在团队目前共识中，你列的这24个问题是项目最重要，最急迫的问题吗？是不是还有更重要的问题，你暂时还没有接触到？
你的问题描述客观吗？还是过分夸大，和带着情绪？很多词看起来都不是平心静气的说的。你看到的问题领导和团队成员看到了吗？他们认可吗？
解决这24个问题能提高你们的生产效率，或节省经费吗？能缩短问题解决的时间，提高客户满意度吗？能减少加班吗？
如果你这24个问题并不是项目目前的项目的核心问题，解决了，又能如何呢？谁会分配资源给你来解决问题，谁会配合你解决问题？
如果没有共识，或者无法建立共识，那么要么忍，要么滚。
第三，产品是过程的产物，你们目前的系统也是过程长时间运行的产物。 IT系统成功的三大要素是：过程，人和技术。想不触动软件开发过程，仅仅从软件技术上解决问题是没有办法解决的。
看到上面你的描述，估计贵公司是没有什么成文的过程（或者没有执行），你要找公司的相关部门，如过程管理部，质量管理部，或项目管理办公室，得到他们的支持，建立软件开发过程，如：
- 需求文档及评审
- 设计文档及评审
- 代码评审
- 单元测试
第四，要有合格的团队成员，团队成员要建立起良好的习惯和准备充足的技能，没有合格的人，也是不靠谱的。你不能一个人单枪匹马和风车作战吧。
人的问题一方面要用制度，也就是上面谈到的过程，进行约束和规范，另一方面，还是要进行培训，提高技能。对于那些不愿意改变的员工，只能通过招募更多新员工的方式来解决，在没有文档的公司里，老员工脑子里的知识十分重要。
员工应该学习和提高开发技能，比如：
- 单元测试，以及代码覆盖率
- 写Web应用时，要分层，不在JSP里嵌入业务逻辑。而是用Java Bean封装业务逻辑。
- 掌握面向对象的程序设计，理解SOLID原则，设计模式等。
- 比如命令和查询职责分离原则（CQRS）
- Spring框架 的使用
第五，问题要主次分清，你列的24个问题，是不是一样严重，哪个公司都有这样那样的问题，但是这个问题是不是严重的影响项目当前的运转和按期达到目标？你要找出最重要和最急迫解决（两个维度）的问题着手解决，其他的问题可以先放置。
第六，老代码中的问题可以放置，新开发的代码一定要建立新的技术规范来，避免更多的烂代码出现。在这个基础上，你才能够慢慢改进老的代码。比如编码规范，日志规范等。
第七，解决问题的过程要一步一步走，每一步都尽量取得看得见的进展，解决团队成员和领导的痛点，形成正向反馈。这样支持你的力量越来越大，反对、质疑你的力量越来越小。否则在你进行大手术的过程中就会被团队成员和领导的不满压倒。
第八，建立文档，对于工作压力不大的任务，一定要求写相关的文档，慢慢补上一些材料，特别是模块的接口，库表结构，文件格式，协议等。有些文档可以利用反向工程的工具生成。团队一定要注意知识积累。
在这些文档的基础上，解决遇到的问题，或者进行重构才有可能。
我简单归类一下你问题吧，然后给出了我个人的意见。
重要，目前要着手改变的，建立起过程和规范来。
7.不写注释、不写文档不写注释还在其次，不写文档，时间长了，没人知道是怎么回事了。什么叫不写文档，是少写还是不写？
文档的作用有两个，1. 沟通，2. 技术积累。前一个可以通过口头沟通替代，但是后一个感觉无法被取代。
17.每个作者都喜欢自己搞一套，缺乏共识，各自为战，各种约定、各玩各的这个肯定是在过程上缺乏规范和评审。 为什么说这些问题不是技术问题，二是管理的问题。仅靠你一个人重构，就能解决这个问题吗？
24.整个团队都没有代码质量追求，习惯了烂代码是进度压力导致的，还是就是不想好好干？你很主观的描述，是不是你的情绪的宣泄？
一般，已有的代码可以忍了，新的代码一定要改。如果这里面有痛点，可以选择一些解决老代码上的问题。
1.一半的bean用spring管理，另一半的bean自己new或者用单例模式，spring的包扫描配错了，但两年时间一直没人改过来培训Spring技术啊，使得团队成员对Spring技术的掌握达到统一的水平之上。
2.到处都是静态类、静态方法，没法扩展提高面向对象的程序设计水平，代码规范和评审。
4.业务配置文件过于复杂，过度设计，居然是事件模式解析过度设计造成什么后果了吗？已经完成的过度设计的模块，是否给维护的人带来困扰？
5.自己写了个Dao，自己手动管理事务，到处拼sql，六七十个字段的表，每个操作都重复拼这个就是要代码评审和代码规范了。
6.4000行的大jsp、大类、800行的大方法、多达17个参数的方法，喜欢写万能函数代码规范和代码评审。其实消除很多复制粘贴的代码，把业务逻辑的代码抽离，代码就没有那么多了。方法参数多一定是bad smell，简单粗暴的解决可以引入Parameter Object。
20.页面还是jsp，jsp里写了大量的业务逻辑，甚至通过httpclient去抓别的项目，抓回来内容嵌在当前页面里代码规范和代码评审。
13.方法、变量命名词不达意，经常在getXXX、isXXX的方法里改传入参数，但又反回值，从命名就能看出作者词汇量狭窄、思维局限代码规范，参见上面说的CQRS原则。
14.对spring、spring mvc了解和利用严重不够，框架支持得很好的功能，非要自己写技术培训啊，有足够的文档和知识的积累啊，避免自己造轮子。
15.pom依赖关系一团糟，各种重复引包、重复依赖，httpclient竟然多达4个版本这个问题应该重视起来，但还是对技术了解不够，缺乏规范和评审。如果是使用的不同框架使用了不同的HTTPClient的版本，这个可以通过梳理，降低到2个版本左右。
21.到处都是main方法，不用单元测试这个是没有单元测试方法，不熟悉JUnit，在项目中推行单元测试，新的代码要添加单元测试，单元测试的质量如何可以使用代码覆盖率工具如Emma进行评估。不好写的单元测试，可以自己写些测试桩，也可以使用Mock Object。
话说没有单元测试，你敢重构吗？没有重构，你敢敏捷吗？
22.代码重复度很高，一段逻辑，到处复制粘贴这个靠代码评审解决，一些静态分析工具，Java的有PMD，FindBugs也可以查出来。
23.数据库表设计很烂，导致不好查（比如用逗号分隔的串），较老得表甚至毫无注释（生产环境）不好查询一回事，现有的代码已经实现完了。查询的效率不高倒是有可能。
数据库表没有注释一定要解决。否则出了问题怎么查呢？通过反向工程就能够产生E-R图，然后让老员工帮忙回忆，可以放到Wiki中，慢慢补上没有的内容。
琐事，现在完全没有必要着手改已有的代码，只是要建立起技术规范，新代码可以不犯这些错误。已有代码中的问题也很难系统解决。
8.log4j和logbak混用，各占一半很正常，项目时间比较长，或者项目比较分散，使用多种日志机制而已。选出一种来，在新新代码推行。也可以是使用Simple Logging Facade for Java (SLF4J) 作为接口，slf4j还是有很多好处的。
9.混杂的代码风格，花括号行尾、换行都有，缩进用tab、2空格、4空格、8空格，紧凑风格和松散风格都有这个问题太琐碎了，统一一种缩进方式，添加到代码规范里，然后旧的代码慢慢改。
10.一些作者喜欢用反射调代码，没办法用ide跟踪反射怎么就没法跟踪呢？不解
11.很多作者不用开源工具包，喜欢自己搞一套，有炫技嫌疑，实际上搞得很烂这个太正常了，我甚至感觉题主情绪上的渲染和夸大。一种情况是不知道开源工具，自己土法上马，一种是觉得开源工具不顺手（也许是不熟悉），自己写立马解决问题。
12.分包分得一团糟，既想按照功能分，又想按照业务分，没有把握好，稀里糊涂的这个不是什么大问题，你一上来接触很多代码觉得乱，这很正常。
16.大片的被注掉的代码留在项目里，到处都是，许多废弃的类和废弃的配置文件没有删掉正常，废类和配置文件要去掉，注释掉的代码没太大问题。代码规范中添加要求即可。
18.该打日志的地方没有打，导致一些工单成了无头案，有些地方，又重复打日志，啰里啰嗦这个很正常，你们有统一的日志规范吗？没有就各自按照自己的习惯打了。
19.到处都是HashMap，而不用java bean；1个HttpServletRequest调了五六层方法；自己手工拼json字符串；拼email的html body，不用模板手工拼写字符串，不用模板也很正常。需要要注意的是地方高频调用的拼字符串的效率，不要用String的+操作，用StringBuilder。
json字符串完全可以用Jackson，xstream，JAXB之类的技术，操作POJO，生成字符串。
生成HTML这种大段的文本，还是用模板不吧，可以引入模板框架如Freemarker，引导大家使用。HashMap和Java Bean，这是应该改。
- 无法判定，由于我不熟悉，无法判断优先级
3.在低基数、低频率的搜索上写优化算法，算法和业务逻辑搅在一起，没有分开为2个层面
其实所有欠下的技术债要么是妥协于当时公司和项目的业务目标（比如工期），要么是管理经验不足。要解决技术债，还是要从管理上着手。
281
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
