新三年，旧三年，修修补补又三年。
                                                             — 中国俗语。

上面的这句俗语用来形容很多遗留软件系统(legacy software system)的现状是再合适不过了。

今天下午做了一下午的代码评审，对象是一个运行了7年的遗留系统。会上除了几处明显的代码逻辑错误我发言指了出来外，涉及业务流程以及代码设计的问题，我 大多保持沉默。因为我清楚，即便我明确指出问题，可能也得不到修正。也许参与评审代码的其他同事也都知晓这些问题，只是觉得现在还不能去改…。

为何不能去改？回想当年第一版代码出炉时，它是那么的“出淤泥而不染”，而如今它身材臃肿，满身赘肉，千疮百孔，让人无处下手，看起来都不舒服。虽然它依旧能坚持工作，但终会有一天，它会轰然倒地，酿成大错。为何代码会腐化到如此地步？是怎么腐化的？这里谈几点体会。

* 第一版的设计和实现水准

我们知道：设计再完美的系统也终会有腐化的一天，时间才是最可怕的武器，它是一把无情的刻刀，不仅能使人老去，逻辑抽象世界的程序也不能幸免。但是你的程 序设计和实现的越完美，这个衰老和腐化的周期就会越长。一个糟糕的初始设计和实现，只会让系统更早的发霉、腐败直至被替换。我们的这个legecy系统在 最初的代码设计上就给后人留下了许多“糟糕的参照物”，在后人无以伦比的“复制粘贴”的技能下，这些糟糕的设计和实现就像癌细胞一样扩散到系统机体的每个 角落，让你无法重新建立其免疫系统。

* 没有测试做保障，不敢改

系统从诞生的那天起就使用“人肉测试”的方式，而且是粗粒度的系统功能测试。没有白盒的、可重复使用的、自动执行的单元测试集做保障，以致没有人敢对其轻举妄动，一旦出了问题，后果自负。另外人肉测试，精力和成本双重消耗，测试人员“耗”不起啊。

* 缺少崇尚“美”的文化

记得组织第一版企业文化中“美”这个成分还有立足之地的，但后期改版后，我们就再也看不到“美”了。码农们也是一样，在缺少了“俱美”之风的吹拂下，大家 都变得有些“丑陋”了，大家都开始摒弃“美”，认为代码只要能工作即可，美不美不打紧，于是工作就变成了修修补补，系统变得日益臃肿，臭气熏天。

* 进度之忧高悬

很多人会说：“如果给我充足的时间，我会让系统获得新生。但我没有时间，客户那边催的急，只能下次再重构、完善和优化了吧”。从这里不知大家是否看出了：“改善是没有的，下次却是永恒的”这一“道理”。在进度堪忧的情况下，我们多数时候选择了屈服，而不是自己的原则。

* 成本，老板们不得不面对的

“能用即可，新三年，旧三年，修修补补又三年”。如果你和老板谈重构、谈优化，那么这句话就是老板最好的拖词儿。成本永远是悬在老板头上的一把宝剑，老板们不能视而不见。因此，如果你要和老板谈重写遗留系统，那得需要多么强大的魄力和坚定的意志啊。

* 拷贝粘贴，最好的伙伴 or 最大的敌人

相信发明复制、粘贴以及剪切板的那位仁兄无论如何也没有想到，自己送给世界的礼物，竟然被码农们操练的如此熟练，应用在各种场合，尤其是Coding中。代码中充斥着大量重复代码信息，都是拷贝、复制和粘贴的结果，于是乎代码腐败的最大敌人就此出现了。

牢记：“千里大堤，溃于蝼蚁”。下一步该怎么办？去闻闻，你的代码腐化了没有！

2002年的Bug A与2008年的Bug B同时穿越到2013年，并在某个场合相遇了。

上周六，项目组本应以一个愉快的心情结束一天的工作的，但一个2002年的Bug A与另外一个2008年的Bug B同时穿越时空来到了2013年，并且恰恰在那时那刻（下班前）相遇了，于是项目组由放松变成了忙碌，由愉快变成了紧张，17：30的下班点也因此延迟到了凌晨1：30。

Bug A来源于2002年我们发布给客户的一版客户端API，严格来说称其为Bug不免有些冤，它只是遇到Bug B时才会被触发，其只是在处理机制上缺少一些容错的考虑罢了。Bug B才是名副其实的Bug，居然明目张胆地违反协议，擅自在登录应答包的Body尾部补了一个字节的“脏数据“，导致使用我们客户端API的某企业短信通知系统出现故障。

关于这次的“故障”，我想感慨的不是这次的Bug有多么的诡异难找，而是下面这几点：

* 生产环境中场景的复杂性与多样性

任你用例再多，测试人员经验再丰富，脑力再强大，也很难设想出如此之情形。往往我们在模拟环境中测试的都很好，开发和测试人员都手拍胸脯保证说：“没问题了”。但一到生产环境中，问题就像滚雪球一样越来越多，弄得大家焦头烂额。究其源头还是在开发人员这里，开发人员是第一责任人。已经离职的制造出这两个Bug的“前辈们“肯定不会想到，他们的Bug居然穿越到2013年相遇了，否则我相信他们在当时一定会认真对待代码的。

* Bug是藏不住的

通过此例可以让我们看到：Bug终有一天是会暴露的，是藏不住的。这“潜伏”了10多年的问题不也在这次事件中暴露出来了吗。所以说我们写代码的时候，一定要心中有“追求0bug”的理想和目标，严格要求自己和自己的代码，采用各种手段，如代码评审、单元测试、持续集成、自动化的模拟环境验收测试等对所写代码进行“残酷”的打磨和考验，让Bug遛到生产环境的机会尽可能地小。

* 版本的变更管理有漏洞

这又是一次在产品升级后导致的“故障”，原因在于没能完整的识别出这次升级带来的所有软件变更。其少引发Bug B的那行代码的“作用”没能识别出来。这的确是个难题，如果不是原开发人员或评审人员“自发”上报此处的变更，这个变更太容易淹没在代码海洋中而丢失了。目前似乎也没有太好的办法。如果未来能有一种自动识别版本间代码不同且能识别出差异代码的语义变更的工具，那么我相信这款工具一定大卖。