史上最烂的代码

其实本没有什么代码是 “史上最烂” 的，要有也只有 “史上更烂” 的，我想随便说说这个话题，也是源自豆瓣的一个讨论。事实上，系统复杂了被骂代码烂是一件司空见惯的事情。当然，也有一些短小的代码片段，就足以看出代码作者是个不怎么样的人。

布尔类型的使用是很容易变成最烂代码的：

有一些毫无意义的注释：

更无意义的是这样的变量命名：

也有人说，最烂的代码片段应该是这样的才对：

还有曾经被骂到遍体流脓的 12306.cn，代码节选：

还有 JavaScript 的烂代码，这实在太多了，就不贴了。越灵活的语言，越难驾驭，超级烂的代码就越容易见到。

Tiago Fernandez 做过一个投票，选举最烂的 Java API：

公式是：score = (I can live with) + (Painful * 2) + (Crappy * 3) + (Hellish * 4)

结果，你猜到了吗？

Java 的框架多、语法严格，对于限制那些要来搞破坏的程序员确实有帮助。但是真要搞破坏，要限制还是限制不住。以前我接触过一个 Portlet 扩展类，一共好几千行，当时觉得这代码已经够烂了。可是后来我看到了 5000 多行的存储过程，还有 7000 多行的 jsp 页面——我以前以为 Java 程序员的破坏力要远远小于 C/C++程序员。看来，也不尽然。

我的经历中接触到的烂代码，最常见的大概包括下面几种：

• 一些命名的恶习，比如 “cptct” 这种缩略语缩略到几乎是密码电报的方法名，大概是受到 Basic 毒害，即便是早期的 Visual Basic 版本也在代码中强制实施了一些约束（如变量名的长度、模块中允许的变量数和模块的大小）。
• 早些年的 web 项目（甚至包括现在的一些小公司做的 web 项目），不懂解耦、不会分层，逻辑全部揉在一起，一坨屎一样。页面模板直接访问数据库、样式代码散落在世界各地，HTML 写死在各种逻辑里。
• 在某些程序员眼里，“复用”==“继承”，只要有可复用的属性、公共的方法，就设法用无敌霹雳继承大法来解决，也不管适不适合，一级又一级，最后一定是一棵伟岸无边的继承树。
• 无穷无尽的工具类。这类代码比继承大法的代码好不到哪去，XXHelper、XXTools 这样的静态类满山遍地都是，但是复用的眼光倒是比只会继承多了一条路……
• 不会用标准库函数、封装好的类库。我见过好几个这样的程序员，对于 Integer、Long、Double 这些数值对象类型的定义、方法几乎完全不了解，倒是对 String 很熟悉，所有的转换、校验，全部都转换成 String 以后完成，完成后再转回来。
• 上帝类。本质是对类的职责单一不理解。用 Java、C++的程序员写出上帝类也就罢了，今年我居然听朋友说到一个写 Ruby 的有相当工作经验程序员写出一个巨大的上帝类来……
• 满大街乱跑的设计模式。本质是过度设计。好好一个 “new Template()” 非要引入工厂，再搞一个策略模式、模板模式，不过瘾，最后加上注解来实现……
• 大部分的 JavaScript、CSS。不解释。

今天有同事说，代码之所以成为烂代码，很大可能是写代码的人会遇到比后来读代码的人多得多的问题，虽然写代码的人解决了大部分的问题，但是剩下的问题还是足以让代码遗臭万年。不过我不这么看，我看到过年份比较早的 VB 代码、还有 Delphi 代码，虽然都是界面开发用的，虽然很多理念远远不及今天，代码依然清晰易懂。

有的程序员说，工期紧、项目重，领导催得我天天吐血，迫不得已我写出了烂代码。客观原因千千万万，我确实无话可说，毕竟在物质文明还非常虚弱的时候，还是不要扯精神文明的蛋。但是，优秀的程序员是有追求的，而人是会麻木的，总是把项目压力挂在嘴边的，给一个宽松的限期也不见得能如何。

还有的程序员说，唯物辩证法告诉我们，任何事物都有两面性，所以我们要学习烂代码中好的设计，并且把糟糕的设计引以为戒……我说，得了吧。烂就是烂，把屎放在冰激凌蛋筒里也还是屎，那么矫情干什么？

有很多程序员总有一种推倒重来的冲动，特别是看到烂代码的时候。我也曾经如此。其实这是危险的。况且在很多情况下你的重写未必有他原来的烂代码好。也许你能解决其中的 30 个问题，却引入了 50 个新问题。重构还是要在业务模型和流程清晰的情况下尽量小改动、划模块入手，大开大合总是危险的。

总说十五年前吃过多少多少苦的程序员我一点都不佩服，我佩服的是在十五年前那种条件和观念下，依然能够写出现在看来都让人无比舒坦代码的优秀程序员。不写烂代码就是爱惜生命、节约资源、保护地球，写好的代码就是一个程序员的素质，没有那么多理由可以讲。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》