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