代码评审是在软件开发流程中非常重要的一环，由于这个环节需要开发具有一些在写代码时涉及不到的能力，如沟通能力、判断力等，所以这也可能是最具有挑战的环节之一。一个功能的代码可能被写成N种不同的形式，这些不同的形式一定程度上决定了执行效率、可维护性、可读性等方面。这些方面大部分情况下很难通过机器来识别，所以代码评审环节不可或缺。
我们先来看下它的定义：代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。（来自百度百科）
上面定义中提到了两个比较关键的词：
-
编码标准
-
质量
编码标准，并不只是代码是否符合团队的代码规范。代码规范的检查绝大部分是不需要人去做的，用代码规范检查工具就能很轻松的完成，比如前端里面的ESlint。这里，我认为更重要的是评审代码设计及可维护性，比如：
-
代码逻辑间是否足够的解耦
-
复杂逻辑是否有明确的注释
-
可能出异常的逻辑是否有异常处理
-
......
还有很多其他重要的评审点，这里不对这些点做详细讲解，后面会出一篇专门讲怎么进行代码评审的文章。
代码的质量直接或间接的决定了产品最终的质量。有的代码是有明显的逻辑错误，而且还是分支错误。如果测试同学漏测了这个逻辑分支，那这个bug就可能会被用户发现，对产品口碑造成影响。有的代码逻辑耦合，虽然不一定马上出bug，对当前版本无较大影响，但随着时间的推移，后面的同学就有可能改动到这块代码，高耦合的逻辑让接手的开发无从下手，就好比拆炸弹，线路错综复杂，一不小心就剪爆了，bug随之而出。
所以，上面两点就是代码评审最基本的目的，保持编码标准统一与提高产品质量，从而提升整个产品的质量。
但，还没结束。上面的两点，都是代码评审带来的非常直观的收益。那还可以思考下，有什么其他好处吗？
在我看来，代码评审除了对产品质量有较大的好处，也对开发团队带来很多其他方面的收益。
1.通过代码评审来成长
假如你是一个菜鸟，在代码评审的过程中，你有机会看到比你厉害的人是如何实现某个功能逻辑的。你可以学习里面的设计并吸收，运用到自己的开发中。长此以往，你的代码水平就会提高。
假如你是一个老手，你能借助你的经验，发现菜鸟代码中的不足，提出来让他们改进，甚至指导他们应该怎么写。这不仅是在帮助菜鸟提高编码水平，同时也能帮你提高自己对代码的鉴赏能力，也间接提高了你的影响力。
2.提升团队的技术氛围
代码评审中发现问题时，审核与被审核的人会讨论代码中的问题。在互相交流中，不仅能使双方达成对代码规范的共识，还逐渐形成良好的技术氛围。在上一篇谈技术氛围的文章中讲到，技术氛围就是大家在一起讨论技术，有时候会被优秀的代码所折服，有时也会为一个设计争的面红耳赤。
3.技术备份
不做代码评审，往往自己写的代码，只有自己最了解。这就会导致一个问题，假如负责某个模块的同学休假或离职了，而其他人又对这个模块不熟悉，那后面在这个模块上继续开发就会变得相当的困难和痛苦，当开发接手一个经过时间堆积起来的代码模块时，会束手无策，因为，之前对这块没有一点了解。此时必定会损耗较多的时间来熟悉这块的内容，这会严重影响一个处于快速迭代期产品的节奏。
如果在版本迭代的过程中，持续的有代码评审这个环节，那起码同一个模块是至少有2个人了解的。这类似服务多机部署，没有人将会是整个系统的关键路径。在出现问题时，都有另一个人可以顶上。
这是一个好事，起码，你可以放心的去度个假。
大部分开发小哥，内心都渴望自己写的代码被其他人认可。所以当知道自己的代码会被别人评审时，开发过程中会付出更多的努力让自己的代码写的更符合规范，逻辑清晰。换个角度思考，如果你去评审一个不写注释，一个函数几百行的代码，你一定会默默的骂娘。当然，你肯定也不期望是被骂的那个，所以你会好好写。这是一个非常好的良性循环。
题外话：
很多时候，你拿到的代码是令人发指的，问题很多，想骂人。但请克制住自己的怒火，找出主要的问题点，委婉的讲给作者听。别炸锅了，造成两个人的冲突，得不偿失。
之前听一位高人说过，代码评审应该是开发人员之间的社交活动，需避免形式化的推行让这个活动变得无趣。想想，是有那么点道理。
下一篇会具体聊聊如何进行代码评审