【敏捷开发每日一贴】代码走查

代码走查

怎样走查

“高手本来自己就要开发很多代码，还要替新手检查代码，多花费时间啊……”这是一个常见问题，答案是：“每天，在后检查点，花费不超过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软件好一些）。因此软件质量取决于最差的部分，而不是最好的部分。

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

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

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

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

----本文摘自CSDN文章