Google代码健康：代码评审有过多评论改进项
本文源于Google公司的马桶上的健康代码，作者：Tom O’Neill
代码评审可能会减慢单次代码的变更速度，但同时也有机会改善你的代码并向另一位聪明且经验丰富的工程师进行学习。如何充分利用它们？
力求使你的大部分变更在少量评论项的情况下，于第一轮评审就获得批准。如果您的代码评审经常需要多轮评论，那么下面的技巧可以帮助你节省时间。
聪明地耗费评审者的时间—资源有限。如果他们发现很容易发现的问题，那么你的工作效率就会降低。
在发起代码评审之前：
- 重新评估你的代码：不要在测试通过后立即发起评审。退后一步，尝试重新思考整个问题-设计是否可以简化？特别是在一天中很晚的时候，看看第二天早上是否有更好的方法会很有作用。尽管此步骤可能会减慢单次代码变更的速度，但长期将形成更高的平均吞吐量。
- 考虑进行非正式的设计讨论：如果不确定，结对编程，面对面交谈或尽快发送差异，并要求对总体设计进行“预审”。
- 自我评审变更：从一无所知的人的角度出发，尽可能审慎地查看代码。代码评审工具可以为你提供与IDE截然不同的代码视图。这样可以轻松为你节省反复评审。
- 使差异易于理解：一次进行多个变更会使代码更难评审。当进行自我评审时，请寻找可减少差异量的简单变更。例如，保留重大的重构或格式变更以开展另一次代码审阅。
- 不要在提交消息中隐藏重要信息：最好将其放入代码中。以后阅读代码的人不太可能查看提交消息。
在处理代码时，请评论：
- 解决不重要的评论后，重新评估代码：退后一步，以崭新的眼光再看一下代码。进行了一组变更后，通常可以发现这些变更开启或建议了其他一些改进。就像进行任何重构一样，可能要花费好几步才能达到最佳设计。
- 了解评审人为什么发表每条评论：如果您不了解评论背后的原因，则不要仅进行修改—寻到评审人并学习一些新知识。
- 在代码中回答评审者的问题：不只是答复—使代码更易于理解（例如，改进变量名，将布尔值更改为枚举）或添加注释。稍后会有其他人出现同样的问题。
- 版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！
