code_review

简介

• 代码评审

什么是 Code Review

• Code Review 翻译成中文是代码评审，具体的定义可以看 wiki。这篇 wiki 介绍说 Code Review 在帮助团队找到代码缺陷这件事上作用巨大：“代码审查一般可以找到及移除约65%的错误，最高可以到85%”。实际上， Code Review 的好处远不止这一条，它至少能在以下三个方面帮到我们：
  • 传播知识。相信很多人第一次提交 Code Review 都有类似的经历：短短几百行代码，却被提了密密麻麻几十条 comments，更新了十多次代码，才最终被 accept 。其实当代码被 accept，提交代码的工程师通过这次 review 就学习到了代码规范和很多好的实践。同时，通过 review 更资深工程师的代码，年轻的工程师也更直观地学习架构和编码；另外，工程师之间也可以通过 review 代码来共享项目知识，看代码实现在绝大多数时候是了解项目的最好方式。
  • 增进代码质量。这点也很容易理解，有经验的工程师可以在架构设计、代码细节等各个方面帮助到初学者。不同工程师也会有知识盲点，互相 review 进步也很快。另外，被 review 的代码质量更高还有一个很多人注意不到的心理因素：在状态不佳的时候，工程师难免会匆忙写些“潦草”的代码，但是当你知道自己的代码会被review 的工程师提交 comment 打回来，自然会更仔细些 :
  • 找出潜在的 bug。这是大部分团队进行 Code Review 的目的。就像上面提到的，Code Review 在这方面效果不错。其实我认为大部分代码 bug 应该由单元测试，功能测试，性能测试和回归测试来保障。不过由于静态分析不理解业务，另外有些 bug 在测试中并不容易复现，这两种情况下，经验丰富的工程师来 review 代码就尤其重要了。

Code Review 不应该做

• Code Review 应该讨论的是功能实现，架构设计，代码质量，不应该做以下两件事情
  • 检查代码风格和编程规范。除了新人，其他工程师提交的代码不应该通过 review 来确保代码风格。这里所说的代码风格包括但不限于：命名规范、代码缩进、注释和文档等等。你可以利用 IDE 或者其他工具来保证编程规范和代码风格的统一。如果你在制定团队的代码规范，可以 follow Google Java Style 或者 Facebook Coding Standards 。在这里我推荐好好看看 Facebook 的规范，因为 Google 的代码规范告诉你应该怎么做，而 Facebook 的规范解释了为什么要这样做，以及在什么情况下需要权衡。
  • 检查常规的 bad smell 和代码 bug 。《重构》 和 《Clean Code》 对代码 bad smell 都有非常详细的描述。团队的工程师应该熟读这两本书，避免这些 bad smell，比如：重复代码、过长函数、过大类、过于亲密的两个 classes 等，你可以利用 IDE 和静态代码检查工具 checkstyle、 findbugs 和 pmd 来帮你检查出这些问题。同样，代码中的大多数 bug 也不应该在 Code Review 阶段来发现，你应该通过静态工具、单元测试、集成测试和性能测试来发现它们

如何提高 Code Review 的效率

• 选用合适的工具。

  • 我用过 Phabricator、Gerrit、Gitlab 来 review 代码。这里推荐使用 Phabricator ，就不过多介绍了，可以看 这里 的讨论。

• 每次只 Review 少量代码。

  • 新人经常犯的一个错误，花了两周甚至更多的时间写代码，然后又花了一些时间做测试，等他们自己觉得“大功告成”才敢自信地提交 review，殊不知，这个时候提交的 review 几乎没有什么意义。一方面，对于提交 review 的工程师来说，辛辛苦苦开发测试了两三周，就等 review 完成后 release 了，这时候如果收到各种需要修改代码的意见，心里难免会有抵触情绪，尤其是 review 的结果是架构需要改动，代码需要大面积重写，内心一定是崩溃的。另一方面，代码审查者如果面对数千甚至上万行代码，需要理清项目架构都需要花费大量时间，强行 review 这种代码，争论、修改、测试代码，很可能 一周甚至更长时间都完成不了 review，结果就是双方都痛苦不堪。在实践过程中，我们认为，频繁 review 代码并且每次只 review 少量代码非常重要，我自己认为 reivew 不超过 500 行代码比较好。

• 明确职责。

  • Review 过程中经常遇到的一个问题是 review 响应不及时。比如 assgin 给了工程师，工程师没有及时 Review，或者提交 review 的工程师没有及时响应修改意见。造成这种现象的原因大致有这么几种：工程师没有及时处理 review 的习惯；review 工程师需要项目的领域知识等。解决方法也很简单，Review 是项目开发的一部分，进度由开发工程师来负责，这样，Code Review 如果不顺利，应该由提交代码的工程师负责推动，如果需要讲解代码，提交代码的工程师应该主动走到 reviewer 工位上，说说背景知识和代码逻辑。也就是说，如果沟通受阻，工程师应该更积极的面对 reviewer ，毕竟大家是在花自己的时间来帮助他。

• 整理 checklist。

  • 如果你回顾犯过的编程错误就会发现，在某个阶段自己容易犯类似的错误。其实上，团队里的工程师也有这种情况。刚入门的工程师会出现 API 误用；刚加入团队的工程师对编码规范需要一段时间来适应；有些工程师在代码命名上总会犯同样的错误；也有一些工程师搞不清楚并发编程；还有工程师甚至常常写面条式的代码而不自知。如果每位工程师有自己的 checklist 来记录这些问题，定期回顾自己是不是还在犯类似的错误，他们的水平就会很快提高，至少不容易重复已经犯过的错误。同样，团队也需要积累 Code Review 的 checklist，刚开始，这个 list 可能非常初级，会有一些常见的 bad small，甚至代码规范的内容。不过没关系，相信随着团队成员能力的提升，这个 list 慢慢会集中在设计方面，比如编写代码的工程师有没有考虑到代码可维护性、扩展性和性能等等。

• 完善CI/CD设施。

  • 很多团队不愿意做 Code Review，其实和不愿意做单元测试、集成测试原因一样，这些团队的CI/CD 工具不成熟，每增加一个不直接产出“功能代码”的步骤就会增加工作负担。其实根本原因是工程效率工具的缺失。

• 培养工程师的能力。

  • 还有一个比较常见问题是，有些新人面对被 review 代码往往提不出问题。这个时候就需要工程师提升自己的能力。如果平时有积累，面对等待 review 的代码，即使不能面面俱到，也能提供不少有价值的意见，比如整理学习 Restful API 知识，在评审 Http 接口代码时就会是专家；掌握了 Spring 框架，Guava 等工具类，也能在很多时候提出很好的建议。慢慢地积累更多经验后，这些工程师就能提出更多业务、设计方面的意见

注: CI/CD设施

“CI/CD” 是持续集成（Continuous Integration）和持续交付（Continuous Delivery）的缩写，是软件开发中的一种流程和方法论。它旨在自动化和简化软件开发、测试、部署和交付的过程，从而提高软件交付的速度和质量。

持续集成（Continuous Integration，CI）：
持续集成是指开发团队将他们的代码频繁地集成到共享的版本控制库中，每次集成都会触发自动化的构建、测试和代码质量检查。这可以帮助团队尽早地发现和解决代码集成导致的问题，确保代码在整体上保持稳定和可工作的状态。CI 可以减少代码集成时的冲突，并鼓励更频繁地提交代码，以便更快地发现和修复问题。

持续交付（Continuous Delivery，CD）：
持续交付是在持续集成的基础上，自动化地将可工作的、经过测试的代码交付到一个类似于生产环境的环境中。这种做法可以确保在每个阶段的开发过程中都存在可部署的代码，从而使团队随时都能够将新功能、改进或修复部署到生产环境中，而不需要复杂的手动步骤。

持续部署（Continuous Deployment，CD）：
持续部署是持续交付的一种更进一步的扩展，它是指将经过测试的代码自动发布到生产环境中，以实现实时或几乎实时的部署更新。这需要高度的自动化和测试覆盖率，以确保新的代码变化不会破坏现有的生产环境。

综上所述，CI/CD 是一种在软件开发过程中通过自动化和持续的方式来集成、测试、交付和部署代码的方法，旨在提高软件质量、降低风险，同时加速软件交付的速度。这种方法对于现代软件开发中的敏捷和迭代式开发非常重要，它可以帮助团队更快地交付新功能、修复错误并响应市场需求。

注: checkstyle

Checkstyle 是一个用于静态代码分析的工具，用于帮助开发团队在代码编写过程中遵循统一的代码风格和最佳实践。它可以在代码编写的早期阶段发现潜在的代码质量问题，从而提高代码的可读性、可维护性和稳定性。以下是关于 Checkstyle 的详细解释：

功能和特点：

• 代码风格检查：Checkstyle 可以根据预定义的代码风格规则，检查代码是否符合规范，例如缩进、命名约定、括号使用等。
• 代码质量检查：它可以检查代码中的各种问题，如未使用的变量、未使用的导入、冗长的方法等。
• 配置灵活：你可以根据团队的需求和偏好，自定义和配置各种规则和检查项。
• 支持多种编程语言：虽然最初是为 Java 设计的，但 Checkstyle 也可以用于其他编程语言，如 C、C++、C#、XML 等。
• 命令行和集成：Checkstyle 提供命令行工具，也可以与常见的集成开发环境（IDE）和持续集成工具（如 Jenkins）集成。
• 可扩展性：你可以编写自定义的 Checkstyle 规则和检查器，以满足特定需求。

使用示例：
以下是一个简单的使用 Checkstyle 的示例。假设你有一个 Java 项目，你可以按照以下步骤进行静态代码分析：

1. 安装 Checkstyle：首先，你需要下载并安装 Checkstyle。你可以从 Checkstyle 的官方网站或仓库获取最新的版本。

2. 配置文件：创建一个 Checkstyle 配置文件，其中包含你想要的代码规范和检查项。配置文件可以是 XML 格式。

3. 运行 Checkstyle：使用命令行工具，运行 Checkstyle 并指定要分析的源代码文件或目录以及配置文件。例如：

   checkstyle -c my_checkstyle_config.xml src/

   这将对指定的源代码进行静态分析，并根据配置文件中的规则和检查项报告问题。

4. 查看报告：Checkstyle 将生成一个报告，显示代码中的问题、违反的规则以及建议的修复措施。

5. 集成到持续集成流程：你可以将 Checkstyle 集成到你的持续集成流程中，以便在每次代码提交或构建时自动运行代码分析，并生成相应的报告。

需要注意的是，Checkstyle 只是众多静态代码分析工具之一。在使用它之前，你需要了解团队的编码规范，配置适当的规则，并根据报告进行代码修复。同时，还可以考虑与其他代码质量工具、代码审查流程等结合使用，以提高代码质量和开发效率。

静态代码检查工具 findbugs 详解

FindBugs 是一个用于静态代码分析的工具，用于发现 Java 代码中潜在的 bug、错误和不良实践。它能够帮助开发人员在代码编写的早期发现潜在的问题，从而提高代码的质量和可靠性。以下是关于 FindBugs 的详细解释：

功能和特点：

• 静态分析：FindBugs 在不执行代码的情况下，对源代码进行分析，以查找潜在的问题和错误。
• 多种检查：它可以检查诸如空指针引用、资源未关闭、不良的异常处理、未使用的变量等多种问题。
• 定制规则：FindBugs 允许你配置和定制不同的规则，以适应你的项目需求和编码标准。
• 可视化报告：分析结果会生成一个可视化的报告，展示了发现的问题、问题的严重程度和建议的修复措施。
• 持续集成集成：它可以与常见的持续集成工具（如 Jenkins）集成，使代码分析自动化并集成到开发流程中。

使用示例：
以下是一个简单的使用 FindBugs 的示例。假设你有一个 Java 项目，你可以按照以下步骤进行静态代码分析：

1. 安装 FindBugs：首先，你需要下载并安装 FindBugs。你可以从 FindBugs 的官方网站或仓库获取最新版本。

2. 运行 FindBugs：使用命令行工具，运行 FindBugs 并指定要分析的编译后的类文件或 jar 文件。例如：

   findbugs -textui my_project.jar

   这将对指定的 jar 文件进行静态分析，并生成文本报告。

3. 查看报告：FindBugs 将生成一个报告，显示代码中的问题、问题的严重程度以及建议的修复措施。

4. 集成到持续集成流程：你可以将 FindBugs 集成到你的持续集成流程中，以便在每次代码提交或构建时自动运行代码分析，并生成相应的报告。

需要注意的是，FindBugs 是一个非常有用的工具，可以帮助你在开发过程中及早发现潜在的问题。然而，它并不是万能的，它只能发现静态代码中的问题，有些问题可能需要更深入的分析和测试来发现。在使用 FindBugs 之前，你需要了解规则和报告，以便理解其结果并决定如何处理问题。

静态代码检查工具 pmd 详解

PMD 是一个用于静态代码分析的开源工具，用于检测代码中的潜在问题、错误、不良实践和性能优化机会。它可以帮助开发人员在代码编写的早期阶段发现并解决潜在的问题，从而提高代码的质量和可维护性。以下是关于 PMD 的详细解释：

功能和特点：

• 多语言支持：除了 Java，PMD 还支持其他语言，如 JavaScript、Apex、PLSQL 等。
• 多种检查规则：它提供了多种内置的检查规则，用于检查代码中的不良实践、错误、性能问题等。
• 自定义规则：你可以创建自定义规则，以适应项目的需求和编码标准。
• 报告生成：PMD 生成可视化的报告，展示了发现的问题、问题的严重程度和建议的修复措施。
• 集成到开发环境：PMD 可以与常见的集成开发环境（IDE）集成，如 Eclipse、IntelliJ IDEA 等。
• 命令行支持：它也可以通过命令行工具在构建过程中运行，并将结果导出为文本、HTML 或 XML 格式的报告。

使用示例：
以下是一个简单的使用 PMD 的示例。假设你有一个 Java 项目，你可以按照以下步骤进行静态代码分析：

1. 安装 PMD：首先，你需要下载并安装 PMD。你可以从 PMD 的官方网站或仓库获取最新版本。

2. 运行 PMD：使用命令行工具，运行 PMD 并指定要分析的源代码文件或目录。例如：

   pmd -d src/ -R ruleset.xml

   这将对指定的源代码进行静态分析，并使用指定的规则集（ruleset.xml）进行检查。

3. 查看报告：PMD 将生成一个报告，显示代码中的问题、问题的严重程度以及建议的修复措施。

4. 集成到持续集成流程：你可以将 PMD 集成到你的持续集成流程中，以便在每次代码提交或构建时自动运行代码分析，并生成相应的报告。

需要注意的是，PMD 是一个有助于代码质量和可维护性的工具，但并不是完美的。它可以帮助你发现静态代码中的问题，但不能解决所有问题。在使用 PMD 之前，你需要了解规则和报告，以便理解其结果并决定如何处理问题。结合其他代码质量工具、代码审查流程和测试策略，可以更好地提高代码质量。

注: Phabricator 工具 详解

Phabricator 是一个由 Facebook 开发的开源软件开发协作平台，旨在帮助团队更高效地进行软件开发、代码审查、协作和项目管理。它整合了多个工具和功能，以提供一个综合的开发环境。以下是关于 Phabricator 的详细解释：

功能和特点：

1. 代码托管和版本控制：Phabricator 提供了代码托管功能，支持 Git、Mercurial 和 Subversion。团队可以在平台上进行代码提交、分支管理、代码合并等操作。

2. 代码审查：Phabricator 提供强大的代码审查功能，允许团队成员在提交代码之前进行审查和讨论。审查者可以提供反馈、评论和建议修改。

3. 任务和项目管理：团队可以在 Phabricator 中创建任务、追踪工作进度、分配任务给成员，并将任务组织成项目来管理整体项目流程。

4. 代码浏览：Phabricator 提供功能强大的代码浏览工具，允许用户查看代码提交的差异、历史记录、注释等。

5. 文档和维基：平台上的 Phriction 组件允许团队创建和维护文档、维基页面，以方便知识共享和团队协作。

6. 构建和部署集成：Phabricator 可以与持续集成和部署工具集成，支持自动化构建、测试和部署。

7. API 和扩展性：Phabricator 提供了强大的 API，使开发者可以自定义和扩展平台的功能。

8. 轻量级和高度可配置：尽管具备丰富的功能，Phabricator 仍然保持了一定的轻量级特性，并提供了丰富的配置选项。

9. 开源和社区支持：作为开源项目，Phabricator 拥有活跃的社区，用户可以获取开发文档、论坛支持等。

使用场景：

• 软件开发：Phabricator 提供了从代码编写、审查、测试到部署的一体化开发环境，适用于团队协作开发。

• 代码审查：Phabricator 的代码审查工具有助于提高代码质量，促进团队合作，减少代码缺陷。

• 项目管理：通过任务和项目管理功能，团队可以更好地组织和跟踪项目进度。

• 知识管理：文档和维基功能使团队可以共享知识、最佳实践和资源。

• 持续集成和部署：Phabricator 可以与构建和部署工具集成，支持自动化的持续集成和部署流程。

需要注意的是，尽管 Phabricator 提供了丰富的功能，但在实际使用中，根据团队需求可能需要一些学习和配置。如果你打算使用 Phabricator，建议查阅其官方文档以获得更详细的使用指南和配置信息。

注: Gerrit 工具 详解

Gerrit 是一个基于 Git 的开源代码审查工具，专门用于团队协作进行代码审查和管理。它提供了一个集中式的方式来处理代码审查流程，帮助团队更有效地合并和审查代码变更。以下是关于 Gerrit 的详细解释：

功能和特点：

1. 代码审查：Gerrit 的核心功能是代码审查，它允许开发人员将代码变更（提交）提交到 Gerrit 中，然后其他开发人员对这些变更进行审查和讨论。

2. 权限控制：Gerrit 具有灵活的权限控制机制，可以细粒度地控制哪些用户有权进行审查、合并或提交代码。

3. 集成 Git：Gerrit 是基于 Git 的，因此它与 Git 版本控制系统紧密集成，可以直接与 Git 仓库交互。

4. 线上评论：审查者可以在代码行级别提供评论和反馈，以便进行详细的技术讨论和修正。

5. 自动构建和测试集成：Gerrit 可以与持续集成工具集成，以自动构建和测试提交的代码，确保质量。

6. 审查工作流：Gerrit 支持多种审查工作流，如拉取请求（Pull Request）式和代码共享式。它使团队可以根据需求选择适合的工作流。

7. 可定制性：Gerrit 可以根据团队的需求进行定制，包括主题、插件、报告等。

8. 报告和统计：Gerrit 提供了审查的报告和统计信息，帮助团队了解审查的状态和趋势。

使用场景：

• 代码审查：Gerrit 最主要的使用场景是代码审查。团队可以使用 Gerrit 进行严格的代码审查流程，确保代码质量。

• 团队协作：Gerrit 促进了团队内部的协作，通过审查、评论和讨论，开发人员可以共同改进代码。

• 质量控制：通过自动构建和测试集成，Gerrit 帮助团队确保代码变更不会破坏现有的代码质量。

• 版本控制管理：Gerrit 作为一个版本控制系统，可以帮助团队集中管理代码库，确保代码的安全性和一致性。

需要注意的是，Gerrit 需要一些学习和配置，特别是对于团队来说，要设置好合适的权限和工作流程。如果你打算使用 Gerrit，建议查阅其官方文档以获得更详细的使用指南和配置信息。

注: gitlab 工具 详解

GitLab 是一个基于 Git 的开源代码托管和协作平台，提供了版本控制、持续集成、代码审查、项目管理和多个其他开发工具。它可以帮助开发团队更高效地进行软件开发、协作和交付。以下是关于 GitLab 的详细解释：

功能和特点：

1. 代码托管：GitLab 提供了强大的代码托管功能，支持 Git 版本控制系统。团队可以在平台上创建代码仓库、分支、标签等。

2. 持续集成（CI）：GitLab 内置了持续集成功能，允许团队将代码自动构建、测试和部署。它集成了运行测试、生成报告等功能，有助于确保代码的质量。

3. 代码审查：GitLab 提供了内置的代码审查工具，可以帮助团队进行代码审查、评论和讨论。审查者可以提供反馈，改进代码质量。

4. 项目管理：GitLab 具备任务追踪、问题管理、里程碑、项目看板等功能，支持团队管理项目和跟踪进度。

5. 持续交付（CD）：除了持续集成，GitLab 也提供持续交付功能，可以自动将代码部署到生产环境中。

6. 容器注册表：GitLab 集成了容器注册表，支持存储和管理 Docker 镜像，方便构建和部署容器化应用。

7. 集成第三方工具：GitLab 可以与其他开发工具（如 JIRA、Slack）进行集成，实现更好的协作和通信。

8. 自动化流程：GitLab 的 CI/CD 支持自动化流程，从代码提交到部署的整个流程都可以自动执行。

9. 自定义配置：GitLab 提供丰富的配置选项，允许团队根据需要定制开发流程。

使用场景：

• 版本控制：GitLab 提供了稳定和强大的代码托管功能，适用于任何需要版本控制和代码管理的团队。

• 持续集成和持续交付：通过 GitLab 的 CI/CD 功能，团队可以自动构建、测试和部署代码，提高交付效率。

• 代码审查：内置的代码审查工具有助于提高代码质量和团队协作。

• 项目管理：任务追踪、问题管理等功能帮助团队更好地组织和跟踪项目进度。

• 容器化应用开发：容器注册表和集成的容器构建功能使 GitLab 适用于容器化应用的开发和部署。

• 跨团队协作：通过集成第三方工具，团队可以更好地进行协作和通信。

需要注意的是，GitLab 提供了广泛的功能，可能需要一些学习和配置，特别是对于团队来说。如果你打算使用 GitLab，建议查阅其官方文档以获得更详细的使用指南和配置信息。