11 个让开发人员更轻松地进行代码审查的实用技巧
由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！
代码审查是构建优秀软件过程中最被低估的环节之一。
一开始可能会觉得很难很复杂，但实际上比你想象的要容易得多。
本文简要概述了开发人员进行代码审查的 11 种实用方法和策略。
这将有助于你更好地进行代码审查。
🎯 什么是代码审查？
在深入探讨要点之前，让我们先花点时间了解一下代码审查的含义。
代码审查是指开发人员在合并或发布代码之前，互相检查对方的代码以提高代码质量。
这个术语code review可以有很多种含义，从简单地阅读朋友的代码到 20 人参加的会议，详细分析每一行代码。
主要涉及两个角色：
Reviewer：负责阅读代码并决定何时将其合并到团队代码库中。Author：负责编写代码并提交审核，主要通过 pull request 的方式。
当审核员确认修改后，审核就结束了 approves 。你会看到 LGTM，这是“我觉得不错”的缩写，意思是一样的。
如果您想了解更多， GitLab 出品的《什么是代码审查？》指南是一个很好的起点。它列出了代码审查的优点、缺点、几种方法和一些最佳实践。
让我们来探讨一下在进行代码审查时应该考虑的技巧和策略。
1. 使用人工智能工具进行情境反馈。
使用人工智能工具可以帮助您节省时间，并确保合并的代码质量非常高。
我搜索了很多工具（主要是在 Reddit 上），找到的最好的工具是CodeRabbit。
根据官网信息，CodeRabbit 已审核了 500 万个 pull request，这足以证明其可靠性。而当你维护一个私有代码库时，这一点尤为重要。
它使用机器学习算法来分析您的代码库，识别潜在问题，并针对拉取请求提供上下文相关的反馈。
✅ 您可以获得逐行反馈和一键式简易修复。✅
您可以在评论区创建问题并进行实时聊天。✅
它可以与 GitHub、GitLab、Azure DevOps 和 BitBucket 云平台（测试版）集成。
您只需使用命令即可执行某些操作，例如@coderabbitai summary…… @coderabbitai review。人工智能还会随着时间的推移不断学习，并识别出特定于存储库的某些最佳实践。
您可以观看这个简短的演示！
免费版会提供拉取请求的摘要（这是最重要的），并且提供免费试用，帮助您了解它是否适合您。
您可以在文档中找到更多信息，如果您想了解CodeRabbit，它是开源的。
您还可以了解Linux 基金会如何使用 AI 代码审查来减少开源软件中的人工瓶颈。
如果您想探索其他工具，还有一些其他工具可供选择：
Codacy- 自动识别并修复代码质量问题。Synk- 用于查找和修复代码/依赖项中的漏洞。Bito- 代码审查助手，帮助您发现问题。Qodo- 提高审核质量，同时减少来回沟通的延迟。Code Review GPT GitHub Actions- 使用 GPT 直接在 GitHub Actions 中自动执行代码审查。GitHub Copilot- 最值得信赖的人工智能结对程序员。PullRequest- 结合人工智能和专家人工审核。
我知道这些描述听起来几乎一样，只需浏览其他博客即可找到更多工具。
2. 将你的评论与原则联系起来，而不仅仅是观点。
我是一个开源项目的维护者，所以我知道提供反馈有多么困难。
如果程序员发给你一份他认为很棒的变更列表，而你却列出一大堆理由说明为什么不行，这可能会传递完全错误的信息。
大多数时候，作者会将对他们代码的批评视为他们不称职的程序员的间接证明，但这绝对不是事实。
在对代码提出反馈意见时，请解释您建议的更改以及更改的原因。
语气上的简单变化就能产生很大的影响：
❌我们应该合并这两个功能
。✅
“这个功能同时处理身份验证和日志记录，违反了单一职责原则。我们应该将它们分开。”
这样写能将你基于个人意见的反馈转化为建设性意见。要客观，并尽可能提供链接等具体证据。
3. 对不同类型的评论采用通用方法。
开发人员并不了解许多技术，例如：
⚡ The Show and Tell Review：作者向审稿人展示修改之处，并解释修改背后的原因。
⚡ Checklist based Review：使用预定义的检查清单来保持一致性，避免遗漏关键领域。
⚡ Rubber duck review：作者向审阅者解释代码的方式，就像在向一只“橡皮鸭”解释代码一样。
⚡ Checklist Automation review：结合自动化工具和人工审核，以发现诸如风格违规之类的常规问题。
⚡ Two Peas in a Pod：你在对话中评论了一行代码，而另一位贡献者则对同一个拉取请求中的另一行代码提供了反馈。
⚡ The Chameleon Review：根据同行的贡献类型调整你的 PR 审核方式。
⚡ Teach them Review：审阅者不仅指出了问题，还解释了为什么需要进行这些更改。
⚡ Commit-by-Commit Review：每次提交都会单独审核，从而更容易跟踪更改并理解思考过程。
还有更多类似的技术Pattern recognition，等等，你可以自己去探索Change impact analysis。Trace-based code reading
如果您有兴趣阅读更多内容，以下几个博客值得一看：
- freeCodeCamp教你如何给出有效的代码审查反馈。
- 来自优秀代码审查的10 种最佳代码审查技巧。
一旦你掌握了这些技巧，只需将它们与你的个人经验结合起来，就能让你更好地把握方向。
4. 请求改变，而不是命令改变。
正常的代码审查对话很容易演变成个人意见。
想象一下，你对你的团队成员说：“把那份报告给我，顺便帮我买杯咖啡”，这会显得要求很高，而且也出乎对方的意料。
| 以命令形式呈现的反馈 | 以请求形式提出的反馈 |
|---|---|
审阅者：“将该User类重构为多个较小的类。” |
审阅者：“我们能否将该User类重构为多个较小的类？” |
| 作者：“我觉得没必要。现在的课程挺好的。” | 作者：“我们可以这么做，但我认为拆分可能会使事情变得过于复杂。您觉得呢？” |
如果命令显得更加直接，可能会导致防御性反应。
人们喜欢对自己的工作拥有掌控权。当你提出要求时，会让他们产生一种主人翁意识。
给予反馈时格外温和，并不需要付出十倍的努力，但却能让事情进展得更加顺利。
5. 使用代码审查清单可以让工作变得轻松许多。
采用系统化的方法进行代码审查，可以带来更快、更准确的审查过程。
这就是代码审查规范的概念review checklist。它是一套代码审查员每次审查代码时都要遵循的准则或项目。
你不必从头开始制作，只需下载一个现成的清单，然后根据你的需要进行调整即可。
您可以让它更侧重于您的技术栈，并专注于一些特定领域，例如可访问性或安全性。
它有助于团队成员对哪些事情重要达成共识，并减少代码审查过程中的冲突、分歧或不必要的反复沟通。
例如，如果您正在开发 React 应用，您可能需要加入对 hook 使用情况、组件可重用性或高效状态管理的检查。
团队中的每个人都会对代码审查时需要关注的内容达成共识。随着时间的推移，这将在不影响代码质量的前提下加快审查流程。
Michaela 在 Gumroad 上发布了一款免费产品，其中包含一份不错的清单。
您还可以查看GitHub 上获得 900 多个星标的代码审查清单。
6. 避免把时间浪费在语法检查器和格式化工具可以轻松处理的任务上。
在信息爆炸的时代，我们的注意力持续时间正在逐日缩短。
在各种会议、邮件和其他干扰因素的干扰下，很难抽出时间专注于代码。阅读别人的代码会消耗你的精力。
我的建议是不要把时间和精力浪费在电脑可以轻松完成的琐事上。
例如，与其手动向作者解释缩进问题，不如使用一款优秀的格式化工具在几秒钟内解决这个问题。
| 需要人工审核员付出努力 | 使用格式化工具需要付出努力 |
|---|---|
| 审校人员会检查空格问题并找出错误。 | 没有什么！ |
| 审稿人写了一条注释来解释问题。 | |
| 审阅者再次核对笔记，确保其清晰易懂。 | |
| 作者阅读了注释并修改了缩进。 | |
| 审核人员验证了修复效果。 |
你也可以将此方法应用于代码审查中的其他重复性任务。以下是一些示例：
| 任务 | 自动化解决方案 |
|---|---|
| 请检查代码是否符合风格指南。 | 代码检查工具，例如ESLint（用于 JavaScript）或Pylint（用于 Python）。 |
| 检查文档中是否存在失效链接 | 链接检查工具，例如Markdownlint或 HTML linting 工具 |
| 验证代码是否遵循安全最佳实践 | 类似SonarQube或Brakeman（用于 Ruby on Rails）之类的安全代码检查工具 |
| 检查评论中的拼写和语法。 | 像Code Spell Checker或write-good 这样的拼写检查工具适用于 Markdown 文件 |
| 确保所有敏感信息（API密钥、密码等）均未硬编码。 | 类似Git-secrets或TruffleHog 的秘密扫描工具 |
| 检查项目是否具有足够的测试覆盖率。 | 代码覆盖率工具，例如Istanbul（JavaScript）或Jacoco（Java） |
| 请检查依赖项是否为最新版本。 | 依赖管理工具，例如Dependabot或Greenkeeper。 |
与其浪费时间纠正基本错误，不如将精力集中在更复杂的问题上。
此外，没有人喜欢听到人犯错，如果是电脑犯错，就更容易让人安心了！
提示：与你的团队合作，在代码审查工作流程中设置自动化检查，例如在 Git 中使用pre-commit hooks或在 GitHub 中使用webhooks。
7. 如果剩下的修复工作很简单，就批准。
许多代码审查员认为，只有在所有问题都得到解决之后才能批准代码。这可能会给back-and-forth作者和审查员双方都造成不必要的延误。
如果只剩下一些小问题，例如 atypo或 a，variable name那么要明确说明它们是可选的，以便作者知道这不是批准的条件。
不要因为变量名不够完美就耽误代码的开发。
多花点时间处理那2%的罕见病例，总比给其他98%的病例造成不必要的延误要好得多吧？好好想想。
8. 寻找机会将大型评论拆分成多个部分。
我见过包含 30 多个文件更改和 1000 多行代码的 Pull Request。
一次性审核如此大的改动非常困难。大多数时候，我们这些审核人员最终都会遗漏一些关键内容。
一个合理的解决方案是将大型审阅拆分。与其直接要求作者拆分，不如帮助他们找到合理的分割点。如果修改对文件的影响是独立的，则按文件进行分组。
对于更复杂的情况，您可以找到简单的逻辑，并将其移至单独的变更列表。
如果代码质量差，就明确说明有必要进行拆分。
审查几份杂乱的 300 行变更列表，比审查一份庞大的 600 行代码转储要好得多。
9. 只提供高层次的反馈。
我一直避免一次性给出太多反馈，以免作者感到压力过大。
首先就重大问题提出高层次的反馈意见，例如架构问题、重大漏洞等，这些问题影响最大。
这些问题解决之后，就可以着手处理一些不太重要的细节，例如命名或细微的改动。
这样，作者就可以集中精力先解决最大的问题，而不会被一些可能并不紧急的小事所困扰。
10. 不要忘记，对话的另一端是一个活生生的人。
在时间紧迫的混乱局面下，很容易忘记对话的另一端是一个活生生的人。
🎯 消除偏见。
我们都有潜意识里的偏见， 谷歌最近的一项研究 表明，女性开发者在代码审查中比男性同行更容易受到阻力。这真是令人震惊！
了解这些情况并采取必要的措施（例如对审查进行审查）来减少代码审查中的偏见或任何与偏见有关的事情非常重要。
🎯避免僵局。
代码审查中最糟糕的结果是，stalemate你拒绝在未进行进一步更改的情况下签署变更列表，但作者拒绝进行更改。
讨论的气氛会非常紧张，所以有必要好好谈谈。坦诚简单的沟通就能打破这种局面。
🎯 简洁的音调。
代码审查中避免使用“你”。
你觉得它们之间有什么区别吗？
❌ 能否 将此 变量重命名为更具描述性的名称？
✅ 我们能否 将此变量重命名为更具描述性的名称？
语气上的这个小变化就能产生影响。
11. 表彰优秀代码。
代码审查不一定非得指出错误，它也是一个突出优点的绝佳机会！
比如，说一句“我喜欢你这样解释，这样更容易理解了”，真的很有帮助。一句小小的赞美意义非凡（即使你没有意识到）。
这表明你不仅仅是为了指出错误，而是真正注意到他们做事做得正确的地方。
这不是为了让人们感觉良好，而是为了创造一种积极的氛围，激励他们做得更好。
我运用了自己作为开源项目维护者的经验，希望对你有所帮助。
如果您在代码审查过程中有任何反馈或其他需要注意的事项，请告诉我。
祝你今天过得愉快！下次再见 :)
| 您可以在anmolbaranwal.com 查看 我的作品。 感谢阅读！🥰 |
   |
|---|
