# 代码审核指南

## 目录
*   [介绍](#intro)
*   [代码审核者应该看什么?](#look_for)
    *   [挑选最好的代码审核者](#best_reviewers)
    *   [面对面审核](#in_person)
*   [参考](#seealso)

## 介绍 {#intro}

开发者写完代码后,让其他人来审视这些代码,这个过程称为代码审核(译者注:也译为“代码评审”或“代码审视”)。

在 Google,我们通过代码审核来保证代码质量,进而保证产品质量。

此文档是 Google 代码审核审核流程和政策的规范说明。

本节对代码审核过程作简要介绍,后面的两篇文档会做更详细的说明:
-   **[怎样做代码审核](reviewer/)** :针对代码审核者的指南。
-   **[开发者指南](developer/)** :针对 CL 提交者的指南。

## 代码审核者应该看什么? {#look_for}

代码审核者应该关注以下事项:

-   **设计**:代码是否设计良好?这种设计是否适合当前系统?
-   **功能**:代码实现的行为与作者的期望是否相符?代码实现的交互界面是否对用户友好?
-   **复杂性**:代码可以更简单吗?如果将来有其他开发者使用这段代码,他能很快理解吗?
-   **测试**:这段代码是否有正确的、设计良好的自动化测试?
-   **命名**:在为变量、类名、方法等命名时,开发者使用的名称是否清晰易懂?
-   **注释**:所有的注释是否都一目了然?
-   **代码样式**:所有的代码是否都遵循[代码样式指南](http://google.github.io/styleguide/)?
-   **文档**:开发者是否同时更新了相关文档?

详情可参见文档:[怎样做代码审核](reviewer/) 。

### 挑选最好的代码审核者 {#best_reviewers}

一般来讲,你一定会找*最好*的代码审核者来帮你审核代码,这个人应该在你期望的时间内有能力对审核工作负责。

如果若干人能对你的代码给出正确的反馈意见,那么最好的审核者就是这些人中最有见地的那个。他可能是你正在修改的代码的原始作者,也可能不是。有时候,一个代码审核者无法覆盖整个 CL,他们只能审核其中一部分,这种情况就需要多位审核者(这并不意味着当一个审核者能覆盖所有代码时,就只需要一个审核者),以确保能覆盖所有代码。

如果最理想的代码审核者无法帮你审核,至少应该抄送给他(或者把他加到可选的审核者名单里去)。

### 面对面审核 {#in_person}

如果你正在与一个人结对编程,你的伙伴已经对代码做过细致审核,那么这段代码可以认为是审核通过的。

你还可以与代码审核者进行面对面审核。当有疑问时,审核者提问,开发者回答。

## 参考 {#seealso}

-   [怎样做代码审核](reviewer/):针对代码审核者的指南。
-   [开发者指南](developer/):针对 CL 提交者的指南。