1. 是否需要有代码规范
对于是否需要有代码规范，请考虑下列论点并反驳/支持：
Statement1 : 这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
这样的观点未免太过于肤浅且自我主义。
首先，之所以产生这样的结论，一方面是因为仅看到要团队成员自身去适应团队规范的不便性所带来的损失。
把目光放长远一点，每个人的compromise都会大大提高整体代码的规范性、整洁性与清晰度。
这样的代码无论对于复审、二次开发、调试测试、后期维护等来说都是十分有利的。
大家在同一个规则下编写代码，虽然增加了编写过程中适应规则的时间，但更值得一提的是，这种前期的coding adaption大大降低了后期的composing/reviewing adaption所需时间。
而后期对代码的审核调试，代码与模块之间的拼凑，这两个步骤如果没有前期的规范为基础，那磨合所需的时间会远远超出前期所浪费的时间。
而且前期的浪费是不过分需要人力脑力的，相反后期的浪费将要调用所有团体人员对代码进行解释、修改、审核等。
其次，产生这种想法往往是过于egoism的典型表现，仅仅考虑到自身的不便却忽视了软件工程是一个团体性的任务。
各个分量的局部最优拼凑出来的往往不是全局最优。在最优化过程中，而每个局部都reconcile其它元素才能达到团体利益的最大化，在软件工程中也是如此。
Statement2 : 我是个艺术家，手艺人，我有自己的规范和原则。
编程是一门艺术，这点不可否认。对于个人的编程而言，coding的规范和原则确实构成了展现代码特性的重要一环。
但正如上述1中所说，这是一个团队性的任务，而在这种环境下，编程的艺术更讲究和谐与一致。
如何让各个模块相互协调，让零散不一的零件组合成最终流畅运行的整体，以及让团队中的每一个大脑都能参与并以最舒服的方式进行brainstorm，这些才是团队编程中的艺术。
它与个人的狂想不同，在团队的编程艺术中，你需要作出一定的牺牲，舍弃原本保持的风格（当然这种舍弃也不是绝对的，团队间的协商可以最大程度减少它）。
更关键的一点，我们所舍弃的仅仅是外在的习惯，而编程艺术强调的不仅仅是外在表现形式，更多的是我们的逻辑思维、组织方式和奇思妙想。
从这一角度出发，我们实际上并没有舍弃自己的艺术。与其说是舍弃了自己的规范和原则，不如说是将自己编程艺术的本质用团队的语言做了一次不一般的演讲。
Statement3 : 规范不能强求一律，应该允许很多例外。
这一想法需要进一步的限制与说明，所谓的“例外”是什么样的例外？是在设计创新上的例外，还是在命名规则、模块设计等方面的例外？
若是前者，那团队自然不应进行限制，除非客户有具体明确的需求，不然任何能达到要求甚至超过要求的代码都是值得考虑的。
若是后者，那团队在初期必须要有明确的规范，否则会给后期的相互调用模块、复审代码、调试测试以及二次开发带来诸多不便，降低整体效率。
但后者也并不是否认了所有人的规范，前期的商榷过程是十分关键的，如何确定一个所有人都满意，最大程度减小每人规范舍弃的原则，这个问题值得前期认真考虑。
经过这种商榷后，诸多人的“例外”已经被包含进了团队规范中。在这一层面，团队规范并没有强求一致。
Statement4 : 我擅长制定编码规范，你们听我的就好了。
软工需要一个leader但不是专制主义者，正如前面所一直强调的那样，一个团队规范要能够最小化所有人的损失，而这样的专制明显无法达到要求。
一味地将个人的偏见强加至所有人身上难免会造成团队内部的不和谐，降低团队效率不说，更可能导致整个团队的分裂。
2. 代码复审
原文：http://www.cnblogs.com/kanelim/p/4842157.html