Microsoft官方出品：如何做Code review

爱因思念l5j0t8 2017-05-23

展开全文

为什么需要 Code Review

要了解为什么需要code review之前，先透过下面这张图解释，随着软件开发周期越后面的阶段或经历的时间越长，软件修复bug的成本越高。

软件修复成本与时间关系（资料来源）

为什么越晚修复，成本会越高呢？这跟技术债的情况相同，债会生利息，而这利息与循环利息和复利一样可怕。

开发越后期大楼越盖越歪，叠床架屋与贪快累积的技术债将导致程序包袱越大，也越难维护。

然而也因为只要是程序就一定会有bug，而越晚修复bug的成本越高，因此在各个开发团队中，希望有效降低软件维护成本最佳的方式，就是下列两种：

l提早发现bug并进行修复，让X轴的值小一点，自然Y轴所代表的成本就低一些。

l让程序尽可能地好维护一些，以减缓成本上升的曲线斜率。一旦曲线平缓一些，Y 轴所代表的成本自然也会低一点。

而进行 code review 则是有效满足上面两个目的：提早发现 bug 且修复，并让程序好维护一些。

什么是 Code Review

程序一定有bug主要是因为开发人员很容易陷入自己的盲点，常见的盲点有两种：

l程序是照你写的跑，不是照你想的跑。

l程序照你想的跑，但你想的是错的。

要突破上述的盲点，最简单的方式就是找别人来review你开发中或开发完的程序，跟你一起确认程序是否写的跟你想的一样，以及确认你想的是对的。

当然，review开发中或开发完的程序所发现bug的时间点，就是上图的Development阶段，如果希望能在Design与Developer阶段中就发现问题，来让bug根本不会发生，或是在第一时间点就被修复，这就是极限编程（eXtreme Programming）中所提倡的搭档编程（pair programming），这在实务上更是挑战工程师的人性以及管理者的极限，但以bug修复成本的角度来看，这的确花费的成本最低。

简单的说code review就是邀请其他人来帮你审查，原始码上是否存在着不妥之处，例如风格是否与团队一致、是否有哪边程序可读性不佳、有坏味道、不好维护、不好扩充、安全性疑虑、效能不佳、甚至压根就误解需求的问题存在。

有的时候「三个臭皮匠胜过一个诸葛亮」，臭皮匠有臭皮匠的角度，诸葛亮有诸葛亮的盲点，一定要记住「程序码是属于整个团队的」，不论自己写的程序再高超、再有效率、再有弹性，如果没有人可以维护，那就都只是空谈。

Code Review 会议的种类

Code review的方式见仁见智，个人觉得没有绝对最佳解，只有慢慢tuning出最适合团队的review方式，并建立起自己团队的文化、价值观与Code review的规范和流程。

但可以确定的是，当code review的频率越低，则代表着需要review的范围越大，可能重工的范围与成本越高，而上线的时间压力也越紧迫。团队往往会因为上线时间压力而导致空头review或略过review的动作，大家都知道哪些地方设计不好，却不进行修改。而code review的频率过高，相对会带来的overhead也会比较多。因此怎么调整code review的频率与review的重点就显得格外重要。

这边则针对几种不同的团队组成，提供几种常见的方式供大家参考。

一、团队中有大量新进工程师，较少的资深工程师：

这种时候通常新进工程师只有基本的教育训练或是由他们自行参考旧的程序与文件，对团队的开发标准（coding standard）、开发规范（code convention）、命名规则、系统架构、系统介接与领域知识不熟悉。他们需要由资深人员带领，透过实际的例子来对他们进行教育训练，只是训练的方式是以review新进人员所撰写的程序码来进行。

这种情况下 code review 参与人员几乎是整个开发团队，好处是透过一次实务的例子，就能让所有成员用最快的速度了解哪些错误不要犯，进而回去修改他们开发中的程序，避免犯同样的错误。坏处则是与会人员一多，花费的时间成本就会相当高，一定要确保 review 会议有效率且有达到效果。

这类型的 code review 频率建议上限一周一次。当新进工程师开始进入状况，了解团队文化与开发规范后，就可以减少这类型的 code review 会议，而往其他类型进行。

二、团队中资深与新进人员比例相当，或是彼此专长领域不相同：

这样的团队组成，建议可以进行daily的peer review，由资深与新进的工程师进行配对，或是由熟悉不同领域知识的工程师配对，每天花15~30分钟针对今天程序码异动的部分（Code Churn），彼此同步一下。一般一个开发人员每天可以产出新的程序码（不包含产生器自动产生的部分）行数约莫200~400行，因此建议要控制在半小时内review完毕，最好也可以把时段固定下来，如同Scrum的每日站立会议一样，尽速且小范围地针对原始码提供反馈与建议。而这样的范围也是最容易找出defect的比例，如下图所示：

LOC与Defect发现的关系图（资料来源）

这样配对的好处是，参与的人员较少，可以轻量化地进行review与沟通。在review过程中，只要出现程序码看不懂的情况，基本上可以归类为：

l程序码是对的，可能是新进人员的技术能力不够或是不熟悉domain的伙伴对需求不够了解：这时候可以针对技术或domain不懂的部分进行解说，趁这机会备份彼此的技术与领域知识，这是提升团队能力与彼此备援的一个重要流程，比起单向的一对多项目分享或教育训练，来得有效率地多。

l程序码是有瑕疵的，可能是新进人员违反了开发规范、较难维护扩充或设计出效能较差的算法，也可能是程序码的易读性不够，让其他工程师无法轻易了解需求与程序码的设计目的：这时也是协助他们修正与学习的好时机，建立团队的开发文化，就需要从平时开发的小细节着眼。

不论review后的程序码如何，可以确保的是，这一份程序码至少有两个人以上了解其意义，也就是拥有共识。并且透过这个机会来提升或备援彼此的领域知识和技术能力，将code review的价值最大化。

Code Review前透过工具的Preview

在进行code review之前，有一些开发规范应该要善用工具来作程序码分析，以节省review过程中所需要花的时间。透过这些工具与定义的标准，可以客观地审视与协助团队成员在开发时不会像脱缰野马、各自为政。下面列出几个开发规范相关的工具（以.NET为例）：

l统一命名标准－词汇表（Glossary）：可透过GoogleDoc、Wiki、Excel或其他知识管理平台来建立，属于自己团队领域知识的相关词汇，以及开发上的命名习惯。命名，是软件开发最基本也是最重要的一件事。

l程序码风格分析：可透过 StyleCop 来自订属于团队的风格规则模板，让开发团队可以随时检查程序码是否有违反风格规则。团队中程式码风格的一致性是易读性与可维护性的基础之一，风格没有绝对的对错，但当规范订出来之后团队就应该遵守，规范可以经过团队同意后进行调整，但程序码风格的检查应交给工具来做，才会快速且客观。如果code review还要花时间调整style，那就无法做到轻量化敏捷的review，时间一旦拉长，与会人员就容易失焦与失去耐心。

l程序码相似度分析：可透过Simian或VS2012 Premium以上的版本来进行重复程序码分析。重复的程序码一直都是坏味道的基本来源，如何快速的扫描出项目中有哪些程序码是重复的，可以帮助团队快速地找到程序码坏味道，检查是否违反了单一职责原则（SRP）中的同一份职责散落在不同物件中。团队也可以设定出自己的指标门槛，例如超过20行重复，才需要送出警告。

l程序码复杂度分析：可透过 SourceMonitor 或VS2010 Premium以上的版本中的计算程序码度量功能来分析循环复杂度。所谓的循环复杂度，简单的说就是程序码的分歧路径，可以想象如果一个方法中程式码可执行的路径越多，代表人脑要理解程序码意义的成本就越高，也代表程序码可能越难维护。因此复杂度太高也是坏味道之一，直接透过工具分析出复杂度，可以让开发人员在code review之前，就将这些可能不易懂的方法内容修正，以节省review的时间，也就是开发人员在开发时就透过工具来帮自己的程序码做健康检查，先行用工具review的意思。这边建议分析的报告可以显示前15个最复杂的方法来协助团队了解，目前项目中最复杂的方法是哪一些。而团队复杂度指标门槛建议可以限定复杂度在15以下，也就是复杂度超过15时，开发人员应说明原因，确认无法或不需要重构，方可通过审查。

l综合质量分析：可透过 FxCop 或Visual Studio的静态程序码分析来进行分析，团队可依据团队规范以及项目的性质，建立不同规则集。FxCop与Visual Studio的静态程序码分析其实核心是一样的，如果开发团队针对基本的安全性分析找不到免费或可信任的工具，建议也可以直接使用FxCop中的安全性规则，在OWASP上也有推荐使用FxCop来进行基本的分析。

上述的工具，除了在开发时期使用，也都可以部署在持续整合服务器（如 TFS、Jenkins）上每次建置时运作。不管是Daily build或是Checkin build，每次程序码有异动时，团队就可以在第一时间知道程序码的质量趋势是上升或下降。团队应建立质量文化，当build failed或质量开始出现缺陷时，必须用最短的时间修正，否则在破窗效应下，技术债就可能累积越来越多，最后形成焦油坑。

相对大于绝对，趋势大于数字

在使用程序码分析工具时，要避免成为数据的奴隶，这些指标报告就如同健康检查报告，红字不代表一定有问题，但一直红字就代表需要关注。而许多团队可能已经有既有的程序码或系统（legacy code），这时建议大家应了解质量指标数据不是绝对的，但一定要守住相对的底限。

所谓相对的底限也就是，不管原本的程序码质量有多差，在每一次程序码的异动后，经过每一位开发人员手中，程序码质量只能更好，不能更糟。因此，这些指标的趋势要比数字来得重要得多。只要每一次的异动，都能让质量更上一层楼，哪怕只是一个风格警告的修正，都能帮助产品更好。只要维持住这样的演进过程，就不用担心被技术债压垮，缺陷的趋势是收敛的，团队就能更有信心。