关闭

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

标签: 管理
269人阅读 评论(0) 收藏 举报
分类:
一个很烂的项目,发现以下问题:

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.培训,软件开发规范,如果所在部门话语权不足,就内部培训,邀请兄弟部门
总之,不要单以技术热情来操作此事!!!
公司不认可,就说明代码还没有烂到他们觉得做手术的时候!!!就说明重构的市场价值不大!!!
公司不发话就别动!
如果公司的负责人有能力并且也有意愿来解决这些问题,建议好好跟着他干,做好执行,理解的要执行,不理解的也要执行。这是非常锻炼自身能力,提高经验值的事情。越乱越好,能够把烂摊子理顺,是能力的重要体现。不要因为眼前的这些问题而感到挫折,或者不爽,进而影响工作效率。尽量把事情做得更好。多大一个空格,把括号对齐也是改善。当然,跟烂摊子死扣也仅仅是修炼的一种方式。也可以有别的方式,辞职,换别的不同的公司也可以是种选择。
最后转个小故事:“在高盛期间,一次复杂的重组项目让他真正学习到了东西。当时在国内投资界名噪一时的广东粤海集团重组,高盛足足操作了两年,中间涉及到100多家债权银行,400多家公司,刘每天工作都到凌晨两三点,两年的项目感觉做了四年。但最终完成后,刘也对企业的管理、经营、执行几乎所有流程都都全面了解,“做完这个项目,基本上再做任何项目都觉得容易了。

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


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:210298次
    • 积分:3196
    • 等级:
    • 排名:第10744名
    • 原创:119篇
    • 转载:25篇
    • 译文:0篇
    • 评论:31条