背景
第一次参加CodeReview不知道该如何去做，也不知道为什么去做，后来参加多了，慢慢了解了CodeReview的意义，也同时发现CodeReview的效率问题：
●有时候会发现一个CodeReview时间很长，作为参与者真的是很煎熬，感觉精力很不够用而且浪费时间；
●有的时候不太了解对方评审的东西，以至于没法跟上大家的思路；
●有的时 候也可会看到有些人无所事事、精神不集中、也不发言，我想他们也能会和我有着同样的痛点。
写这篇文章，希望本文中的一些建议能够缓解上述问题，能使新人更快的了解CodeReview的意义和方法，有经验的人能够更加快速有效的进行CodeReview。
CodeReview的目标和原则
CodeReview的目的提升代码质量，尽早发现潜在缺陷与BUG降低修复成本，同时促进团队内部知识共享，帮助更多的人理解系统。建议CodeReview的原则如下：
●发现代码的正确性
代码审查用意是在代码提交前找到其中的问题——你要发现的是它的正确性。在代码审查中最常犯的错误—几乎每个新手都会犯的错误是，审查者根据自己的编程习惯来评判别人的代码。
●不仅是在Review Code，更是在分享和学习
Code Review最重要的是讲解者分享业务流程和设计思路，参与者通过这些讲解获得这些信息，使得更多人理解这个系统，提升团队整体水平，使得团队维护代码的能力提升。
●高效迅速完成CodeReview
我们不能为了应付匆匆忙忙的进行一次代码审查，效率也是很重要的，如果不能保证Code Review目的实现，那么评审便是徒劳的。
如何高效完成CodeReview？
参与者要检查设计的合理性以及业务逻辑是否错误，检查代码可读性；讲解者要想办法分享设计、技术、经验等知识。
1.检查设计的合理性和业务逻辑的正确性：
●代码的设计是否符合设计要求：
·如果存在代码和设计有出入的地方需要问询为什么要变动，因为这些变动有可能是出于开发者在真正设计代码时候的深入考虑，或者是由于一时大意出现偏差。
●业务逻辑是否正确：
·业务流程是否按照详细设计的流程走，不要出现原本是先A流程后B流程而设计的时候出现先B后A，或者丢失流程。
·某些传入参数是否合理：判断某些接口的参数输入是否是冗余的，比如输入A字段可以满足A接口里面的所有操作，那么多输入一个B就冗余的。
·数据库字段的设计，数据库的设计是对实际业务的映射，我们要保证每一个字段的出现都反应实际业务并且经过合理性的验证，比如设计table1的时候A字段 在table2中已经出现，并且A和B表有相应的关联，那么要注意A字段对于table1的冗余是否有合理性，如果没有合理的说服性可以去掉A，而节省对 A字段的维护成本（存储空间，更新操作等）。
·某些判断是否合理，比如某些参数的输入金额是否可以为0的判断等等。
·系统交互是否合理，比如在代码设计的时候没有关注考虑系统交互的顺序而造成有些信息不能获取到；比如获取支付方式的费率信息必须要等待支付的时候才能拿 到，那么获取这些信息就应该放在pay_trans的时候而不是create_trans，大多数这种问题其实都是详细设计时出现的，代码评审阶段比较少见。
·是否有异常处理机制，一个好的代码设计应该考虑各种异常并对相应的异常做出合理的处理，比如接口的可重入，当代码检测到有重入的这种情况，怎样去做这种异常处理使得调用方能捕捉的这些异常而进行后面的处理。
●关注业务可拓展性：
·我们的业务在不断的发展，每一个项目设计都会影响后续业务的拓展，一个好的设计应该考虑到后续业务的发展，而尽量避免定制化的设计。
●关注使用到的数据结构、设计模式和代码的性能（效率）：
·一个好的数据结构和设计模式可以增加代码的可维护性安全性和效率等，比如我们在设计的时候要考虑到不同的场景选择什么样的数据结构，有时候我们会纠结于 用map还是用hash_map，这时候我们要根据具体的情况具体分析；
·当我们设计代码的时候如果能用上系统提供的函数那么最好不要自己去写，比如自己实现一个链表的时候是否可以想到用系统库提供 的list_head以确保链表结构的正确性；
·某些设计如果能套用设计模式会让设计更加美观也让阅读者更加明了；出于对系统性能的考量，我们要关注编写代 码对系统的开销，包括使用的算法是否合理，以及对某些比较耗时的操作比如数据库的操作要加以关注。
2.检查检查代码可读性和可维护性：
●如果代码的可读性强，那么维护起来也就方便很多；一个好的代码规范和编码风格会节省大家对代码的理解时间，减少维护成本虽然我们有代一些编程规范的价差工具，但是有些东西还是检查不出来而靠大家去规范的。
●关注代码注释：我们在编写函数和进行逻辑判断的时候最好要标注一下这个函数或者这段判断是用来做什么的；做了这种注释的好处，一来当别人阅读这段代码的时候看到你的注释以后就会根据你的思路快速理解代码，甚至不阅读直接跳过；二来防止自己由于长时间不阅读代码而忘记这段代码的用途。
●关注命名规范：虽然我们有自己的编码规范，但是这种规范只是限制了使用驼峰命名法还是其他命名法；但是好的命名风格应该是看到变量或者函数名字就能“望文生义”，毕竟我们不能把自己写的所有代码都做注释。
●关注重复代码：如果出现大量的重复性代码，要考虑将这些代码抽象出来一函数，来减少代码的量增强代码的可读性
●关注繁琐的逻辑：如果一个简单的功能却对应大篇幅的代码，要考虑一下是不是有比较简单的实现方式，因为过于复杂的代码会给后来者对他的维护带来麻烦；如果没有简略的办法，一定要把注释写好。
3. 分享设计、技术、知识和经验
●在代码审查的过程中，大家往往更加关注去发现代码的不足之处，而将代码评审中传播的设计、技术业务知识能地位放低，而笔者认为被大家忽略的这些东西的重要性绝对不亚于去发现代码的错误。
●大家可以通过评审者介绍自己的代码去更加深入的了解业务流程，并且可以看到评审者使用到的一些算法、数据结构、设计模式甚至是系统架构等知识以及评审者在编码过程中踩过的坑；参与者可以通过这些信息提升自己的业务水平和技术能力使得整个团队的水平得到提高。
●除了参与者要有这种学习的意识以外，评审者也要想办法怎么让参与者更加快速高效的去理解代码评审中传播的知识，（也带有提升review速度的好处），笔者的建议如下：
●简单介绍一下项目的背景以及详细设计，介绍这些信息的好处有以下几点
·首先，代码的设计是按照详细设计来执行的，但是设计者在真正code的时候会出现一些变动，这些变动要给大家一个同步。
·其次，参与过详细设计的人可能由于没有直接参与的code，时间一长忘记了之前详细设计的流程，简单介绍之后就会让参与者想起，方便参与者的理解
·第三，对于没有参加过详细设计的人，在简单介绍过这些信息以后大致也有个了解，否则整个评审过程是很煎熬的（你懂的）
·总之，如果参与者对代码的信息不是很理解的时候就会造成参与者理解的难度，他们由于没有很容易的理解而不能提出建设性的意见，也难以学习到评审中传播的 知识；这点是很容易被大家忽略的，尤其是在跨团队代码评审的时候，准备不足和经验不是很足的人是很难理解对方在讲什么的。
●讲解code的时候最好是以接口功能为单位去讲解
·如果评审者一下子把所有的详细设计讲解完了，可能由于信息量比较大，或者设计到一些细节问题，参与者不能有效的记住或理解也会影响评审的速度和效率。
·还有在讲解的过程中，参与者可以随时根据自己发现的问题进行讨论，评审者可以在讲解的过程中分享一下自己才过的坑。
如何迅速完成CodeReview？
所谓的迅速就是节省时间，只要我们去尽量避免一些意义不是很大的事情就能节省一些时间，加快评审速度，以下就是笔者建议大家尽量不要做得事情。
1.不要可以寻找代码的bug
●有些代码的逻辑是比较复杂的，如果是很容易发现的错误，评审者在编码的过程大多数都会发现，那么剩下的不容易发现的错误应该交给测试人员去发现；
●如果参与者刻意去找bug将会是顾此失彼，忽略更重要的东西；当然如果有些bug你一样就看到了就再好不过了。
2.不要按照自己的编程风格去评论别人的代码
●有些人可能比较自负，会根据自己熟悉的编码语言或者编码风格去评论别人的代码；
●只要代码是符合命名要求也符合设计要求就可以了，不过还是那就话，如果编码者的确错误明显当然可以提出带大家讨论一下
3.不要带着抨击和质疑别人能力的心态去进行代码评审
●有些时候参与者可能是由于心情不好，或者感觉对方是新人就会可以的去抨击别人的代码，这样会带来一个问题，就是在模棱两可的问题上浪费时间；
●参与者可能认为A方法好，评审者可能认为B方法也不坏，这样就会造成没有必要的争论而浪费时间。
4.不要在不好确定耗时的问题上争来争去
●大家在讨论的时候如果某些问题讨论一段时间以后仍然没有结论，或者需要第三方去确认异或是评审者不能马上理解参与者提出的意见；
●把这些问题可以先记录下来，等到会议结束以后评审者将这些问题解决以后给大家一个反馈即可，这样就能节省很多时间。
5.不要听不进去别人的意见
●有些评审者比较自负，不愿意接受大家的意见，而造成不必要的争端和讨论；
●当然有的时候参与者的意见不见得是最好的，但是也可以是一个参照的方向，如果存在争论，这些建议也可以做成会议记录，评审者私下和建议提出者讨论以后给大家一个结论。
6.参与者最好不要自己都没想明白就提意见
●如果参与者自己没有想明白的事情就去提意见，那么评审者反问的时候会浪费大家的时间；
●参与者可以先将自己的想法大致记下来，在有空闲的时间想清楚了在提给评审者也是节省时间的办法。
总结
综上，给大家介绍了一些如何进行高效迅速的CodeReview思考的方向，这些方式的正确性还要有待验证；同时需要根据不同团队的实际情况做相应的调整，不过最终的目的就是希望我们的CoderReview能够更有效更迅速，以提升我们的代码质量和团队整体水平。本文是结合别人的经验和自己的经验总结而来，内容不一定完整，观点也只是代表个人，希望给大家有些启发和帮助，大家有更好的经验可留言反馈给我们。
作者：王宏宇，百度钱包支付发展部研发工程师。
（本资讯于2015-09-14首次发布）
