敏捷开发“松结对编程”实践之五:代码检查篇(大型研发团队,学习型团队,139团队,师徒制度,代码审查)
Posted on 2011-07-09 14:10 阳光VIP 阅读(98) 评论(0) 编辑 收藏 举报本文是“松结对编程”系列的第五篇。(之一,之二,之三,之四,之五,之六,之七,之八)
松结对和紧结对不一样,两个人不是总坐在一起随时发现问题解决问题,而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个:一是看结果是否符合需求(做什么),而是看代码是否存在问题(怎么做),后者就是代码检查。
代码检查(也称代码审查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团队”就是一个使用松结对编程工作方式的大型团队。
点击下载免费的敏捷开发教材:《火星人敏捷开发手册》