代码的创造者是代码评审过程中的最重要的角色，是代码评审的发起者，也是最大受益者之一，而如何让代码评审为发起者带来更大的好处，下面是4个有效的建议。
改动范围要小
每次评审的代码变动的范围，要保持尽可能的小。当一次评审的代码中，有超过3个，或者5个以上的关键变动时，就要考虑是否将其分解为更小的变更请求。
因为一次评审中，如果涉及到的改动越小，参与评审的人的认知负担也会更小，也就越能快速的评审、快速的给出反馈。
对反馈保持开放
关于反馈，无论是给与反馈，还是接受反馈，都是一样有压力的事。
编程是一门手艺，对于指出其他人努力工作的结果中，还有值得改进的地方，是非常不容易的。
如果你对你收到的反馈感到沮丧时，在做出回复前先暂停一下，也许把它先放在一边一段时间，去走走休息一下，再来处理结果会更好。
你对反馈意见越开放、越欣赏，你就越能从他人那里得到的极具价值的经验，你也就成长的越快。
快速的做出回应
如果你对他人的反馈，有消极的情绪反应，最好的方式是先放一下。不要在愤怒的无意识中去回应代码的评审，至少要记住这一点。
如果你没有负面的情绪，就就尽快的处理反馈中问题，对代码做调整，以及提出一些后续的问题等等。
上下文切换是编码过程中精力杀手。我们的目标是尽可能的降低自己和参与评审的同伴的无效时间的浪费。
如果评审的过程大家能保持尽可能的同步，在一个场域能快速的完成一件事，那是最好方式了。
切换到同步进行
通常情况下，大部分的代码评审是异步进行的，发起人通过代码评审工具发起评审请求，等待参与评审人的反馈……
现在，及时大家在千里之外的不同地方办公，也是可以借助于在线化工具，实时同步的开展代码的评审的。
在异步评审中，如果发起人对反馈有想法，也可以利用工具，将其转化为同步沟通，走过去，电话过去等等，都是可以提高效率的方式。
如果团队已经比较习惯代码评审，这完全可以开展同步评审会议：
1、作者概述评审代码；
2、评审者查看和反馈建议
3、作者对反馈做理解
4、作者对反馈做出反应
当参与在同一场域下，可以减少上下文切换的时间，很快的完成一项评审。
最后
代码评审，是让团队将事做正确的保证机制，也是团队内互相学习和提高的一个场域。
保持开放，保持坦诚，抱着一颗学习的心态，是最关键的所在。
