敏捷开发“松结对编程”实践之五:代码检查篇(大型研发团队,学习型团队,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团队”就是一个使用松结对编程工作方式的大型团队。

 

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

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

 

你可能感兴趣的:(敏捷开发)