代码是怎么腐化的
新三年,旧三年,修修补补又三年。
— 中国俗语。
上面的这句俗语用来形容很多遗留软件系统(legacy software system)的现状是再合适不过了。
今天下午做了一下午的代码评审,对象是一个运行了7年的遗留系统。会上除了几处明显的代码逻辑错误我发言指了出来外,涉及业务流程以及代码设计的问题,我 大多保持沉默。因为我清楚,即便我明确指出问题,可能也得不到修正。也许参与评审代码的其他同事也都知晓这些问题,只是觉得现在还不能去改…。
为何不能去改?回想当年第一版代码出炉时,它是那么的“出淤泥而不染”,而如今它身材臃肿,满身赘肉,千疮百孔,让人无处下手,看起来都不舒服。虽然它依旧能坚持工作,但终会有一天,它会轰然倒地,酿成大错。为何代码会腐化到如此地步?是怎么腐化的?这里谈几点体会。
* 第一版的设计和实现水准
我们知道:设计再完美的系统也终会有腐化的一天,时间才是最可怕的武器,它是一把无情的刻刀,不仅能使人老去,逻辑抽象世界的程序也不能幸免。但是你的程 序设计和实现的越完美,这个衰老和腐化的周期就会越长。一个糟糕的初始设计和实现,只会让系统更早的发霉、腐败直至被替换。我们的这个legecy系统在 最初的代码设计上就给后人留下了许多“糟糕的参照物”,在后人无以伦比的“复制粘贴”的技能下,这些糟糕的设计和实现就像癌细胞一样扩散到系统机体的每个 角落,让你无法重新建立其免疫系统。
* 没有测试做保障,不敢改
系统从诞生的那天起就使用“人肉测试”的方式,而且是粗粒度的系统功能测试。没有白盒的、可重复使用的、自动执行的单元测试集做保障,以致没有人敢对其轻举妄动,一旦出了问题,后果自负。另外人肉测试,精力和成本双重消耗,测试人员“耗”不起啊。
* 缺少崇尚“美”的文化
记得组织第一版企业文化中“美”这个成分还有立足之地的,但后期改版后,我们就再也看不到“美”了。码农们也是一样,在缺少了“俱美”之风的吹拂下,大家 都变得有些“丑陋”了,大家都开始摒弃“美”,认为代码只要能工作即可,美不美不打紧,于是工作就变成了修修补补,系统变得日益臃肿,臭气熏天。
* 进度之忧高悬
很多人会说:“如果给我充足的时间,我会让系统获得新生。但我没有时间,客户那边催的急,只能下次再重构、完善和优化了吧”。从这里不知大家是否看出了:“改善是没有的,下次却是永恒的”这一“道理”。在进度堪忧的情况下,我们多数时候选择了屈服,而不是自己的原则。
* 成本,老板们不得不面对的
“能用即可,新三年,旧三年,修修补补又三年”。如果你和老板谈重构、谈优化,那么这句话就是老板最好的拖词儿。成本永远是悬在老板头上的一把宝剑,老板们不能视而不见。因此,如果你要和老板谈重写遗留系统,那得需要多么强大的魄力和坚定的意志啊。
* 拷贝粘贴,最好的伙伴 or 最大的敌人
相信发明复制、粘贴以及剪切板的那位仁兄无论如何也没有想到,自己送给世界的礼物,竟然被码农们操练的如此熟练,应用在各种场合,尤其是Coding中。代码中充斥着大量重复代码信息,都是拷贝、复制和粘贴的结果,于是乎代码腐败的最大敌人就此出现了。
牢记:“千里大堤,溃于蝼蚁”。下一步该怎么办?去闻闻,你的代码腐化了没有!
© 2013, bigwhite. 版权所有.
Related posts:
唉,感同身受… 每天都以这种代码为伴…每天都上演类似的场景…
+1