11年刚进入一个新部门，接手一个老项目，典型的legacy code , 一个jsp 好几千行，那叫一个乱。
但是细细瞧瞧， 还有不少代码是不错的，依稀能看到漂亮代码的影子，可以想象，当初的架构应该还是优美的，只不过经过了若干程序员之手以后，代码慢慢的腐化了。
07 年做的一个项目也是这样，刚开始的时候设计了一个漂亮的架构，大家都严格遵循规则写代码，很注意维护架构的完整性和一致性，也做Code Review,坚决杜绝 dirty code。 随着时间的推移，项目的进度压力加大，什么原则了，纪律了都抛弃了，实现功能是第一要务， 最后系统变成了一个难于理清的大怪物， 现在大家都盼望着它赶紧退休，推倒重写。
联想到我2010年做的咨询项目，客户是行业的领导者，软件和产品运行在世界各地，原以为代码质量会很不错，进入项目组一看，好家伙，代码够乱的，项目组成员在实现新特性的时候，好多copy&paste , 然后就忙着fix bug 。
我深入的看了它的代码结构， 隐隐约约的看到最初的一些好的原则，模式隐藏在代码的背后，对照现在的代码，让人无限感慨。
代码腐化之路
新项目来了，大家很happy,有机会从头开始构建一个东西，是很难得地，于是仔细小心的设计架构，定下规矩和原则，约定大家都要遵守，刚开始时运转正常，平安无事。
渐渐的出现了一些新情况，需求变动，时间很紧张， 程序员发现有一个非常直接的办法，可以快速的实现客户的要求， 几天就可以搞定， 但是违背了架构的原则或最初的项目的编码约定， 如果想遵循的话，可能需要花费好几倍的工作量，可能需要几周才能完成，更要命的是，为了实现这个新需求，可能需要对整个架构进行调整， 真的调整了，测试跟不上，风险太大， 怎么办？
大多数情况下，程序员都经不起诱惑，也扛不住进度的压力， 会用最直接的办法进行快速修改，“管他呢，先实现再说，反正我还记得细节” ，实际上，改完以后我们又忙着干别的事情去了，过上几个月，自己都看不懂了。久而久之，这些脏代码没有人知道是怎么回事了， 后面接手的程序员就会骂前面的程序员 “这么烂的代码，谁写的！！！？？？”
代码就是这么腐化的......