如果没有设计，团队中的成员按照个人的喜好去编码，那么这些代码必将走向混乱，成为难以维护的代码。无论是通过什么样的过程，团队都应该在代码上达成一些共识，形成一些约束，比如代码格式应该是怎样的，url命名是什么样的，代码有哪些结构，单元测试怎么写等等。如果只是产生共识，作为口号提一提，这些共识在开发过程中很难得以贯彻。怎么办呢？从我这两年的工作经验来看，有一下几点。

　　显式的表达约束

　　必须显式的表达代码的约束，而不是隐式或笼统的。每个程序员都想写出好的程序代码，但是每个人心中的好都不一样，如果不显式的明确的提出什么样的是好，什么样的是不好，那么最终写出的代码肯定是乱七八糟的。如果在软件设计的时候对编码提出了一些约束，那么就要把程序员们召集起来，逐一的明确的向大家传达这些约束，甚至于把这些约束写入文档。

　　人工代码检查

　　代码就像是农田，你不常去除除草打打药，它就要长杂草生病。而这些杂草和病症往往是隐藏在代码的内部的，测试人员通过外部是看不出来的。因此，必须有一个成员主动的去检查代码，看看当初设计时定下的约束，指导思想等有没有被保证和贯彻。发现了问题，要尽早的提出来解决掉，告知其他人，避免类似情况发生。这个世界上优秀的软件代码，必定都是被很多人阅读过除草过很多遍的。

　　用工具限制违反约束的行为

　　人工的速度毕竟比较慢，很难反复的多次的对大规模的代码做检查，而工具在某一些方面可以弥补这种不足。比如，如果当初约定单元测试代码必须被维护好，单元测试覆盖率必须达到多少，那么就可以再持续集成的时候去做测试，覆盖率检查，并报警，阻止测试失败覆盖率不足的代码发布出去。在这样的工具的倒逼之下，才能保证当初的约定得以贯彻。

　　结对编程，逐渐在整个团队中形成共同习惯

　　让约束成为习惯，才是最后的解决之道。如果人人习惯于写出符合规范的代码，而不是先写出不符合规范的代码在被查出来后再修改，那么这才是规范真正显现威力的时候。结对编程，通过程序员之间的互相监督学习，让结对的人逐渐形成统一的习惯，然后更换结对，最终让整个团队形成共同的习惯。这个过程是漫长的，但是绝对是值得的。