背景
今时今日，软件工程的开发工作早已不是一个人的单打独斗，而是一个团队的相互配合、共同前进。有位作家写过一句很流行的话，叫“一个人要像一支队伍”,而作为一个组织进行高效率的脑力生产劳动时，更需要追求的反而是“一支队伍要像一个人”，这个人走路不会同手同脚，四肢要协调，前进方向只有一个。
那怎么实现这个目标呢?Code Review，即代码评审，是必不可少的一个环节。
什么是 Code Review(代码评审)?
当一个程序员写完了一段代码后，由 另外的程序员 花时间来浏览阅读这些代码，并进行审阅。
Code Review 是以轮转的方式进行的，所以参与代码审阅的人有两种，分别是 作者（author 以及 评审者（reviewer） 。当作者将写好的代码提交给评审者后，评审者对这次变动作出反馈，作者根据反馈修改代码，并重新提交，经过一次或多次往返后，评审者 同意（approve） 这次代码变动，允许代码进入仓库保存，Code Review 就完成了。
制图来源
此时评审者要考虑的问题包括：
总体逻辑上的实效效果
检查是否满足了所有需求
之前的自动化测试需要额外做修改才能跑通吗
与其他模块之间有没有程序检查不出来的冲突
由此可见，Code Review 基本上就相当于老师在给学生一字一句地批改作业，学生订正后又交给老师再次检查，如此往复。因此，为了节约精力，以便代码审阅工作可持续性开展，评审者可以交给程序去处理的问题包括：
发现代码中的 bug 与错误
代码风格和编码标准的统一
Code Review 的好处
热力学三大基本定律中有一条叫“熵增原理”，即：一个孤立系统总朝着混乱无序的方向发展。软件工程也是如此，如果没有人把控输入的代码，只管一个劲地堆砌，久而久之，这坨代码也就失去秩序，成一团乱麻了，人见人嫌。所以在工程的一开始就引入代码审阅，可以非常有效地提高代码质量。
更重要的是，Code Review 是一个 双向 的过程，双方借助针对具体代码的交流，得以了解对方的想法，进行互相探讨，这是帮助团队中的成员 成长 ，赋予团队自我管理、良性发展的能力。归根结底，人才是首要的生产力。
高效进行 Code Review 的方法
版本对比 / 文件改动
在“上古”时代，代码作者在开始 Code Review 前，还需要手动做一份**变更列表(changelist)**，来告诉评审者这一次提交做了什么改动。得益于 Git 的诞生，今天的我们可以借助基于 Git 版本控制系统的平台，来更轻松无痛地开展代码审阅，比如「CODING 企业版」，作为企业级软件研发管理系统，其提供的 Code Review 功能简单好用，能大大提高代码审阅效率：
借助 Git 自动实现精细的文件改动，红色代表删减，绿色代表新增，支持行级评论，再也不用在不同工位间来回走动，直接在具体代码下进行交流。
资源关联
代码不是孤立的一串文本字符串，而是实现目标的其中一项资源，那么必然需要与其他资源相互组合才能掌握全局。落实到代码审阅中也是如此，放到具体的上下文环境里方能见微知著：
「#」关联任务、文件等资源，「@」通知相关同事，实现垂直关联场景下的精细调控。
多人协同审阅
不同的人有不同的思考方式与见解，对同一段代码能从不同的角度出发考虑。尽可能的让不同的人 reivew 你的代码，不仅会有更多的人日后有能力维护你的代码，也是一个增加团队凝聚力的好方法。
学会享受 Code Review
不用担心收到批评面子过不去，也不用一枚追求“同意+1”，代码审阅是一个团队生机勃勃的象征，这里面的每一个人都在相互鼓励、相互交流以及相互进步，参与其中，与团队共同成长吧。
|
