你的代码完成了吗？（之二）——可维护性和规范性

二. 可维护性和规范性

对于代码来说，这两个属性其实是紧密相连的。什么样的代码最好维护呢？当然是规范的代码了。再差的规范也要比没有规范强得多。

之前做对日项目的时候，日本人对于“规范”这个东西（他们称之为开发规约）要求的极为严格。一方面会制定严格的规范来供大家遵守，其中不仅仅会包括对命名、代码格式的规定，甚至还包括了每个控件之间的距离，代码的注释的格式，代码中的注释要达到什么样的比例，每种代码结构（循环、选择等等）要怎么写，什么时候应该加空行等等，一般他们的代码规范都至少会有10页左右的内容。另一方面，他们还制定了比较完备的流程来保证规范的执行，代码开发完毕，首先是要进行代码Review，然后是进行单体测试。这两个过程并非是在某些国内项目中，就是走个过场，在对日的项目中甚至还制定了标准，每千行代码中必须Review出多少个问题，必须要测试出多少个Bug，都是有数量限制的，如果达不到标准，除非有充分的理由，否则这个过程是无法通过的。

经过了这么多严格的过程之后，对日项目想要达到的目的就是“所有代码看起来像是一个人写的”。尽管这有些理想化，毕竟每个人处理问题的思路还是会有些不同，但仅就代码来说，的确看起来干干净净，就像是同一个人编写的一样。自然在维护的时候，看起来至少不会有太严重的问题。

相反，在某些国内项目中，对于代码规范的重视程度明显不够，很多代码中连最基本的缩进和命名问题都没有解决好，更别提每个方法的长度，类和接口的设计等问题了。有时，不得不对那样的代码进行修改的时候，我都会先把规范整理一遍，然后再开始修改。但是，就像破窗子理论一样，有时心情不爽的时候，根本就不会做修改，甚至还会加入更多的不符合规范的东西。（那种情况是极少的了，哈哈。而且我不会署名啊，偷偷地闪！）

由此看来，新编写的代码是否遵从了代码规范会给以后的维护和修改工作带来很大的影响。

可维护性体现在什么地方呢？我觉得就在于对现有的程序进行修改的时候，能否快速定位到问题所在，而且在读代码的时候，很容易就能理解代码所要完成的工作，那样才能够更快速有效地对代码进行修改。

在此必然会涉及到注释的问题，关于这个东西的讨论已经有很多了，我的观点是，如果能够用较好的命名和清晰的代码说明的问题，就可以不写注释了。相反，如果仅仅看代码无法理解的东西，尤其是业务上的知识，或者是业务流程上的一些特殊的要求，就非常有必要写上注释，否则以后维护的人就不明白其所以然了。而对于对日项目中规定代码中的注释率要有多少，就有些过分了。

对于自身来说，想要编写规范和可维护的代码，其实也不是很难的事儿，主要在于态度。记得当初我给公司的新人培训的时候，曾经说过：“我们应该编写什么样的代码呢？我觉得有一个原则，那就是别人在以后修改、维护你写的代码的时候，不会一边改，一边骂人，他***，这是谁写的鬼代码，让我有打人的冲动。”呵呵，玩笑而已，但还是能说明一些问题的吧。