代码腐化之路

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

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

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

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

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

代码腐化之路

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

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

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

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

相关推荐