|
代码评审是每一个组织都应该不可或缺的实践。 因为软件动态测试取代不了静态测试，测试工具也取代不了人工的逻辑判断。 但要更好地实施代码评审也需要遵循若干指南。比如：
就像文档评审前应先由QA（质量保证人员）进行审查，去除一些低级的问题，以使得评审能集中到更为重要的技术问题上一样，要进行代码评审的代码也应满足一些入口准则。如：代码是否具备一定的可读性、是否遵循编码规范等等。
代码评审虽然是个挑错的过程，但它并不是评审人员炫耀自己，取笑他人的场合。代码评审更多的是一种团队交流和学习的机会，参与代码评审的人（无论是评审人员还是被评审人员）都是平等的，大家在一起平等地交流，是为了让团队中的每个人变得更加出色。
代码评审虽然是不可或缺的实践，但也要考虑项目的进度、质量要求的实际。在资源有限，时间紧张的情况下，就需要明确哪些代码必须进行评审，哪些代码可以不进行评审。一般关键模块的代码评审不应裁剪。
为了便于代码评审的实施，应明确代码评审的时机。可选择的评审时机包括：代码编写完成前、单元测试前、代码受控前等。
原则上，所有人（不管他的职位有多高，技术水平有多牛）的代码都应进行评审。但在一些特殊的情况下，对于水平较高，经验丰富，平时代码缺陷率低的人员可以不进行评审。
原则上参与评审的人（无论他的职位有多低，技术水平有多差）都可以给出自己的意见。但，最终记录下来的意见还是以多数人认可为主。
评审人员给出的意见不仅是代码存在的问题，也可以是代码好的一面。评审意见只针对代码的编写，而不要侮辱代码编写者人格。
100行以内的代码评审是很容易进行的，也很容易取得效果；但是超出1000行代码的评审是很难进行，也不会取得好的效果的。 这正是： 代码评审不可少，遵循指南会更好 八个指南告诉你，尝试尝试好不好 参考书目：奔跑吧，程序员：从零开始打造产品、技术和团队，作者：[美]叶夫根尼·布里克曼，译者：吴晓嘉，出版社：人民邮电出版社 |
|
|
