不要让人重构你的烂程序

上个星期主要工作是重构一个很重要的模块，先抱怨一下，这个模块没有注释，可以运行，完全没有可维护性，写得是相当的丑陋。

单是理解这个程序就花了我和一个同事整整1天，然后重构花了我4天。而且每天我为了这个模块的重构，居然打破了我的“程序员每天只需编程4个小时”的教条，我每天竟然要花6个小时在这个模块的重构和测试上，最终我在重构上大概花了30个小时，所以很多人说不要轻易重构代码，这里我想说的是重构他人的烂代码还不如自己重写。
但是经过上个星期的经历，这里再次总结一下什么是烂代码。
1. 没有关于重要代码的解释
2. 没有统一的名称的规范
3. 到处都是注释掉的代码（注释掉的代码会让读代码的人很痛苦，而且会让人觉得这个代码不是最终的成品，而是实验性的代码，或半成品）
4. 巨大的方法（我居然看到了一个超过1000行的方法）
5. 很在方法中很随意的加入代码
6. 过于愚蠢的API的设计 （如果要学习如何设计一个好的API请查看Qt API Design Principles）

上面第4点提到的，对于这个超过1000行的方法，被我改成的8个小方法，每个都不超过50行，而且这些方法的都具有复用性（因为每个方法很小，代码的可重用性开始指数增长）。为什么会有这种巨型的方法呢，其实就是程序员很多时候很随意的加入代码所造成的，而且他们满足于写出“可用”的程序，而不满足于写出“优雅”的代码。

很多人都停步于烂代码，因为他们认为他们的烂代码可以用，很多程序员都会犯这样的错误。他们很理直气壮的对我说，看我的代码很好用，可用的代码不代表不是烂代码，其实这些代码都金玉其外，败絮其中。人们常说，程序员都是从写烂代码开始，然而也许写出所谓的“内聚性、松耦合、零重复、封装、可测试性、可读性以及单一职责”的“好代码”需要长时间的锻炼，但是最坚持最简单的代码规范却是每个程序员可以做到的，这就是避免烂代码的最好方法。

其实我们常常并不要求人们写出“优雅，精妙”的代码，我们的要求不高，程序员只需要坚持“简单性”，写出符合“代码规范”简单的代码即可。