代码腐化之路11年刚进入一个新部门，接手一个老项目，典型的legacy code , 一个jsp 好几千行，那叫一个乱。但
代码腐化之路
11年刚进入一个新部门，接手一个老项目，典型的legacy code , 一个jsp 好几千行，那叫一个乱。
但是细细瞧瞧， 还有不少代码是不错的，依稀能看到漂亮代码的影子，可以想象，当初的架构应该还是优美的，只不过经过了若干程序员之手以后，代码慢慢的腐化了。
?
07 年做的一个项目也是这样，刚开始的时候设计了一个漂亮的架构，大家都严格遵循规则写代码，很注意维护架构的完整性和一致性，也做Code Review,坚决杜绝 dirty code。 随着时间的推移，项目的进度压力加大，什么原则了，纪律了都抛弃了，实现功能是第一要务， 最后系统变成了一个难于理清的大怪物， 现在大家都盼望着它赶紧退休，推倒重写。
?
联想到我2010年做的咨询项目，客户是行业的领导者，软件和产品运行在世界各地，原以为代码质量会很不错，进入项目组一看，好家伙，代码够乱的，项目组成员在实现新特性的时候，好多copy&paste , 然后就忙着fix bug 。
我深入的看了它的代码结构， 隐隐约约的看到最初的一些好的原则，模式隐藏在代码的背后，对照现在的代码，让人无限感慨。
?
代码腐化之路
?
新项目来了，大家很happy,有机会从头开始构建一个东西，是很难得地，于是仔细小心的设计架构，定下规矩和原则，约定大家都要遵守，刚开始时运转正常，平安无事。
?
渐渐的出现了一些新情况，需求变动，时间很紧张， 程序员发现有一个非常直接的办法，可以快速的实现客户的要求， 几天就可以搞定， 但是违背了架构的原则或最初的项目的编码约定， 如果想遵循的话，可能需要花费好几倍的工作量，可能需要几周才能完成，更要命的是，为了实现这个新需求，可能需要对整个架构进行调整， 真的调整了，测试跟不上，风险太大， 怎么办？
大多数情况下，程序员都经不起诱惑，也扛不住进度的压力， 会用最直接的办法进行快速修改，“管他呢，先实现再说，反正我还记得细节”? ，实际上，改完以后我们又忙着干别的事情去了，过上几个月，自己都看不懂了。久而久之，这些脏代码没有人知道是怎么回事了， 后面接手的程序员就会骂前面的程序员 “这么烂的代码，谁写的！！！？？？”?
?
代码就是这么腐化的......
?
?
?
?
我也没有Solution,这里只能发发牢骚,然后告诉自己，看到烂代码，就不要再骂了，因为自己也可能是烂代码的来源。 当然自己尽量写Clean Code, 防止被别人骂
12 楼 tianmo2008 2011-04-06 很多程序员都是散弹式的，修改bug时见逢插针，那里出了问题就在附近加点处理逻辑。
很多有经验的程序员也会经常了为快速处理bug,采取这种方式，久而久之，本来条理很清晰的程序，变得越来越臃肿，同样的处理逻辑散落得到处都是。。。。。
越是后面接手的人越是痛苦，
很多接手的人都想过重写，想上面提出，回复是“虽然有问题，但整体运行得还好，重写风险太大，不给干。”。
想私下重写，但开发任务又压得紧，出了bug又象催命鬼似的催个不停，只能继续霰弹式蔓延。
等到那一天处理不了了。。。。 13 楼 DOCDOC 2011-04-07 ender 写道3 楼说的很对，不断的重构时解决腐化问题的出路，可惜啊， 我所经历的项目中还没有一个能够做到持续的重构， 保持清洁的代码。
我自己也有些怀疑了，到底有没有项目是能够保持Clean Code ?
传说有,但是极少极少.
很多外表光鲜,号称世界级的XXOO系统,代码也是一团乱麻. 刚工作时,曾改过一个号称有20年的C代码, 那才叫惨不忍睹 14 楼 huangfoxAgain 2011-04-07 是的，前期都设计的好好的，干干净净，后来需求变动，时间压得紧，就顾不上那些了~ 先实现功能，给眼前的领导个交待再说~后来就陷入了代码沼泽中，希望快点解脱，于是就有了很多其他理由的离职~ 15 楼 DOCDOC 2011-04-07 tianmo2008 写道很多程序员都是散弹式的，修改bug时见逢插针，那里出了问题就在附近加点处理逻辑。
很多有经验的程序员也会经常了为快速处理bug,采取这种方式，久而久之，本来条理很清晰的程序，变得越来越臃肿，同样的处理逻辑散落得到处都是。。。。。
越是后面接手的人越是痛苦，
很多接手的人都想过重写，想上面提出，回复是“虽然有问题，但整体运行得还好，重写风险太大，不给干。”。
想私下重写，但开发任务又压得紧，出了bug又象催命鬼似的催个不停，只能继续霰弹式蔓延。
等到那一天处理不了了。。。。
对于一些数据准确性比较敏感的应用,一般是没有任何理由去重写的.
一个系统能常年运行并频繁使用着,说明这个系统本身是具有业务价值的. 在这种大前提下,如何规避风险,保证业务价值是要优先去考虑的.重写的风险太大了.
至于修Bug, 换个角度:病人治病,治疗方案当然是针对病灶. 当然,保健医生(好比:顾问)会提供很多的预防建议,但是主治医生(好比:技术维护人员)的义务,只是治好病 16 楼 xiaojin21cen 2011-04-09 深有同感，也深受其害。现在的项目的代码“怎一个烂字了得” 17 楼 alyouge 2011-04-09 我们的代码就是这个样子的 ！ 18 楼 sniffer123 2011-04-09 重构不能卖钱，不能作为资历，不能作为年终奖的凭据，谁乐意重构？
辛辛苦苦写的漂亮的代码，结果别人稀里糊涂复制黏贴后反而被夸奖手脚利索，呵呵 19 楼 ffychina 2011-04-10 经历过，有感受，也为此辞职。我现在是不允许我的开发团队有垃圾代码，我会用一些开发管理方法去降低垃圾代码，提交代码的可维护性，当然，这需要整个团队所有成员的配合和共识。 20 楼 pch272215690 2011-04-11 我们的系统就是这种现状，烂到改不动了就辞职。 21 楼 MaxWu 2011-04-12 一开始就考虑到两种情况:
1) Branch + Refactory
2) High pressure and low skilled ppl 22 楼 Jacky-Q 2011-04-13 简直是项目必经之路了，我的项目也是这样。
关键像上面的朋友们讲的，重构代码没有激励，快速交差更能拿奖金。三五年后的代码会怎样，who care？按IT业的跳槽频率，这是后来者的麻烦了。 23 楼 C.T 2011-04-15 我们现在这样骂人，然后到时又被人这样骂啊！ 24 楼 href 2011-04-15 俺们的项目我看见过，一个方法长达250多行。 25 楼 fanfq 2011-04-15 DOCDOC 写道tianmo2008 写道很多程序员都是散弹式的，修改bug时见逢插针，那里出了问题就在附近加点处理逻辑。
很多有经验的程序员也会经常了为快速处理bug,采取这种方式，久而久之，本来条理很清晰的程序，变得越来越臃肿，同样的处理逻辑散落得到处都是。。。。。
越是后面接手的人越是痛苦，
很多接手的人都想过重写，想上面提出，回复是“虽然有问题，但整体运行得还好，重写风险太大，不给干。”。
想私下重写，但开发任务又压得紧，出了bug又象催命鬼似的催个不停，只能继续霰弹式蔓延。
等到那一天处理不了了。。。。
对于一些数据准确性比较敏感的应用,一般是没有任何理由去重写的.
一个系统能常年运行并频繁使用着,说明这个系统本身是具有业务价值的. 在这种大前提下,如何规避风险,保证业务价值是要优先去考虑的.重写的风险太大了.
至于修Bug, 换个角度:病人治病,治疗方案当然是针对病灶. 当然,保健医生(好比:顾问)会提供很多的预防建议,但是主治医生(好比:技术维护人员)的义务,只是治好病
一直在安慰自己，只要跑的不出问题的代码就是好代码。修改bug时见逢插针也未尝不可。
如果时间够的话，那就再重构的，要是没时间，那就改bug。 26 楼 rabbit2011 2011-04-16 重构须贯穿于始终。
12 楼 tianmo2008 2011-04-06 很多程序员都是散弹式的，修改bug时见逢插针，那里出了问题就在附近加点处理逻辑。