本文是对谷歌代码审查指南的总结。这篇文档发布在谷歌的工程实践仓库上，从仓库命名上来看，这个仓库是一系列工程实践文档，不过目前只更新了这一篇，希望谷歌能够持续填坑，贡献出更多的内容。
    指南分两部分，分别从代码提交者和审查人的角度，描述了如何进行代码审查。其中既有指导性的战略原则，也包括了一些具体可操作的战术性动作。

    CodeReview.xmind

    为了做好代码审查，google将代码的修改切分成若干”CL“，作为审查的基本单元。具体审查步骤如下：

    1. CL由代码提交者创建，对CL的要求如下：
      1. CL应尽量小，一次只包含一个功能的改动。
      2. 要包含完整的测试用例，并且确保提交后系统正常运行。
      3. CL描述要写好：第一行做标题，标题与内容之间空一行，内容包含足够的信息
    2. 代码审查人收到CL后，应尽快进行审查，审查时间最多不能超过一天。要记住代码审查的终极目标是保证代码库整体质量稳步上升。审查时要遵循如下原则：
      • 用技术事实和数据说话，而不是个人喜好和意见
      • 编码风格要遵守代码规范指南，作者可以自由书写没有在规范中声明的部分
      • 有关软件设计并不是编码风格和个人喜好的问题，而是需要遵循一些基本原则，并且常常需要进行权衡
      • 如果没有指导原则可以应用，则需要看是否跟现有代码库保持统一
    3. 审查过程一般是先概览一下，看是否跟预期有较大的出入，再审查主流程有没有问题，最后详细审查每一行代码。过程中任意一步有问题应尽快打回。
    4. 审查内容包括系统设计是否合理、功能是否正确、复杂度如何、单元测试是否完备、命名规范、注释及编码风格。
    5. 审查发现问题后应尽快反馈，反馈时要注意态度友好，说明原因并尽可能给出建议。
    6. CL作者收到反馈后，应仔细思考反馈内容，修改相关代码使其合格。如需解释，尽量写在代码注释中，以便其他人参考，确实不必写在代码注释中的内容，可以写在审查工具中。
    7. 最后，如果CL作者和审查人意见冲突，要参照代码审查指导原则解决，实在解决不了的进行上报。过程要快，不能让代码审查严重影响了CL的提交进度。
    8. 特殊情况下，可以考虑简化审查步骤。特殊情况包括：
      1. 修复线上严重影响用户使用的bug
      2. 修复影响主版本发布的bug
      3. 处理政策/法律/安全漏洞等
      4. 硬性的截止期限临近，包括合同规定、延期会错失市场、发布周期很长。

    据说google内部有一个专门的reviewer团队，个人水平达到一定程度后才有资格进入。完整看下来，这是一个很完备的代码审查体系，要系统实践下来很不容易，现实中有太多干扰因素了：倒排工期、工程师文化的缺失、完备的编码规范和单元测试体系、原有工作方式的调整，甚至是组织结构的调整等等。
    不过，其中的指导原则和一些审查项很值得学习，这些即便不能用在代码审查上，也可以用在指导个人编码和自查的过程中。