敏捷开发“松结对编程”实践之五：代码检查篇（大型研发团队，学习型团队，139团队，师徒制度，代码审查）

本文是“松结对编程”系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八）

松结对和紧结对不一样，两个人不是总坐在一起随时发现问题解决问题，而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个：一是看结果是否符合需求（做什么），而是看代码是否存在问题（怎么做），后者就是代码检查。

代码检查（也称代码审查Code Inspection）是一种由来已久但是很神秘的东西，最初引入是在一些生命攸关、重大财产相关的软件开发中，典型的就是SSOS（美国航天飞机的软件），其每段代码都交由6个人审阅，方可入库。成果就是在1989年之前（之后笔者没有数据），SSOS在太空中失效次数只有一次。笔者亲身参与的代码审查活动包括某数字电视CA系统的代码审查（25个程序员只有1个测试，已用于CCTV）、某电信计费系统的代码审查（一周发现2400个缺陷）、某电信运维系统的审查（2天发现200个重要缺陷，其中1个已困扰团队5年）、某航空无损检测系统的代码审查（交付后一年内客户只发生一次失效）。

代码检查的基本原理就是相信人脑（而非人眼）是判断代码好坏的最好工具，比如如果代码中有一行：if (i == 1001) return die()的错误或非法代码，几乎无法经由测试包括自动测试发现，但肉眼却一目了然。

笔者曾编写过一个“复杂而彻底”的代码检查培训教材，但后来发现过于复杂而且还不彻底，所以作罢。下面将要介绍的是一种业余但却有效的代码审查方法。

-----------------------------------------------------------------------

程序员的质量观

有人曾把程序员分为四级：编写可用软件（大致是大学在校生的状态），编写可靠软件（大致是好一些的职业程序员的状态），编写精美软件（在简单性/可维护性/可复用性上有所突破），编写思想深邃软件（设计模式、MVC、JQuery及早期OLE、RPC等创始者所做的事情）。

但在现实中，却往往发现很多程序员停留在第一层次：“你测吧，测出缺陷来我改”“这个不用改也能运行”“这么编就是难读点而已”，师徒间的代码检查，就是把程序员从第一级别向上提高的过程。

第一段提到的25个程序员+1个测试人员的团队是01年我们所在的团队，当时保持了良好的质量风气。尤其由于大家知道没有测试人员擦屁股，留下缺陷相当于给自己找麻烦，所以大家不得不习惯自己动手防患于未然。这个产品后来发展势头很好，07年曾占据市场60%（之后不详）。

怎样检查

“高手本来自己就要开发很多代码，还要替新手检查代码，多花费时间啊……”这是一个常见问题，答案是：“每天，在后检查点，花费不超过15分钟时间，能看出什么来就说什么，时间到了就停。”

一般而言，大致每天高手能编写100多行有效代码（按分号计数），新手会多一些但也不超过200（他们编写代码比较费），也就是10个屏幕以内。有经验的人一定知道：高手看新手的软件，5秒钟就能发现问题。

常存在的一种情况是高手“看不懂”新手的代码，当然不是因为技术太精妙了，而是写得太乱了。但在松结对编程里边不存在，由于师傅徒弟天天在一起，这200行代码可谓一目十行，如果以往一直每天检查代码，那么里边存在的问题应该不会很多。

检查什么

这个是重点，整体包括：

1. 结构问题

代码最大的问题，不是一两个地方有技术缺陷，也不是业务逻辑错误，而是整个软件编写的不好。前两者都可以通过测试或使用来发现和更正，但后者就不同了。如果回想一下自己见过的各种烂摊子，是不是有同感？具体哪里有问题怎么改说不上来，就是整个软件看上去混乱无章，无从下手。

具体结构问题包括：重复拷贝代码（不封装函数，不用Template/泛型……），函数过长（超过一屏幕就叫过长），错误封装（不恰当的public/不用Interface/不内聚/强耦合/在类中封装了无关方法……），内容错误（多个无关类置于一个文件/不恰当的命名……）等等。

改正结构问题，是从编写可靠软件向编写精美软件迈进的重要方法。

（笔者博客中已经写了几个“编码简单性”的文章可供参考）

2. 业务逻辑问题

就是软件是否与需求的要求符合的问题。师傅和徒弟经常对业务需求的理解有差异，借此机会同步一下，必要时引入PO（产品经理/策划人员……）。

有人会说业务逻辑问题不是一测试就知道了吗？可是测试一般发生在很久以后，有些逻辑测试还需要一定的触发条件，而且测试只会发现失效（failure, 与预期不符）而不能发现缺陷（defect, 具体哪里出了错），等积累长了，谁也找不到原因了。

3. 编程素养问题

很多问题属于那种“这样也行那样也行”的状态，比如命名/初始值/缩进/断行……但是高手的做法总是比新手好一些。

比如bool result = true; 这句话就有问题，刚初始化就先宣布成功，必有隐患。这是一个真实案例，而下面也的确有一个分支错误地返回了这个true（实际案例是个HRESULT）。而发现这个问题，不是测试而是代码检查。实际上测试几乎发现不了这些问题，比如上面那段代码会在某文件打不开的时候错误地返回这个true，而在测试中几乎不会故事破坏那个文件来测试其结果。

实际使用时，不用拉太长的清单，师傅能想到的看到的告诉徒弟就行。

徒弟不需要学到天上去，只要能学到师傅那么好就可以了。之前在做CMMI咨询的时候我弄过一些检查表，推广均以失败而告终。那些表都是为了顶级安全性的软件考虑的，在普通项目里边使用是个灾难。

几个问题

1. 师傅天天检查，会不会很累？

检查不全是为了发现缺陷，而是为了提高成长。如果总是发现重复问题，此徒不可教。好学的徒弟有半年时间就能接近师傅了，考虑到师傅一般比徒弟多工作2年，我们因此让一个人加速1.5年。

2. 不会饿死师傅吗？

会，也不会。如果师傅止步不前，即使他不教别人，也迟早被人超越；师傅也是需要学习的。事实是会教徒弟的师傅才会学习，而会学习的师傅才会教徒弟。

3. 师傅跟谁学？

师徒制度是最底层团队制度（1个师傅+1～3个徒弟左右），其上还有更大的结构和更高的高手。我们之前曾把人员层次设为需指导的（徒弟）/可免于指导的（也是徒弟）/可提供指导的（师傅）/可培训的（团队最高级别的高手），最后一级需要定期与大家分享内容。

师傅作为高级技术人员，还享有机会外出培训/采购图书等待遇。

师傅自学也很重要，经验更是不可取代的。前事不忘后事之师，要把自己的经历和别人的经历都当作经验来看待。

4. 师傅努力编好自己的软件不久已经有很大贡献了，为何要帮助徒弟？

软件整体是一个串联系统，一个环节出了问题整个软件崩溃（Web软件好一些）。因此软件质量取决于最差的部分，而不是最好的部分。

代码审查的确会占用时间导致最好的部分变差，但却使最差的地方变得好得多，整体质量因此而得以提高。

------------------------------------------------------------

从工作层面讲，代码检查使得代码的质量尤其是结构质量，整体上保持在师傅可能达到的水平，从而保证了项目的成功。

从学习层面讲，代码检查使得徒弟可以不断/渐进地学习，从而花费远远低于师傅的时间成本达到更高层次。

心态是其中的关键。徒弟不能因此而觉得有一个后盾了可以放任存在问题等师傅发现，要珍惜师傅的时间，也要利用师傅的时间每次都学不同的内容；师傅也不能觉得徒弟学会了对自己是个威胁，威胁时刻都在，不来自于自己的徒弟，也会来自于别人的徒弟，唯有自我提高。

至此所有实践层面的内容基本上都写完了，下一篇将提到一些“139团队”的问题，所谓“139团队”就是一个使用松结对编程工作方式的大型团队。

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》