关于编码规范（二）
促使程序员对架构和设计进行思考
这样的编码规范就很少见了，呵呵。其实这些内容是不是应该放在编码规范当中也是有争议的。不过我个人认为，不但应该放在编码规范中，而且应该是编码规范中最重要的部分。编码规范的本质和作用是什么，就是让代码更具弹性，更具可维护性。而架构设计对这个方面的影响力是最大的，没有理由不在编码规范中进行说明和规定。如果说命名规范或是其他的某种具体实践方法是“地方法规”，那么设计原则就是“宪法”。“宪法”决定了整个国家的法律框架。
如果不能在设计原则上达成统一和一致，即便是大家严格的遵守上述两个层面的编码规范，写出来的代码也极有可能是“貌合神离”。
但是一个模块的设计是否守遵循了特定的设计原则，或者在多大程度上符合设计原则的约定，是不好定出指标，也无法进行量化的。这可能也是一般编码规范中不包含设计原则的原因。每个人对设计原则的理解和领悟不尽相同。因此即使编码规范中包含了设计原则，怎样执行也是一个很伤脑筋的事情，有时还需要接合流程来进行实施。设计原则以及如何贯彻设计原则又是超出本文范围的两个话题了，有机会我会在其他文章中进行专门讨论。设计原则，建议可以直接参照《敏捷软件开发：原则、模式与实践》一书。
编码规范的贯彻实施
好的编码规范还只是一个开头，如果不能贯彻实施下去，那也只是一纸空文，没有任何用处。但要真正贯彻下去也不容易，毕竟代码不像一般的工业产品，可以量一下，称一下。我见过太多的项目，编码规范写得很好，但到了实际的代码上就完全是另外一回事了。也有一些是项目做到后期，代码维护的问题暴露出来后才开始实施和推行编码规范的，搞得所有人都异常的痛苦。要在以前的代码上改点东西，新代码按编码规范来写吧，混在旧代码中看起来很异类；把旧代码也按编码规范来重构了吧，一搞起来就无边无际了。所以推行编码规范一定要趁早。改掉一个坏习惯的成本绝对要高于养成一个好习惯。何况编码规范不是个人努力就可以了，是整个团队的事情。
在贯彻编码规范方面，我曾经工作过的一个开发团队有个很好的方法，说来也简单，就是review。每周划出固定的时间，轮流review开发团队中每个人的代码，一般一次一个人。找个有投影的会议室，被review的人在上面讲一下大致的流程和进行一些必要的介绍，其他三四个人在下面看。看到有问题了就讨论，确认是一个缺陷后就记下来，下去再修改。这样不但可以发现绝大部分的命名方面的问题，还可以发现不少架构设计上的问题。
这个方法虽然简单，但是很有效，关键是要持之以恒。由其是在新的团队里，在项目刚开始的时候实施。看似比较费时，其实是磨刀不误砍柴工。
我现在的团队，也采用了这一方法。因为是新成员，新团队。所以这个代码review的环节特别重要。在review代码的同时，其实也让大家熟悉了彼此的代码，不至于一个人的代码只有那个人能维护。而且review的过程也是一个大家一起学习的过程，可以交流很多的思想和经验。记得刚开始的时候，每周要review一天，很吃力。后来变为半天，上午周会，下午review。最后变成合并到和周会一起。
经过最开始的适应期以后，按编码规范进行编码就会变成很自然的事情，代码到了一定的规模后，新加进来的同事，也很容易被“同化”，这样就形成了一个良性循环。
在实施编码规范时，有一些团队使用“罚款”的方式来推行。如果发现有违反编码规范的地方就进行处罚。我个人很反感这种方式，编程本来是一个很愉悦的过程，这么一来就变成了一个战战兢兢很难受的事情了。就像我在谈过程改进时说的，从某种程度上来划分，开发过程可以分为两类：一类认为开发人员是积极主动的，因此它会减少对开发人员的约束，让开发人员发挥自己的热情和潜能；另一类认为开发人员是懒惰的，因此它通过定义详尽的流程，文档，事后评审，来对开发人员进行约束。编码规范在某种程度上也是这样的，有些是为了帮助开发人员写出更好的代码，它提供指引，提供参考，进行善意的约束，但最大限度的保留编程本身的快乐；有些则充斥着硬性规定和霸王条款，在这样的编码规范下写代码，编程的乐趣自然是遗失殆尽。