code review真的很有必要！

前言

如果你不曾code review，那么你很难体会到代码中那些隐藏的真正乐趣。

上边的那句话是我最近时间的一段code review的真实感受，叹气，皱眉，扑哧大笑，在code review的过程中，各种表情扑面而来，真的是千人千面，代码所表现出来的也是参差不齐，所谓的乐趣，体现在各种匪夷所思的场景，真的是难以寻觅，也很难琢磨。

就比如下面这段代码，就不得不让人笑出声，有问题吗？哎，你还别说，运行手机上之后，只从功能上看，还真没问题，你让测试同学测10天，也很难从功能上排查出来，因为同样的判断，一次和多次是一样的，但是，从代码上看，就很直观的看出问题了，这样冗余且累赘的判断，简直毫无意义。

如果说上面的代码被称为卧龙，我觉得下面要举例的代码，可以称为凤雏，因为同样的配方，熟悉的味道，只是换了一种方式，和上面的如出一辙，简直就是典型中的典型。

以上的问题，不排除是开发同学在开发的时候由于手抖而造成，也不排除，这样的操作，确实有它存在的意义，毕竟存在即合理，但是，我说的是但是，在一个集体协作进行撸码的项目，有一定规范的约束下，这样的问题，尽量还是避免发生，因为实在是难以启齿。

类似的不规范之处还有很多，比如下面的几个例子：

1、逻辑相同

这个和上边那个例子是一样的，都是相同的逻辑，你if是它，else也是它，我想说的是，那你这个判断还有什么意义？

2、代码复杂度高

什么样的逻辑，能让你if使用那么多，当然了出了这种的上下判断比较多之外，还有一种典型的就是层级嵌套比较多，在正常的开发中，我们尽量避免这样写，一是性能上大大折扣，二就是代码上也显得冗余。

3、空逻辑

既然逻辑都为空了，我们还要它干啥，你说呢？显得好看，还是能提高自己的代码行数？

4、无用依赖

这种倒不是什么大问题，无非就是不太美观而已，但是，为了整体的代码整洁度，我们尽量还是删除比较好，毕竟也没什么用，其实也就是一个快捷键的事。

以上所出现的问题，均是在code review中审查出来的，试想一下，如果没有code review，那么这些奇奇怪怪的问题就会始终保留，无形当中，就会越堆积越多。

解决措施

针对以上不规范的代码，如何才能杜绝呢？我相信大家会有各种各样的方式，我也相信有的企业真的可以做到言必行，行必果，所有人的代码都是严格按照规范执行，但我更相信的是，大部分的企业在规范上都未必能做到十全十美，毕竟每个人都有每个人的意识，稍不注意，代码上就会产生分歧。

如何杜绝？站在我个人的角度上看，如果没有一个严格的管理措施，光靠一定的规范约束，工具的审查和人工的code review，真的很难做到百分百杜绝，所以，针对条条框框的规范，严格的管理措施才是重中之重！

1、从上至下的管理约束

code review必须从上至下，制定相关制度措施，严格按照执行，毕竟靠研发人员自觉的进行审查，这个是无法实现的，必须作为一个日常的任务，列入到实际的工作之中，才能初见成效。

我建议，这个要严，必须要严，决不能形同虚设，否则，code review真的很难执行，特别是大的团队。

2、代码未动，规范先行

要按照规范执行，必须规范文档先落地，只有参考的依据，研发人员才能按照文档进行规范化执行，这也是第一条的前提，也是日后代码书写的规范。

3、确定代码审查方式

代码审查方式，无非就是人工和工具审查，如果工具能够全方位的覆盖，则是最好的推荐，否则尽量加入人工的审核。

针对工具的审查，我一直也在不断的探索，之前分享过两篇文章，一篇是《一个便捷操作的Android可视化规范检查》,另一篇是，《Android打造专有hook，让不规范的代码扼杀在萌芽之中》，大家可以作为参考，相对于人工的介入，我更推荐于工具的使用，一是节约开发人员的审查时间，二是提高代码的审查效率。

4、code review执行方式

建立保护分支，合并代码之前，必须有人进行code review，规范则合，否则打回。

可以安排小组内技术优秀之人，作为审查代码人，组内其他成员代码合并前由他过审，这是一套运行机制，当然了可以安排多人，具体需要看实际的情况。

也可以每日时间段，比如下班前半小时，大家一起针对今日合并做集体code review，这样做的好处是，一是忙碌一天了，下班前也是最疲倦的，可以放松下身体，二是，集体审查代码的时候，也是互相学习的时候，看看彼此的优秀之处，三是，多一个人审查，更能全方位的查看，避免有遗漏之处。

5、code review抽查和记录结果

如何才能确保是否真正的进行了code review，这个是很难验证的，如果采取从项目的代码中去看，则耗时耗力，所以说这是一个制度和信任的结合，那么为了让code review能够最终的落地，则需要有人不定时的抽查code review并参与其中，这个人尽量是一个leader，否则毫无威慑力。

当然了，除了抽查之外，尽量code review之后，也作为一个简单的记录，记录在案，这么做的一个目的，只有一个，让code review真正的能够执行下去，并且能够按照一定质量的进行下去。

相关总结

作为一名近十年的老程序员，深知在实际的开发中，有些时候，时间紧，任务重，撸码的时间都不够，哪还有时间进行code review，我想，这是一部分程序员的心声，我想说的是，团队协作开发的项目，人员思想，技术水平不一，不执行code review，如何保证项目的规范化执行，又如何保证项目的稳定输出？虽然说屎山代码也能跑，但后续的维护，人员的介入，势必困难。

code review是验证代码是否规范的必经之路，不要害怕麻烦，也不要害怕耽误时间，否则，随着日积月累，项目的存在的问题则会越堆积越多，到后面才后知后觉，将会付出百倍的精力来维护。