能改进而不是拖慢进度的代码评审

大小

两百行的合并请求会得到真实的意见；两千行的会得到「看起来不错」。拆开它。如果实在拆不开，就在描述里写一条推荐的阅读路径。

该就什么发表意见

正确性、边界情况、安全、敏感位置上的性能，以及对一年后阅读者的清晰度。风格、空格和import顺序——交给自动工具，不是交给人。

把意见写成问题或建议，并标明哪些是阻塞项、哪些只是个人看法。「阻塞：这会允许访问到别的用户的资源」比一句委婉的暗示清楚得多。

响应时间

一个等了两天的评审会卡住别人，并催生出很长的分支。定一个规范——比如半天内回复——并把它当作团队的任何其他承诺来对待。