改动范围要小
每次评审的代码变动的范围，要保持尽可能的小。当一次评审的代码中，有超过3个，或者5个以上的关键变动时，就要考虑是否将其分解为更小的变更请求。
因为一次评审中，如果涉及到的改动越小，参与评审的人的认知负担也会更小，也就越能快速的评审、快速的给出反馈。
对反馈保持开放
编程是一门手艺，对于指出其他人努力工作的结果中，还有值得改进的地方，是非常不容易的。
你对反馈意见越开放、越欣赏，你就越能从他人那里得到的极具价值的经验，你也就成长的越快。
快速的做出回应
如果你没有负面的情绪，就就尽快的处理反馈中问题，对代码做调整，以及提出一些后续的问题等等。
如果评审的过程大家能保持尽可能的同步，在一个场域能快速的完成一件事，那是最好方式了。
切换到同步进行
现在，及时大家在千里之外的不同地方办公，也是可以借助于在线化工具，实时同步的开展代码的评审的。
如果团队已经比较习惯代码评审，这完全可以开展同步评审会议：
1、作者概述评审代码；
2、评审者查看和反馈建议
3、作者对反馈做理解
4、作者对反馈做出反应
当参与在同一场域下，可以减少上下文切换的时间，很快的完成一项评审。