代码审查的 5 条黄金法则

代码审查在开发过程中扮演着至关重要的角色。它不仅能节省宝贵的时间和金钱，还能赋予开发团队以人为本的价值。代码审查也是指导新员工的绝佳工具，也是大公司推崇的良好实践。

但当然，由于紧迫的期限、销售预期和组织压力，一些团队和公司放弃了提高代码质量的机会。

无论您的公司在代码审查方面处于什么位置，本文都将介绍如何（以及应该如何）使用代码审查来帮助开发过程和组织文化的其他方面，最重要的是，为您的开发人员提供更多价值

以下是代码审查的 5 条黄金法则：

代码审查有五条黄金法则。如果你参加过培训，其中一些法则可能听起来很熟悉。没错，代码审查只是特定领域提供反馈的一种特定形式。

‍

永远记住——评论的另一端是人

代码审查的第一条黄金法则很简单：审查其他人的代码，就像你希望别人审查你的代码一样。

代码审查应该：

- 友善 —即使还有改进的空间，也可以用同理心传达信息
- 清晰 —让审阅者轻松理解您在说什么。重要的是，如果您有建设性的反馈意见，请直接提出。避免“垃圾三明治”，即先对代码进行正面反馈，即使是真诚的，然后再提出改进建议。
- 具体 —您的反馈越具体，对作者就越有帮助。
当我们中的许多人远程工作或相距数百或数千英里时，这可能很难做到这一点。
为了确保您正确沟通，请大声朗读您的代码评论并问问自己，这是我希望别人对我说的话吗？如果不是，请考虑改变语气或内容。

‍

给出明确的建议或推荐

永远不要告诉别人代码需要修复，而没有给出关于修复什么或如何修复的建议或推荐。

不知道为什么？想象一下，有人来到你家，对你说：“我不喜欢你的装修风格。赶紧修一下。”

这真是令人恼火。

写“修复此问题”而不提供更多解释绝对不是好主意。为什么需要修复？你有什么修复建议？别人怎么才能解决这个问题？

如果您留下的代码审查结果只是“修复这个问题”或“做得更好”，我们将代表代码审查权力亲自到您家里来严厉批评您。

‍

始终假设善意。

代码的编写方式可能与你想象的不一样。更明确地说：两个不同的人编写的代码很少会以相同的方式出现。毕竟，代码是一门手艺，而不是流水线上的一项任务。

在审查时要激发好奇心和欣赏心——好奇心是想了解审查者的想法，并对编码员所做或试图做的事情表示感激。

‍

明确行动和重要性级别。

如果您提出的是可选建议，例如，在代码获得生产批准之前不需要的“nit”，请明确说明。

如果您想知道为什么此人做出特定的选择，但这并不影响代码是否应该投入生产，请清楚地说出来。

如果您确信代码在投入生产之前需要修复，请明确说明。

专业提示：写作时，我们常常认为自己的意图很明确。毕竟，我们知道自己想表达什么。但请记住，读者理解的可能并不总是像我们自己理解的那么清晰，所以请确保你最基本的指导简洁明了。

‍

不要忘记，代码反馈——以及所有反馈——都包含赞扬。

毋庸置疑，进行代码审查的主要好处是改进代码并解决问题。

但这只是其中的一半。另一方面，代码审查提供了一个绝佳的机会来感谢你并欣赏同事的工作。

如果有人编写了特别优雅或易于维护的代码，或者做出了关于使用库的重大决定，请告诉他们！

在 Sema，我们坚信给予积极、具体的反馈总是合适的。当然，在代码审查方面，我们也言行一致。

在我们的白皮书中了解有关代码审查的来龙去脉及其对公司文化的影响的更多信息：www.semasoftware.com/blog/code-reviews-101-the-basics