解读Code-Review

从项目管理角度来说，Code-Review是QA（Quality Assurance质量保证）方法的一部分，是持续性周期性而非一次性的工作，是团队成员交叉进行而非自上而下的工作，是需要结合业务需求而非纯粹技术性的工作。

 

Code-Review的目的

 

1、审查代码质量

2、从业务角度白盒测试

3、整体提升团队专业水平

4、人员互备

 

以上的最终目的，是保证交付质量。

 

Code-Review的内容

 

1、是否存在性能提升空间

2、是否符合开发规范

3、是否存在安全隐患

4、程序是否健壮

5、是否完整覆盖并正确满足了需求

6、是否满足可读性和扩展性

 

以上每一个小点，都可以展开一个大篇幅，这里就不说了，感兴趣的小伙伴请评论回复 我们共同探讨：）

 

Code-Review的常见误区

 

1、Review是一次性的任务？

 

它既不是一次性的，也不是任务。

与重构类似，Code-Review是技术性工作，但是都需要周期执行；

它是一组质量保证动作却不是任务，Reviewer的专业水平决定了执行的性质和质量。Review机制的建立有助于团队成员提升项目意识和质量意识，机制建立后，执行的动作应该是全员认可的，自发的，有目的的，而不是摊派的。

 

2、代码行数越多越好/越少越好？

 

面向对象的的高级语言已经不能用代码行数来衡量工作量了，高内聚低耦合开发原则和设计模式的应用使得代码复用程度大大提高，代码多的软件未必是好软件。

 

相反，如果滥用语法糖（如LAMDA表达式树等），确实可以将原本十几行（如果愿意，也可以是上百行）的代码写成一行，虽然炫了技，但可读性大大降低，也给调试带来了不便，所以极至的追求减少代码行数也未必是好的。

 

3、Code-Review是纯技术性工作？

 

Code-Review和重构工作一样，是一个开发工程师向架构师转变的必经的环节，而架构师是业务和技术的桥梁，对业务的Sense是潜在架构师必备的能力。

 

Review过程中除了从技术角度审查代码以外，还应能从业务角度检查需求的完成情况。Review的最终目标并不仅仅是代码优秀，而是交付优秀，这其中的偏差请大家细品。

 

Code-Reivew是技术人员主导但需要结合业务需求而进行的技术工作。

 

4、Code-Review可以代替单元测试？

 

单元测试的过程，其实包括了Code-Review的动作。当你Mock一个方法时，要熟知方法体内的逻辑，才可以写出针对这个方法的完整单元测试用例。你的Review不充分，那么单元测试的覆盖度一定不高，所以可以说，一个好的单元测试可以代替Code-Review，因为好的单元测试的前提是Review充分、覆盖全面的，但反过来 “Code-Review可以代替单元测试” 是不成立的。

 

5、通过尽可能多的异常捕获来提高容错性？

 

首先能想到用异常捕获来提高容错性是好的，至少比没有捕获的异常抛给用户是个进步。但如果能在此基础上，有针对性的通过逻辑判断来定位并处理每个错误，减少异常的产生，在程序性能上会有非常大的提升，因为每个异常的抛出，程序框架和操作系统都要协同提供很多信息，甚至有时会包括硬件信息，性能方面是非常大的开销。所以在保证容错覆盖率的情况下，尽量手动找错吧，不要依赖TRY-CATCH。

 

6、判断条件的先后顺序不重要？

 

程序当中的多个IF条件的先后顺序，与SQL中的WHERE后的条件语句一样，先后顺序不同，对执行性能有非常大的差异。

不想赘述，大家查一下在 where 1=1  开头的SQL执行时，执行计划是怎样的，百度有很多。

 

作为Reviewer，应该严格审查条件语句的先后顺序。从性能和逻辑方面。

作为Developer，如果之前没注意，现在开始注意吧。和上面的TRY-CATCH问题一样，对性能的重视，是除了Code-Review和重构以外，开发人员成长的另一个必经环节。

 

7、匿名方法、LAMDA表达式树、设计模式等面向对象的产物，多多益善？

 

语法糖在某些情况下，会使代码变得优雅，但它们均无助于性能提升，过度使用却会降低可读性和扩展性。

 

设计模式的初衷是为解决特定场景的问题，当你的问题对于这个设计模式来说并不是那么适用时，不要生贴硬靠，完全可以利用面向对象设计原则来重新设计你的应对方案。设计模式不止23个，那只是从无数个应对方案中挑选出的最具代表性的23个，不要让前人总结的成果限制了自己的视野。

 

语法糖和设计模式，FIT就好。

 

总结

 

Code-Review并不是形式主义，它有一套完整的方法论以支撑QA的工作，只是技术（仅指高级语言）发展太快，Review的对象随着每一个框架的诞生和语言的进化，都会有不小的变化，这就是贴近业务的高级语言的特点，我们应该认清现实并乐观应对。

 

对Reviewer来说，对技术的掌控，对业务的理解，对整体将要交付的这个软件的定位，甚至对所有项目干系人的了解，都将影响Review和最终交付的质量，是知识和经验的综合运用，在Review的同时，如果能建立一套先进的开发标准和足够高的视角，那么Review的过程对Leader自身也是一种提高。

 

 

原创日期20200408