代码评审会议指引

                              
代码评审的目的
第一个目的：确保要发布质量可靠的代码，换句话说，它对于开发过程中的下个阶段是否应该提高代码的质量是个严峻的考验。代码评审能非常有效地发现所有类型的错误，包括那些由于不正确的结构引起的错误，那些不适合商业进程的错误，还有那些简单的冗余错误。这就是为什么它对于代码质量来说是个有效的试金石。
第二个目的：作为教学工具帮助开发人员学会何时并且如何应用技术来提高代码的质量、一致性和维护性。经过反复仔细地评估代码，开发人员有机会掌握不同的和潜在的更好的编码方法。
评审前准备
1、     确定评审代码的checklist；
2、     会议前两天通知评审会议时间、地点、人员及评审代码；

代码评审会议
1) 代码编写人介绍本次代码评审业务逻辑、设计思路、现有问题(10分钟)
2) 强调评审的特别关注点(5分钟)
4) 深入地评审代码(55分钟)
a)代码架构
b)数据结构、算法设计

c) 代码规范
d）异常、容错处理
5) 总结优点与改进点(10分钟)

评审结果跟进
     代码负责人在评审三天后提交改进报告于代码评审人员；

评审注意事项
代码评审作为代码分析方法中的一种，以参与者处理代码开始，评审过程仿佛被设计成证明谁是更好的程序员一样。代码评审常常会变成人身的攻击，在这里人们瞄准对象进行攻击；换句话说，编写代码的开发人员在被复查。更好的途径是采用学习的方法，所有的评审工作都被当作讨论的内容来讨论并向其他人学习。就是说这种方法应该是有教育意义的并且是开放的，除了具有创造力之外，还能感觉到它比以前的人身攻击更有挑战性。那意味着，你可以改变下面几个方面来使方法变得更好：

1、询问胜于陈述。陈述是带有指责性的。“你在这里没有遵守标准”带有攻击性－无论你是不是有意的。询问“你使用这个方法的理由是什么？”会发现更多的信息。明显地，问题不能以讽刺的或故意屈尊的语气提出；恰当的询问通常能使开发人员表明他们的想法，并且会因此而询问是否有更好的方法。
2、避免“为什么”的问题。尽管避免“为什么”的问题有时是非常困难的，但是它能充分改善说话的语气。正像陈述是带有攻击性一样—“为什么”的问题也是如此。大多数“为什么”的问题都能重述成并不包含“为什么”词语的语句，

而且结果是很有成效的。例如，“为什么你在这里不遵守标准……”与“在这里你违反标准的原因是什么”相比。
3、记住要赞扬他人。 代码评审的目的不是关注于告诉开发人员怎样才能改进代码质量，也没有必要让他们知道自己完成的多好。人类的本性是希望并且需要别人认可自己的成功，而不是表现自己的过错。由于开发是个具有创造力的工作，开发人员倾注了大量的精力在开发过程中，因此开发人员把它看得非常重要。这就需要称赞多于批评。

4、确保参照良好的编码标准。代码评审以公司内部的代码标准为基础。代码标准一般假设为共享的约定，开发人员彼此使用它来产生高质量，可维护的代码。如果你正在讨论的内容不在编码标准中，那么你首先需要使讨论的内容变为编码标准的条款。你应该有规律地询问自己正在讨论的内容是否在编码标准中。
5、确保讨论集中在代码上而不是编码人员上。关注代码有助于防止评审过程变为人身攻击。你不应该对编码人员的好坏感兴趣，取而代之，你应该注意产生高质量的代码。
6、记住通常有多于一种的解决方法。虽然开发人员编写出的代码可能会与你编写的不同，但这并不能说明它是错误的。我们的目标是产生高质量，可维护的代码。如果它满足那些目标并且遵守编码标准，那么它就是我们所期望的。