Add article "What Code Review is not"

2025/14. Code Review 不是什么/what-code-review-is-not.md

@@ -0,0 +1,70 @@
+# Code Review 不是什么
+
+在软件开发实践中，Code Review（代码审查）是常见的工程质量保障手段；在 1024 实训营中，我们的代码改动体现为一个个 GitHub Pull Request，我们也会要求每个 Pull Request 都要通过 Code Review 后才能合入。
+
+有很多文章会介绍 Code Review 是什么、怎么做，这里我想就着 Code Review 操作过程中常常出现的误解，从反面来谈谈 Code Review 不是什么。
+
+## 1. Code Review 不是帮你找出你自己能发现的问题
+
+诚然，Code Review 是为了发现问题的，但它并不是为了发现那些你自己本可以发现的问题。协作的成本总是高于个人，相同的问题，依赖 Code Review 来发现并沟通解决，需要付出的时间和精力，一定是远高于个人独立发现并解决的。
+
+因此我们不应当依赖 Code Review 去发现那些通过测试或自查就能发现的简单问题，如基本的逻辑错误、代码的误提交等。在提交审查前，进行自检是代码提交者起码的责任，它们包括但不限于：
+
+* 逐行阅读变更，确保其是预期的变更
+* 确保持续集成（CI）通过
+* 添加必要的单测
+
+对应地，Code Review 更适合发现那些需要外部视角才能发现的问题，比如：
+
+* 代码的可读性和可维护性问题
+* 潜在的性能或安全风险
+* 对系统整体的影响
+* 审查者个人的经验和视角能发现的额外问题
+
+## 2. Code Review 不是审查者的义务
+
+很多人认为 Code Review 是审查者的责任——他们负责理解变更、检查并发现问题。不少代码提交者认为只要自己创建了 Pull Request，就可以当甩手掌柜，不用操心了。
+
+但实际上，代码变更是为了解决问题的，通过 Code Review 是合入代码变更、问题得以解决的必要条件。代码提交者是解决问题的第一责任人，因此推动 Code Review 的顺利进行应当是代码提交者的责任。
+
+而对代码审查者来说，为他人做 Code Review 往往不能直接体现为个人的产出，因此如果审查过程得不到足够的帮助，难免会有消极抵触的心理，最终导致审查流于形式。
+
+为了让 Code Review 达到预期的效果，提交者可以主动地帮助审查者理解自己的代码变更并发现问题，比如：
+
+* 控制 PR 的大小，保持改动的专注，使其便于审查
+* 在 PR 描述中说明必要的上下文
+* 维护清晰的提交历史
+* 确保代码易于理解（添加注释、文档等）
+* 主动解释非常规改动的原因和考虑
+
+当提交者认真履行这些责任时，Code Review 就能成为一种积极的协作体验，而不是单方面的负担。
+
+## 3. Code Review 不是设计讨论
+
+Code Review 的重心在“实现是否正确且合理”，而非“重新讨论设计”。
+
+虽然在审查过程中可能会涉及一些设计方面的建议，但这不应该成为 Code Review 的主要内容。如果发现经常在 Code Review 过程中有设计观点上的分歧并讨论、调整，那说明问题并不在 Code Review，而是在更早之前：对于复杂或重要的方案设计，我们应当更早地进行讨论，在代码提交之前讨论，甚至在代码实现之前讨论并达成一致。
+
+在代码实现完成后再去做设计讨论，往往会因为“既成事实”而难以达成共识，甚至会引发不必要的冲突。即使达成共识，也常常需要推翻大量已有的实现代码，导致效率低下。
+
+## 4. Code Review 不是单方的输出
+
+我们常常看到在 Code Review 中一方提交另一方审查，而误以为 Code Review 是审查者单方面的输出或指导。这是一个常见的误区，它也容易给人这样的错觉：只有比我更厉害或能帮我发现问题的人才能帮我审查代码。
+
+我们应当看到，Code Review 中的交流实际上是双向的：在每个 comment 下，提交者都可以进行回复和进一步讨论。事实上在绝大部分的 Pull Request 中，代码提交者都应该比审查者更了解当前要解决的问题和可能的方案选择——如果不是，这往往说明代码提交者是不称职的。
+
+除了 comment 中的讨论，审查者阅读代码（以及 Pull Request 中的其他说明性信息）的过程，本身也是在学习和了解项目。对项目中的代码合入保持关注，可以帮助审查者了解项目整体的演进；查看其他人解决问题的方式，也是在学习和积累处理问题的经验。
+
+这种双向交流不仅能提高代码质量，还能促进团队成员的成长和知识传递。
+
+## 5. Code Review 不一定发生在人与人之间
+
+随着 AI 技术的发展，Code Review 早已不再局限于人与人之间的交流，大模型为代码审查带来了新的可能性和挑战。
+
+一方面，大模型可以作为审查者，帮助发现代码中的常见问题。这样可以减轻人类审查者的负担，让他们更专注于复杂的、对领域知识要求更高的问题。同时 AI 审查者往往也能遵循比人类审查者更为一致的检查标准，避免人为的不稳定性。在 1024 实训营中，我们已经为每个项目配置了 AI 审查，建议大家认真地阅读其建议并做自己的思考。
+
+另一方面，大模型生成的代码也需要进行 Code Review。虽然 AI 可以生成代码，但它往往不是完美的，甚至可能会引入严重的问题。作为 AI 开发工具的使用者，我们需要对其生成的代码进行审查，以确保其正确地实现了我们的意图。在很多大型项目中，因为大模型幻觉的存在，以及它对项目整体理解的欠缺，对 AI 生成代码的审查，甚至要比对人类工程师代码的审查更为重要。在 1024 实训营中，我们鼓励大家使用 AI 工具来辅助代码编写，但需要注意，每个人依然要为自己提交的代码质量负责。
+
+## 最后
+
+Code Review 是软件工程中的重要的一环，在这篇文章中，关于它不应该是什么样的，我们讨论了很多。希望可以帮助大家避免常见的误区，把这件事情做好，为项目和个人带来实在的提升。