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

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

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

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

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

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

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

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

* 缺少崇尚“美”的文化

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

* 进度之忧高悬

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

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

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

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

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

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

10月中旬，有人在Quora网站上发起一个调查：“程序员职业生涯中最难的事是什么？”，调查结果让人实感意外。世界范围内的程序员同胞们普遍认为： “命名是让大家感觉最困难的事情”。对于主流的欧美程序员尚且如此，对于英文非母语的中国程序员来说，苦逼程度可想而知了:(。

虽说中国程序员大多也都学了10年以上的英语了，但能“地道”的表达和书写甚至是选词的程序员们比例却不高。而在编写程序的过程中，给变量、常量以及函数命名即意味着我们要选择恰当地道的词汇或缩写。

事实证明，任何事情经过中国人民的加工，就会呈现出意想不到的效果，于是我们有了Chinglish，有了“中国式”的命名。就此，我特地花了些时间翻阅了下面几个项目组的源码，总结出了一些“中国式”命名的门道，这里也说道说道^_^。

一、万能的动词

通过阅读代码中的一些命名，我发现了代码中经常出现的一些动词堪称“万能”，这些动词包括：handle、do、process、check、collect等。无论对象是什么，你只要像如下这么命名，中国程序员基本都能看懂或猜个八九不离十：

    process_xx  处理xx
    do_yy       做yy
    handle_zz   处理zz
    check_xx    检查/校验xx
    collect_xx 收集xx

二、标志/类型代言人

在项目源码文件中，你会变量声明或结果体声明中看到太多的xx_flag或xx_type。xx_flag被大家“公认为”各种标志的代言人了；xx_type也好不到哪去。

    route_flag
    protocol_flag
    msg_flag
    session_flag

    msg_type
    check_type
    command_type
    session_type

三、字面意直译式

比如我们要声明两个变量，一个的意思是“是否打开消息过滤”，另外一个“是否关闭消息过滤”。对于中国人来说，打开/关闭最直接对应的就是open/close，于是就有了这样的变量命名：

    is_message_filter_open
    is_message_filter_close

其实一般认为更地道的方式应该是：

    is_message_filter_on
    is_message_filter_off

再举个例子，我们的系统要处理一种中文名为“长短信”的对象，于是直译过来就是：long_sms。但其真正的英文术语应该是Concatenated SMS。

四、中文拼音式

在国内做行业解决方案，不可避免会遇到各种领域词汇，比如我们处理的一种业务称为农信通。估计是开发人员没能找到其对应的英文翻译，于是乎用上了我们的看家本领 – 拼音。

    nxt_url  农信通地址

这样的例子是否似曾相识呢！

五、单词“选秀”

采用这种方式的程序员应该是更具“责任心”的，至少他/她知道去查查英文词典^_^。

于是乎有了dispense_message、cache_overstock等变量命名。显然他是在字典的单词选秀中随意找到一个“顺眼”的、意思还算相近的单词就挑了出来。显然dispatch 、overflow要比dispense、overstock更地道和准确。

六、尾声

以上的“实例”确是从我们项目的代码中“挖掘”出来的，希望只是个案。面对这样的命名bad smell，我们是否有解决方法呢？没有捷径，语言的感觉是要一点点的去找的，个人觉得一个最行之有效的方法就是去看那些英语地道的程序员编写的代码，留 意他们是如何命名的。比如看一些著名欧美程序员的开源项目代码。另外对于行业特定领域，尽量用经过认可的英文翻译结果来命名。

不可否认，英语是编程领域的主流语言，包括中文在内的以其他语言为编码语言的编程语言十分罕见。对于欧美程序员来说，这是天然的优势；而对于其他非欧美国家的程序员，尤其是中国程序员来说，在走向“地道”的路上还要付出很多才行。