文章探讨了现有代码审查流程的不足，特别是GitHub在处理堆叠拉取请求和差异审查方面的缺陷。作者提出了两个主要问题：审查状态未作为仓库的一部分存储，以及审查通过远程网页界面进行。作者倾向于本地审查，认为这样可以避免网络延迟，并更好地适应个人工作流程。尽管尝试了git-review工具，但最终决定暂时搁置该方案。

标题：代码审查可以更好

主要内容：

许多开发者对GitHub的代码审查流程感到不满，主要问题之一是GitHub对堆叠拉取请求和差异审查的支持不佳。尽管差异审查有其价值，但作者决定尝试git-review工具的原因并非如此。作者对GitHub及其他代码审查系统有两个主要问题：

1. 审查状态未存储在仓库本身：当前的审查状态通常存储在远程数据库中，而不是本地git仓库中，这导致了延迟和供应商锁定。
2. 审查通过远程优先的Web界面进行：作者更倾向于在本地环境中进行代码审查，而不是通过Web界面。

作者在本地环境中进行代码审查时，会拉取源代码分支，软重置代码到基础版本，然后使用magit工具进行导航和审查。这种方式允许作者运行测试、获取上下文信息，并直接在代码中进行重构建议。然而，当作者想要在拉取请求中留下反馈时，必须通过浏览器进行操作，这带来了不必要的延迟和界面问题。

为了解决这些问题，作者开发了git-review工具。其核心思想是将代码审查视为一个单独的提交，该提交包含带有特定标记的代码注释。审查过程涉及作者和审查者修改这个提交，最终在所有线程标记为“已解决”后，添加一个显式的还原提交以保留审查历史。

尽管git-review的基本理念（即审查是在代码中留下注释）效果良好，但在实际操作中，修改被审查的代码变得复杂。如果审查者请求更改，并且这些更改应用于深层提交或添加新提交，可能会导致与审查注释的冲突。此外，--force-with-lease操作虽然可行，但也增加了摩擦。

此外，Git上游可能会引入类似Gerrit的Change-Id来跟踪单个提交的修订版本。如果实现，可能会为每提交的差异审查提供一流的支持，但这与git-review的方法（即添加一个单独的提交）不兼容。在Change-Id的世界中，可能会将审查注释添加到提交本身，并指示Git存储特定Change-Id的所有修订版本。

目前，作者暂时回到了基于Web界面的代码审查，但希望未来有人能彻底解决这些问题。

相关链接： - Fossil：一个将所有内容存储在仓库中的SCM系统。 - NoteDb：Gerrit的后端，将审查状态存储在git中。 - git-bug：使用git存储问题信息。 - git-appraise：使用git存储审查信息。 - prr：在GitHub的Web API上实现编辑器内审查界面。 - Jane Street的代码审查：展示了一个更好的世界，尽管尚未普及。

主要观点总结：

1. 本地代码审查工具的便利性：

   • 评论1和评论2提到使用本地工具（如VSCode的GitHub Pull Request扩展）进行代码审查的便利性，认为直接在编辑器中添加和审查评论非常高效。
     • 评论1："I use the GitHub Pull Request extension in VSCode to do the same thing (reviewing code locally in my editor)."
     • 评论2："Working with the change locally as you were the one who made it is very convenient."

2. GitHub审查流程的不足：

   • 评论3和评论11指出GitHub的审查流程存在重复审批的问题，尤其是对于开源贡献者来说，频繁的重新审批令人疲惫。
     • 评论3："GitHub makes you reapprove every PR after each push. As an OSS contributor it’s exhausting."
     • 评论11："LGTMs are not reviews, yet so common."

3. 代码审查工具的选择与学习成本：

   • 评论4和评论10讨论了不同代码审查工具（如Magit、gitui、Sublime Merge、diffview.nvim）的使用体验，并提到学习新工具的成本。
     • 评论4："I was on a lookout for best 'precommit' review tool and zeroed on Magit, gitui, Sublime Merge."
     • 评论10："This is a pretty cool tool for it: https://github.com/sindrets/diffview.nvim."

4. 代码审查的文化问题：

   • 评论11深入探讨了代码审查的文化问题，认为LGTM（Looks Good To Me）式的审查并不能真正解决问题，审查质量难以衡量，且企业往往将审查视为次要任务。
     • 评论11："The problem is cultural. The problem is that code reviews are just as essential to the process as writing the code itself."
     • 评论11："You can’t engineer your way out of a social problem."

5. Git审查流程的改进：

   • 评论5和评论8提到Git审查流程的改进，如使用软重置来模拟代码编写过程，以及Git考虑引入“Change IDs”来跟踪修订。
     • 评论5："When I review code, I like to pull the source branch locally. Then I soft-reset the code to mere base."
     • 评论8："It’s so cool that Git is considering first class change IDs!!"

6. 代码审查流程的演变：

   • 评论6和评论7回顾了代码审查流程的演变，提到堆叠式拉取请求（stacked pull requests）和Reviewboard、Phabricator等工具的使用。
     • 评论6："Fun to see how fast code review can change over 3-4yrs."
     • 评论7："I’ve used Reviewboard and Phabricator and both seem 'fine' to me."

7. 对开发者行为的批评：

   • 评论12对当前开发者的行为提出批评，认为他们过于自负且缺乏对代码质量的重视。
     • 评论12："The current generation of devs cannot benefit from advancements in flow or process because they are incredibly stupid and simultaneously arrogant."

总结：

评论中主要讨论了代码审查工具的便利性、GitHub审查流程的不足、代码审查的文化问题以及Git审查流程的改进。尽管技术工具在不断进步，但代码审查的质量仍然受到文化和管理方式的影响。LGTM式的审查虽然常见，但并不能真正解决问题，审查质量的提升需要企业和开发者共同重视。