爱分享

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

来源:编程学习网 2019-01-01 19:45:35521



一个很烂的项目,发现以下问题:

      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上层的上层(我们公司是COOCTO直接支持)都得支持才行。否则你想一个人干就是稳死。而且肯定是先把你干掉。

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

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

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

 

几点建议:

1.  策略一:

 

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

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

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

 

2、策略二:

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


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


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


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

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

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

总之,不要单以技术热情来操作此事!!!

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

公司不发话就别动!

 

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

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

 

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


文章整理于“知乎”

文章推荐