作为被评审者，怎样做才能使评审更加有效？

本文所说评审主要指代码评审。

最近突然感觉到，在评审时，自己作为代码被评审者，一直很难进入状态。

究其原因，主要是因为自己对评审认识不足，在评审前，评审中及评审后均存在一定的问题，现将自己的分析结果整理成文，分享给大家。

 

评审前

关键词：准备不足

评审前准备不足，导致评审时极容易陷入被动。一旦陷入被动，被评审者很可能会被评审者不知不觉带进“沟”里，明明自己的方法当时可能已经是最佳的实现了，但是被评审者三言两语一“建议”后，立马觉得“实在太有理”了，感觉自己当时的方法确实有点“那个”，但是回去细细一想，感觉评审者所提的“建议”并不是那么回事，因为他所提的那个“建议”并没有考虑到我当时考虑的那个细节，只是评审时我怎么没有指出这个细节呢，还是因为准备不足。评审前准备不足，有时还有可能导致评审无法进行下去，当评审者去评审一份低级错误遍布，功能实现残缺的代码，我想是没有人愿意继续下去的。当然，评审准备不足，还会导致其他直接的或者间接的问题，如评审时间延长，评审质量下降（本该评审出来的问题没找到，本来不是问题的地方却耗时太多），当然最后将直接导致产品品质下降。

写给自己的建议： 

在评审前，作为被评审者，至少应该做到以下几点来确保评审的顺利进行。

1.评审前，至少需要对照CheckList过一遍代码，这样做的好处有：可以使自己的编码符合相关的规范，当然还可以避免一些低级错误的出现。

2.评审前，需要重点理解自己代码的核心和疑难部分，因为这部分代码注定是评审时的重点，当然也是问题的高发地带，并且这些部分也是最难理解和及其容易忘记细节的部分，要是评审前没做一定工作，很有可能在评审时，连被评审者也有可能不知所云了，这样是极其危险的，所以一定要记住：对自己代码的核心和疑难部分做一次彻底的理解吧。

3.评审前，需要对自己的代码做全面的自测，不要一味寄希望于评审来帮你找到一切问题，这是不可能的，所以，彻底的自测才是根本保证。

4.评审前，做好其他准备工作：选择好时间（要是条件允许的情况下，选择自己工作状态最佳的时间来进行评审吧），预定好会议室，联络好相关人员等等。

 

评审中

关键词：过于相信评审者

评审中，作为被评审者的“我”来说，最喜欢犯这样一个错（或者说有这样一个毛病），那就是：过于相信评审者。因为评审者往往都是一些经验丰富的前辈，所以评审者提出他们的看法时，我很容易产生错觉，他们所提出的方法肯定比我的方法“吊”，但是实践告诉我，也许并非如此。因为，评审者尽管经验丰富，但是他们并没有实际参与此块代码的开发，所以对于某些细节他们其实并没有考虑到，他们提出的建议可能在大多数情况下是可行的，但是在某些特殊情况下其实是不可取的。在评审中，我还存在一个问题，那就是：有时对评审者所提出的建议理解不充分，往往会暂且认为他们是对的，这样将问题就此放过的作法，其实是有风险的，有问题就应该及时将问题理清楚，而不是留到后面。当然还有其他一些问题：如对评审建议记录不全，对评审者建议理解不彻底，对重点模块评审不充分等等。

写给自己的建议： 

在评审中，作为被评审者，至少应该做到以下几点来确保评审高质量的进行。

1.评审中，应该大胆及时地提出自己的看法，不要盲目相信评审者的经验，更要具体问题具体对待。要相信自己的做法，当然评审者的经验之谈也是不可或缺的，两者结合来看待问题吧。

2.评审中，应该详细记录出现的问题，不要有遗漏，此时的每一个遗漏可能都是Bug出现的潜在伏笔。

3.评审中，不要放走那些重要但是自己并没有完全理解的问题，不要奢望回头再好好理解“她”（指的是问题，不是你的那个“她”），说不定回头你就忘了“她”到底是怎么一回事。

4.评审中，还要控制时间，控制讨论范围，不要越扯越远，要适当休息等等。

 

评审后

关键词：代码修改不彻底

评审后，其实要做的就是根据评审修改代码，再次接受评审或者直接进入测试环节。对于我来说，可能比较容易犯的一个错就是：代码修改不彻底。其他倒是做的还不错（呵呵，吹吧），如评审结果登记等。

写给自己的建议： 

评审后，作为被评审者，至少应该做到以下几点来确保评审的善始善终。

1.登录评审结果，做到有据可查。

2.根据评审意见修改代码，尽量使代码过得去。

3.问题较大时，需要安排二次或者N次评审，直到该解决的问题彻底解决掉。

 

最后，要做的就是：

思想端正，执行彻底。

 

还有：

坦白从宽，抗拒从严

 

还有：

少生优生

 

还有：

。。。