代码腐化之路

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

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

 

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

 

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

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

 

代码腐化之路

 

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

 

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

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

 

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

 

 

 

 

评论

6 楼 dracularking 2011-04-06  

不是说没有clean code，我觉得一是侧重点，很少需要维护的，那可能价值是不大，但换言之也是个死程序，二也是更重要的，如果连你们老板都不在乎，程序员又有什么办法去在乎

5 楼 ender 2011-04-06  

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

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

4 楼 DOCDOC 2011-04-06  

重构这个词儿,说起来很轻巧,事实上呢?
跑得好的程序,远比写得好的程序,来得有价值

3 楼 Mybeautiful 2011-04-06  

同意楼主的观点。但是如果是需要长久维护一个项目，就必须要不断的重构，不只是代码，甚至是框架。我经常对大伙说的就是“你埋下的任何一个坑，将来都会被踩到，为了将来更Happy,现在多花点时间”；维护一个产品5年，其间不断的有新功能增加，终于把它从被放弃的边缘到现在开心的继续维护着。
不断的重构是解决腐化问题的唯一出路。这需要维护者(各个相关角色，主要是开发人员)有足够的勇气，自信，专业知识，以及最求完美的精神。

2 楼 nighty 2011-04-06  

在项目进步的催促下，都会慢慢变成这种情况

1 楼 brook.realize 2011-04-06  

过度复杂的框架要求的通病. 在一开始的时候,就需要考虑到这样的设计方案如何应对高压,如果连高压下的人情都未考虑到,这个方案只不过是温室里的花朵,玩玩而已