评审注解

概要

· 礼貌。

· 解释你的理由。

· 给出明确的方向，指出问题，并让开发人员决定如何在两者之间做出权衡。

· 鼓励开发人员简化代码，或者添加代码注释，而不只是让他们解释代码的复杂性。

礼貌

一般来说，礼貌和尊重是很重要的。一个是要确保你的评论是针对代码而不是针对开发人员。你不一定要一直这么做，但当你想说一些可能会让开发人员感到激动或有争议的话时，绝对有必要这么做。例如：

不好的说法：“为什么你要在这个地方使用线程，这样做显然不会获得任何好处”。

好的说法：“在这里使用并发模型增加了系统复杂性，但我看不到任何实际的性能好处，所以这段代码最好使用单线程，而不是多线程”。

解释理由

从上面的正面示例可以看出，这样有助于开发人员理解你为什么要给出这些建议。你并不一定总是要在评审中提供这些信息，但如果你能够为你的意图、所遵循的最佳实践或你的建议将如何改进代码质量给出更多的解释会更好。

给予指导

一般来说，修复CL是开发人员的责任，而不是评审人员的责任。你不需要为开发人员提供详细的解决方案或者为他们写代码。

不过，这并不意味着评审人员就不应该帮助开发人员。你最好可以在指出问题和给予指导之间做出权衡。指出问题，并让开发人员做出决策，这样有助于开发人员学到东西，并让代码评审变得更容易。这样还可以产出更好的解决方案，因为开发人员比评审人员更了解代码。

不过，有时候直接给出指令、建议或代码会更有用。代码评审的主要目的是获得尽可能好的CL。第二个目的是提高开发人员的技能，这样以后需要的评审就会越来越少。

接受注解

如果你要求开发人员解释一段你不理解的代码，他们通常会去重写代码，并把代码写得更清晰。有时候在代码中添加注解也是一种恰当的做法，只要它不只是用来解释太过复杂的代码。

不要只是把注解写在代码评审工具里，因为这对于将来要阅读代码的人来说并没有多大帮助。只有少数情况可以接受这种做法，例如，你对评审的东西不太熟悉，而开发人员的解释却是很多人所熟知的。