代码审查在开发优秀软件的过程中常常被忽视，但实际上它非常重要。
一开始可能看起来既艰难又让人困惑，但其实没你想的那么难。
这篇帖子对于开发者而言，简要概述了11种实用的代码审查方法和策略。
这将帮助你提高代码审查技巧。
……
或 ...
（省略号）
🎯 你知道什么是代码审查吗？在深入探讨这些要点前，先了解一下代码审查是什么，更符合口语化表达。
代码审查是开发人员互相检查对方的代码的过程，以在合并或发布之前提高其质量。
术语 code review 可以指的是很多事情，从简单地看看朋友的代码到一个20人的会议，逐行详细分析代码。
主要涉及两个角色：
Reviewer：负责阅读代码并决定何时将其合并到团队代码仓库中的那个人。Author：编写代码并通过拉取请求提交审阅的那个人。
审查在审阅者 批准 了更改后结束。你会看到 LGTM，这是“看起来不错”的缩写，意思是一样的。
如果你对了解更多感兴趣，GitLab 的这篇关于什么是代码审查？的文章是一个很好的开始点。它列出了优点和缺点，介绍了几种方法以及最佳实践。
让我们在做代码审查时考虑一下这些可以参考的小技巧和策略。
此处省略具体内容
等等
1. 使用AI工具提供上下文反馈使用AI工具可以帮你节省时间，并确保合并进来的代码质量非常好。
我在Reddit上找了很多工具，最后发现最好的一个叫CodeRabbit。
根据官方网站的信息，已经有500万次拉取请求经CodeRabbit审查，这说明了其可信性。这在处理私有代码仓库时也同样重要。
它使用机器学习算法来分析你的代码库（代码仓库），识别潜在问题点，并在拉取请求（PR）中提供上下文感知反馈。
✅ 例如，你可以在每一行代码上获得反馈信息，并且只需点击一下即可一键修复。
✅ 你可以在审查评论中通过实时聊天创建问题。
✅ 它可以与 GitHub、GitLab、Azure DevOps、Bitbucket 云（测试版）集成。
你只需要使用这些命令就能完成一些操作，比如 @coderabbitai summary，@coderabbitai review。AI也会随着时间学习，并识别出针对这个仓库的一些最佳做法。
快来看看这个演示吧！
在免费版本中，你可以获得拉取请求的概要（这是最重要的），并且他们提供免费试用期来帮助你了解是否适合你的需求。
更多内容可以在文档中找到，如果你想了解更多，Coderabbit是开源项目，欢迎查看。
你也可以阅读 Linux 基金会如何通过 AI 代码审查来减少开源软件（OSS）中的人工瓶颈。
还有一些其他的工具，如果你想了解更多，可以去探索一下。
Codacy- 自动识别和修复代码质量问题。Synk- 用于查找和修复代码或依赖项中的漏洞。Bito- 代码审查助手，帮助你发现代码中的潜在问题。Qodo- 提高代码审查质量，减少来回沟通的延迟。Code Review GPT GitHub Actions- 使用 GPT 在 GitHub Actions 中自动化代码审查。GitHub Copilot- 最可靠的 AI 编程伙伴。PullRequest- 结合 AI 和专家的审查。
这些描述听起来几乎一样，可以多看看其他博客的文章，找到更多的工具。
此处省略
2. 将你的评价与原则挂钩，而不仅仅是个人看法。我在一个开源项目里当维护者，所以我深知给反馈有多难。
如果一名程序员给你发送了一份他们认为很棒的代码变更列表，而你却列举了诸多它不好的原因，这可能会传达一个完全错误的信号。
大多数时候，作者们会把对他们的代码的批评视为不称职的程序员的间接指责，而这绝对不是真的。
在给代码提供反馈时，你应该解释你建议的修改。同时，你也需要说明修改的原因。
语气稍微一变就能有很大不同：
❌ "我们最好把这两个功能合并一下。"
✅ "这个功能同时负责认证和记录日志，这违反了单一职责原则。我们把它们分开处理怎么样？"
这样写可以将你的基于观点的反馈转化为更具建设性的方式。要保持客观，尽可能通过链接提供具体的证据。
……
3. 使用常见技术来处理不同类型审查。这里有一些开发人员可能不了解的技术，比如：
⚡ 展示与讲述环节：作者向评审员展示他们所做的修改，并解释做出这些修改的原因。
⚡ 基于检查清单的复查：使用预定义的检查清单来保持一致性，并避免遗漏关键部分。
⚡ 橡胶鸭子复盘: 作者向审阅者解释代码，就像在向一只‘橡胶鸭’讲解一样。
⚡ 自动化检查清单审查: 结合使用自动化工具和人工审查，以查找诸如风格违规之类的常见问题。
⚡ 两豆共一壳：你在讨论时评论了一行，另一位贡献者在同一拉取请求 (PR) 的另一行提供了反馈。
⚡ 闪电：根据同行的贡献类型调整你的审阅。
⚡ 教他们审查: 审核者指出问题并解释原因，说明为什么需要这些改动。
⚡ 逐提交审查: 每个提交都单独审查，便于追踪更改和理解作者的思考过程。
有更多像模式识别，变更影响分析，基于轨迹的代码阅读等等的技术，你可以自己去探索一下。
如果你有兴趣多读一些，有几个有趣的博客不妨去看看：
- 如何给出有效的代码审查意见 由 freeCodeCamp。
- 10个最佳代码审查技巧 由 awesome 代码审查。
一旦你掌握了这些技巧，只需结合你的个人经验用它们，就能更好地把握方向。
4. 请求更改，而非强制
常规的代码审查讨论很容易变成个人攻击。
想象一下你对团队成员说，“拿那份报告给我，顺手也帮我拿杯咖啡”，这听起来会有些过分，也不是他们预期你会提的要求。
| 反馈以命令形式 | 反馈以请求形式 |
|---|---|
审阅者： "能否将 User 类拆分成几个更小的类？" |
审阅者： "我们能否将 User 类重构成多个较小的类？" |
| 作者： "我认为没有必要这样做，现在的类已经很好了。" | 作者： "确实可以这样做，但我担心这可能会让事情变得更复杂。你对此有何看法？" |
如果命令听起来更直接，可能会让对方产生防御心理。
人们更喜欢对自己的工作有一定的掌控权。当你提出请求时，会给他们一种参与感。
给予反馈时稍微温柔一点并不需要特别费劲，但会让事情变得轻松很多。
使用代码审查检查表可以大大简化工作，让工作变得简单得多。
采取系统的方法进行代码复查将使这个过程更快且更准确。
那就是代码审查清单的概念。它是一份代码审查时需要遵循的清单，每次代码审查时，审查者都会遵循这份清单。
你不需要从零开始做，而是只需下载现成的列表并根据你的需求修改它。
你可以更侧重于你的技术栈，并专注于一些特定领域，例如无障碍或安全。
它在团队成员之间建立了一个关于哪些事情重要的共同理解，减少了代码审查中的冲突、分歧或不必要的来回。
例如，如果你正在编写一个React应用，你可能希望包含hook的使用、组件的重用性或高效的状态管理的检查项。
团队中的每个人都将保持同步，了解在审查代码时应该寻找什么。随着时间的推移，这将加快审查速度，同时不会牺牲质量。
Michaela 提供了一个免费的 Gumroad 产品，你可以在这个产品中找到一份不错的代码审查清单。
你也可以查看在 GitHub 上获得了 900 多个 star 的代码审查清单。
6. 避免在一些自动化工具（例如 lint 和 formatter）可以轻松搞定的任务上浪费时间。
我们的注意力每天都在下降，面对如此海量的信息。
在会议、邮件和其他各种干扰之间，找到专注于编写代码的时间真的挺难。阅读别人的代码会消耗你的精力。
我的建议是别把时间和精力花在那些计算机可以轻易搞定的琐事。
例如，一个好的格式化工具可以自动处理缩进问题，而无需向作者手动解释，可以在瞬间完成。
| 需要人工审稿的努力 | 所需的排版工具工作量 |
|---|---|
| 审稿人查找空格问题并发现错误。 | 完全不用管！ |
| 审稿人写了一份说明问题的笔记。 | |
| 审稿人确认笔记是否清晰易懂。 | |
| 作者读了笔记并修正了缩进。 | |
| 审稿人检查修正是否正确。 |
这也可以用于代码审查中的其他重复任务，比如：
| 任务 | 自动化解决方案 |
|---|---|
| 验证代码是否符合样式指南 | 代码检查工具如 ESLint（用于JavaScript）或 Pylint（用于Python） |
| 检查文档中的断链 | 链接检查工具如 Markdownlint 或 HTML 校验工具 |
| 验证代码是否遵循最佳安全实践 | 安全检查工具如 SonarQube 或 Brakeman（用于Ruby on Rails） |
| 检查注释中的拼写和语法错误 | 拼写检查工具如 Code Spell Checker 或 write-good 用于markdown文件 |
| 确保没有硬编码的机密信息，如API密钥和密码等 | 机密扫描工具如 Git-secrets 或 TruffleHog |
| 检查项目是否有足够的测试覆盖率 | 代码覆盖率工具如 istanbul.js（用于JavaScript）或 JaCoCo（用于Java） |
| 验证依赖项是否是最新的 | 依赖项管理工具如 Dependabot 或 Greenkeeper |
这样他们就可以把更多的时间花在更复杂的问题上，而不是浪费在修复基础错误上。
而且，没有人喜欢听到人犯错，如果是由计算机说，自尊心上好受得多。
小贴士：与团队合作，在代码审查流程中加入自动化检查，例如可以使用 Git 的 预提交钩子（pre-commit hooks） 或者 GitHub 的 webhooks。
7. 在剩下的修复比较简单时同意。
很多评审者认为他们应该只在所有问题都被解决后才批准代码。这可能会导致作者和评审者双方都面临不必要的反复沟通。
如果有像 拼写错误 或 变量名 这样的小问题存在，请明确说明这些问题是可以选择性的，这样作者就知道这些不是批准的必要条件。
别因为变量名不够完美就不提交代码了。
花更多时间在那稀有的2%的特殊情况上，是否比给其余98%造成不必要的延误更好？想一想。
8. 寻找机会将大篇幅的评审分成较小的部分。
我见过包含30多个文件修改和超过1000行代码增加的拉取请求（PR）。
一次性审查这么大的改动非常难，我们这些审阅者大多数情况下最终会错过一些关键的地方。
一个逻辑上的解决方案是将大型评论拆分成更小的部分。不要只是要求作者去拆分，而是帮助找到合适的拆分点。如果更改只影响到独立的文件，可以将这些更改按文件来分组。
对于更复杂的情形，你可以将这些简单的逻辑提取出来，并放到单独的变更列表里。
如果代码质量不好，明确表明需要分拆。
看看两三份乱七八糟的每份约300行的改动列表，比看一份这样的密密麻麻的600行代码倾泻要好。
9. 只提重要的反馈。
我一直避免一次给太多反馈，以免作者感觉压力山大。
从宏观层面开始，提供高层次反馈，例如架构问题、重要漏洞。这些问题影响最大，从大局出发，解决最关键的问题。
一旦这些大问题解决了，就可以继续处理一些较小且不太重要的细节，比如命名或小改动。
这样，作者可以专注于先解决最大的问题，不必被一些可能根本不算紧急的小事困住。
10. 别忘了对面是一个活生生的人。
在一堆截止日期里忙来忙去，很容易忘记对方其实是一个真实的人。
🎯 反对偏见，人人有责.
我们都有潜意识偏见，谷歌的一项最近的研究表明，自认为女性的开发者在代码审查中比自认为男性的同行受到更多的质疑。这真是令人惊讶！
意识到这一点并采取必要的措施（比如说是审查的审查），以减少代码审查中的偏见或其他类似偏见是很重要的。
🎯 避免陷入僵局。
代码审查中最糟糕的情况是出现一种 “僵局”，你拒绝在不进行更多修改的情况下批准变更列表，但作者拒绝修改。
讨论的气氛会非常紧张，因此，进行坦诚简单的沟通是必要的。坦诚简单的沟通会打破这种僵局。
简洁
避免在代码审查中使用“你”这个词。
你看这些有什么不一样吗？
❌ 能把这个变量名改成更有描述性的吗？
✅ 我们能不能把这个变量名改成更描述性的？
小小的语气变化就可以带来不同。
11. 庆祝酷炫的代码！
代码审查不一定总是找出错误。这也是一个赞扬好代码的机会！
说类似“我喜欢你那样讲，这样就容易多了”的话真的很有帮助。一点小赞美可以带来很大帮助（即使你没注意到）。
这说明你并不是仅仅为了指出错误的地方，而是真正注意到他们做对的地方。
这不只是让人感觉好，而是营造一种积极氛围，激励大家更上一层楼。
我根据自己的开源维护经历，希望你在这儿找到了一些有用的东西。
如果你在进行代码审查时有任何意见或其他需要注意的地方，请告诉我。
祝你今天开心哦~下次见！
你可以查看我的工作 anmolbaranwal.com。
感谢您的阅读！🥰 | Twitter上的Anmol_Codes
GIF