Code Review

什么是代码Review？

代码Review是指在软件开发过程中，通过对源代码进行系统性检查来确认代码实现的质量保证机制。查找各种缺陷，包括代码缺陷、功能实现问题、编码合理性、性能优化等；保证软件总体质量和提高开发者自身水平。Code Review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低很多，如果流程正确，它可以起到更加积极的效果。Code Review是一种传递知识的手段，可以让其他并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。Code Review也是在鼓励程序员提高自己。

                                                   

                                                                         

为什么要做代码Review？

• 提高代码质量，提升自身水平
• 及早发现潜在缺陷与Bug,，降低事故成本
• 促进团队内部知识共享，提高团队整体水平
• 保证项目组人员的良好沟通
• 避免开发人员犯一些很常见，很普遍的错误

 

代码Review的好处

1、在代码提交之前如果有很多双眼睛盯着看可以趁早发现bug，这是代码审查最广为人知的好处。如果代码已经上线，那时候受环境的影响，排查起来难度增大，往往需要很长的时间，才能发现一个小bug（有可能只是一个很简单的疏忽），根据经验和前人的实践结果，大部分的bug是显而易见的，在代码review的时候能够很轻易的就发现了。

2、代码Review最大的好处就是纯社会性的。如果你编程的时候，知道你的同事将要看你的代码，你的编程方式会不一样，你的代码会写的更加整洁，注释更加清楚，组织得更好。因为你知道其他人会看你的代码，他们的意见是你需要关注的。如果没有审查，你虽然知道人们最后会去看你的代码，但是那样不会给你一种紧迫感，也不会给你同样的个人评判的感觉。

3、还有一个更大的好处就是代码审查可以传播知识。在开发小组内，每个人都负责某一个核心组件，专注于自己的这一块，只要其他同事的模块不会破坏自己的代码就不会去关注，这种模式导致一个模块只有一个人熟悉对应的代码。另外，通过代码review可以相互学习好的编程习惯和优秀的编程思想，达到知识共享的结果，特别是初级程序员，可以经验丰富的人对自己写的代码进行评审，可以较快地提高编程能力。

 

CodeReview的目标和原则

CodeReview的目的是提升代码质量，尽早发现潜在缺陷与BUG，降低修复成本，同时促进团队内部知识共享，帮助更多人更好地理解系统（代码Review的最终目的是减少线上bug，使团队成员每个人都能有所成长，而不是为了考核开发人员。不要害怕代码审查，拥抱它，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，时间长会忘记之前详细设计的流程，简单介绍之后就会让参与者想起，方便参与者的理解；
  • 第三，对于没参与详细设计的同学，在简单介绍过这些信息后，可以有个大致了解，不然整个评审过程会很煎熬；
  • 所以，如果参与者对代码的信息不理解，会造成参与者理解代码的难度，也就不能提出有建设性的意见，同时也难以学到评审中传播的知识；这一点在之前的评审中是比较容易被大家忽略的，尤其是在跨团队代码评审时，准备不足和经验不足的同学是很难理解对方在讲什么的。