我见过的最糟糕的程序代码

大多数的客户项目在任务完成之后都会很快的从记忆里消退，但有些，你一辈子都不会忘记。我要说的这个属于后者。

这事发生在很多年前，在一个相当大的公司里，公司名我就不说了。那个软件有一大堆程序，是一个商业系统的核心模块，由一个、单独的一个的小伙维护着，这个家伙不久前被炒了。

像这样的事情其实都很正常，一些公司通常会发现他们的一些关键性技术自始至终都保存在一个人的头脑里，当有事情发生时，就像现在这个人，你通常会经历一阵痛苦阶段去阅读他留下的东西，之后生活慢慢趋于正常。

这次有点不一样。

这个程序出了点问题，公司派了一个去修复这个问题，等他回来后发现精神有点反常，不是哭就是笑，嘴里嘟囔着什么“匹萨调用汉堡并且传入了包子”。

程序员的代码里通常体现着自己对幽默的理解以及对‘工作保密’这个词的认识。我们都听说过一些难以置信的故事，比如说公司辞退了某个搞技术的家伙后，结果被告知如不在48小时内向某个海外账户打入多少钱，会计软件将会自动删除所有客户记录。像这种的小伎俩相对而言还好处理 —— 假设这些传说的故事大多数都是真的，我还是很难相信，我从来没有在现实生活中遇到过这种事情。

这个家伙留下来的软件里没有任何的逻辑炸弹或下流的阴谋，编译很正常，除了有一个bug外，一切都工作的很好。但是，你需要想像一下：程序中的所有函数、变量名都是以食物命名的。匹萨，西红柿，泡菜，各种味道的奶酪，水果，蔬菜，酒，等等，一篇一篇，全是这样。里面唯一能让你马上知道意义的地方只有‘main’函数名和C标准类库的调用。

就这样，我接手了这个费力不讨好的烂摊子，努力的把程序恢复到一个可维护的状态。

说实话，这是一个极好的加密形式，只有拿到密钥你才能让这些“代码沙拉“变得有意义。一点一点的，我把这些函数名和变量名改成具有意义的命名，开始很麻烦，之后慢慢的变得容易些。

把已知的函数和源代码进行恢复要比对未知的代码进行反向解析容易的多，因为首先你要分清代码里哪些是程序，哪些是数据，而放在我前面的这些程序显然都是明文，所有这活儿并不是不可能完成，或者说是格外的困难，只是这活儿太乏味太无趣了。一旦你发现了某个变量可能应该给个什么样有意义的名字，余下的就是查找和替换。

另外一个问题是，代码写的太烂，事实上，这意大利面条式的代码比这些毫无意义的符号更让人困惑，等我把函数名和变量名都改回有意义的名称后，我开始把一大堆的代码重写，让它们易于理解、效率更高。

我始终没有弄明白他是否还有一套没有加密混淆过的代码，他可以使用一些‘混淆’脚本通过替换的方法把原始变量名混淆成这样。我很难相信一个人会在最初时就把代码写成这样，因为这对他自己也是一个巨大的挑战，这里肯定有一些高超的技术。

当然，如果你的脑子里还在想：你不能因为我的变量名没有什么意义就把我开除了(或应该招我回来改程序)，那你是在妄想，不管这个家伙的用意是什么，他的做法十分的错误(我很难想象他的前任老板还会推荐他)，不管怎样，这事儿让我乐了好几周。

本文是从 The worst program I ever worked on 这篇文章翻译而来。

译文：http://www.aqee.net/2011/03/28/the-worst-program-i-ever-worked-on/

 已同步至 wxy的微博