代码腐化之路

11年刚进入一个新部门，接手一个老项目，典型的legacy code , 一个jsp 好几千行，那叫一个乱。

但是细细瞧瞧， 还有不少代码是不错的，依稀能看到漂亮代码的影子，可以想象，当初的架构应该还是优美的，只不过经过了若干程序员之手以后，代码慢慢的腐化了。

 

07 年做的一个项目也是这样，刚开始的时候设计了一个漂亮的架构，大家都严格遵循规则写代码，很注意维护架构的完整性和一致性，也做Code Review,坚决杜绝 dirty code。 随着时间的推移，项目的进度压力加大，什么原则了，纪律了都抛弃了，实现功能是第一要务， 最后系统变成了一个难于理清的大怪物， 现在大家都盼望着它赶紧退休，推倒重写。

 

联想到我2010年做的咨询项目，客户是行业的领导者，软件和产品运行在世界各地，原以为代码质量会很不错，进入项目组一看，好家伙，代码够乱的，项目组成员在实现新特性的时候，好多copy&paste , 然后就忙着fix bug 。

我深入的看了它的代码结构， 隐隐约约的看到最初的一些好的原则，模式隐藏在代码的背后，对照现在的代码，让人无限感慨。

 

代码腐化之路

 

新项目来了，大家很happy,有机会从头开始构建一个东西，是很难得地，于是仔细小心的设计架构，定下规矩和原则，约定大家都要遵守，刚开始时运转正常，平安无事。

 

渐渐的出现了一些新情况，需求变动，时间很紧张， 程序员发现有一个非常直接的办法，可以快速的实现客户的要求， 几天就可以搞定， 但是违背了架构的原则或最初的项目的编码约定， 如果想遵循的话，可能需要花费好几倍的工作量，可能需要几周才能完成，更要命的是，为了实现这个新需求，可能需要对整个架构进行调整， 真的调整了，测试跟不上，风险太大， 怎么办？

大多数情况下，程序员都经不起诱惑，也扛不住进度的压力， 会用最直接的办法进行快速修改，“管他呢，先实现再说，反正我还记得细节”  ，实际上，改完以后我们又忙着干别的事情去了，过上几个月，自己都看不懂了。久而久之，这些脏代码没有人知道是怎么回事了， 后面接手的程序员就会骂前面的程序员 “这么烂的代码，谁写的！！！？？？” 

 

代码就是这么腐化的......

 

 

 

 

评论

26 楼 rabbit2011 2011-04-16  

重构须贯穿于始终。

25 楼 fanfq 2011-04-15  

DOCDOC 写道

tianmo2008 写道

很多程序员都是散弹式的，修改bug时见逢插针，那里出了问题就在附近加点处理逻辑。
很多有经验的程序员也会经常了为快速处理bug,采取这种方式，久而久之，本来条理很清晰的程序，变得越来越臃肿，同样的处理逻辑散落得到处都是。。。。。
越是后面接手的人越是痛苦，
很多接手的人都想过重写，想上面提出，回复是“虽然有问题，但整体运行得还好，重写风险太大，不给干。”。
想私下重写，但开发任务又压得紧，出了bug又象催命鬼似的催个不停，只能继续霰弹式蔓延。
等到那一天处理不了了。。。。

对于一些数据准确性比较敏感的应用,一般是没有任何理由去重写的.
一个系统能常年运行并频繁使用着,说明这个系统本身是具有业务价值的. 在这种大前提下,如何规避风险,保证业务价值是要优先去考虑的.重写的风险太大了.
至于修Bug, 换个角度:病人治病,治疗方案当然是针对病灶. 当然,保健医生(好比:顾问)会提供很多的预防建议,但是主治医生(好比:技术维护人员)的义务,只是治好病

一直在安慰自己，只要跑的不出问题的代码就是好代码。修改bug时见逢插针也未尝不可。

如果时间够的话，那就再重构的，要是没时间，那就改bug。

24 楼 href 2011-04-15  

俺们的项目我看见过，一个方法长达250多行。

23 楼 C.T 2011-04-15  

我们现在这样骂人，然后到时又被人这样骂啊！

22 楼 Jacky-Q 2011-04-13  

简直是项目必经之路了，我的项目也是这样。
关键像上面的朋友们讲的，重构代码没有激励，快速交差更能拿奖金。三五年后的代码会怎样，who care？按IT业的跳槽频率，这是后来者的麻烦了。

21 楼 MaxWu 2011-04-12  

一开始就考虑到两种情况:
1) Branch + Refactory
2) High pressure and low skilled ppl

20 楼 pch272215690 2011-04-11  

我们的系统就是这种现状，烂到改不动了就辞职。

19 楼 ffychina 2011-04-10  

经历过，有感受，也为此辞职。我现在是不允许我的开发团队有垃圾代码，我会用一些开发管理方法去降低垃圾代码，提交代码的可维护性，当然，这需要整个团队所有成员的配合和共识。

18 楼 sniffer123 2011-04-09  

重构不能卖钱，不能作为资历，不能作为年终奖的凭据，谁乐意重构？
辛辛苦苦写的漂亮的代码，结果别人稀里糊涂复制黏贴后反而被夸奖手脚利索，呵呵

17 楼 alyouge 2011-04-09  

我们的代码就是这个样子的 ！

16 楼 xiaojin21cen 2011-04-09  

深有同感，也深受其害。现在的项目的代码“怎一个烂字了得”

15 楼 DOCDOC 2011-04-07  

tianmo2008 写道

很多程序员都是散弹式的，修改bug时见逢插针，那里出了问题就在附近加点处理逻辑。
很多有经验的程序员也会经常了为快速处理bug,采取这种方式，久而久之，本来条理很清晰的程序，变得越来越臃肿，同样的处理逻辑散落得到处都是。。。。。
越是后面接手的人越是痛苦，
很多接手的人都想过重写，想上面提出，回复是“虽然有问题，但整体运行得还好，重写风险太大，不给干。”。
想私下重写，但开发任务又压得紧，出了bug又象催命鬼似的催个不停，只能继续霰弹式蔓延。
等到那一天处理不了了。。。。

对于一些数据准确性比较敏感的应用,一般是没有任何理由去重写的.
一个系统能常年运行并频繁使用着,说明这个系统本身是具有业务价值的. 在这种大前提下,如何规避风险,保证业务价值是要优先去考虑的.重写的风险太大了.
至于修Bug, 换个角度:病人治病,治疗方案当然是针对病灶. 当然,保健医生(好比:顾问)会提供很多的预防建议,但是主治医生(好比:技术维护人员)的义务,只是治好病

14 楼 huangfoxAgain 2011-04-07  

是的，前期都设计的好好的，干干净净，后来需求变动，时间压得紧，就顾不上那些了~ 先实现功能，给眼前的领导个交待再说~后来就陷入了代码沼泽中，希望快点解脱，于是就有了很多其他理由的离职~

13 楼 DOCDOC 2011-04-07  

ender 写道

3 楼说的很对，不断的重构时解决腐化问题的出路，可惜啊， 我所经历的项目中还没有一个能够做到持续的重构， 保持清洁的代码。

我自己也有些怀疑了，到底有没有项目是能够保持Clean Code ?

传说有,但是极少极少.
很多外表光鲜,号称世界级的XXOO系统,代码也是一团乱麻. 刚工作时,曾改过一个号称有20年的C代码, 那才叫惨不忍睹

12 楼 tianmo2008 2011-04-06  

很多程序员都是散弹式的，修改bug时见逢插针，那里出了问题就在附近加点处理逻辑。
很多有经验的程序员也会经常了为快速处理bug,采取这种方式，久而久之，本来条理很清晰的程序，变得越来越臃肿，同样的处理逻辑散落得到处都是。。。。。
越是后面接手的人越是痛苦，
很多接手的人都想过重写，想上面提出，回复是“虽然有问题，但整体运行得还好，重写风险太大，不给干。”。
想私下重写，但开发任务又压得紧，出了bug又象催命鬼似的催个不停，只能继续霰弹式蔓延。
等到那一天处理不了了。。。。

11 楼 ender 2011-04-06  

snake1987 写道

深有同感，也深受其害，很期待楼主的文章能引出一套解决方案出来

不好意思， 我也没有Solution,这里只能发发牢骚,然后告诉自己，看到烂代码，就不要再骂了，因为自己也可能是烂代码的来源。 当然自己尽量写Clean Code, 防止被别人骂 

10 楼 Sunny_kaka 2011-04-06  

我现在还在努力保持代码干净.
虽然背负着很大的进度压力.
只是因为我们都见过慢慢腐烂的系统,不想让悲剧重演.

9 楼 waiting 2011-04-06  

都是被逼的~

8 楼 jssay 2011-04-06  

后面接手的程序员就会骂前面的程序员 “这么烂的代码，谁写的！！！？？？” 
这句比较经典！

7 楼 snake1987 2011-04-06  

深有同感，也深受其害，很期待楼主的文章能引出一套解决方案出来