怎样写代码审核的评论？

概述

在审核代码时，礼貌和尊重都很重要，与此同时，评论应该描述清晰，有利于开发者改进代码。确保你对代码的评论应该是针对“代码”，而不是针对“开发者”本人。当然，不必总是遵循这条原则，但是当你要说某些可能让人沮丧或引起争议的话时，一定要对事不对人。例如：

不好的说法：“为什么你在这儿使用线程？明显这儿使用并发没有任何好处。”

好的说法：“这儿的并发模型增加了系统的复杂度，我在性能上没有看到好处。因为没有性能提升，这段代码最好还是由多线程改成单线程。”

从上面“好的说法”中，我们看到，它有助于开发者理解 为什么 你要写这条评论。当然，不必每次都解释为什么，但某些情形——阐明你的意图、你正在遵循的最佳实践、你在提升代码健康程度——解释原因是有必要的。

一般而言，修复 CL 的责任人是开发者，而不是审核者。 你不必为开发者写出详细的设计方案，也不必为他写代码。

但这不代表审核者可以不提供任何帮助。作为审核者，你应该在指出问题所在与提供直接指导之间做好平衡。指出问题，并让开发者自己做决定，这样有助于开发者自我学习，审核者自己也很省时间。这种方式，开发者也更容易找出更好的解决方案，因为相对审核者，开发者对自己的代码更熟悉。

当然，有些时候也可以给出直接的指示、建议或代码。毕竟，代码审核的首要目标是尽可能让 CL 变得更好；次要目标才是提升开发者的技能，以缩短审核时间。

如果某段代码你看不懂，让开发者解释，通常结果是他们会重写代码让它更清晰。有时候，添加注释也可以，只要它不是用来解释一段过于复杂的代码。

仅仅把解释写到代码审核工具里不利于以后的代码阅读者。 只有几种情况可以这样，如当你正在审核一段你并不是很熟悉的代码时，开发者向你解释的文字，其他开发者都知道，那这种解释就不必写到代码里。

Last updated 4 years ago