代码质量保证体系（下）

书接上回，有关代码质量保证体系里勾兑的那些个卿卿我我，还有单元测试、持续集成、代码评审与重构需要与你道来。

 

单元测试

StackOverflow上一个有16.7k分的人问了个有关单元测试的问题“How deep are your unit tests?”，意思就是说“单元测试需要做多细？”，或者换句话说“单元测试的这个单元的粒度是怎样的？”

针对这个问题，下面的回答获得了压倒性的票数，被评为最佳回答。

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

老板为我的代码付报酬，而不是测试，所以，我对此的价值观是——测试越少越好，少到你对你的代码质量达到了某种自信（我觉得这种的自信标准应该要高于业内的标准，当然，这种自信也可能是种自大）。如果我的编码生涯中不会犯这种典型的错误（如：在构造函数中设了个错误的值），那我就不会测试它。我倾向于去对那些有意义的错误做测试，所以，我对一些比较复杂的条件逻辑会异常小心。当在一个团队中，我会非常小心地测试那些会让团队容易出错的代码。

翻译来自酷壳网的文章，这不重要，重要的是这个回答来自于KentBeck（敏捷开发XP与测试驱动开发TDD的奠基者）。下面是有人针对Kent这个回答的调侃。

The world does not think that Kent Beck would say this! There are legions of developers dutifully pursuing 100% coverage because they think it is what Kent Beck would do! I have told many that you said, in your XP book, that you don't always adhere to Test First religiously. But I'm surprised too.

只是要地球人都不会觉得KentBeck会这么说啊！我们有大堆程序员在忠实地追求着100%的代码测试覆盖率，因为这些程序员觉得KentBeck也会这么干！我告诉过很多人，你在你的XP的书里说过，你并不总是支持“宗教信仰式的TestFirst”，但是今天Kent这么说，我还是很惊讶！

持续集成

根据《重构-改善代码既有的设计》作者Martin Fowler大师在《持续集成》一书中的定义，“持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建（包括自动测试）的检验，以尽快发现集成错误。许多团队发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。”

通俗地说，持续集成（CI）需要对每一次代码提交走一次从代码集成到打包发布的完成流程，以判断提交的代码会对这整个流程带来什么影响。而这个过程中所使用的手法严重依赖于团队成员的多少、目标平台和配置的不同等因素。比如，只有一个人单干，同时只面向一个平台，那么每次有一个commit时，手工跑一下测试基本就知道结果，也就完全不需要其他更为复杂的工具与手段。

但是对于Linux、OpenStack等大型的项目来说，显然没有这么简单，涉及一个使用版本控制软件来维护的代码仓库，自动的构建过程，包括自动编译、测试、部署等，以及一个持续集成服务器。

代码评审与重构

首先，我们先来了解一个程序调试大法——“橡皮鸭程序调试法”，它来自http://www.rubberduckdebugging.com/，酷壳网（http://coolshell.cn/ ）上也有篇文章用中文进行了阐释，这里没办法解释得更好。

这个方法实施起来相当方便和简易，几乎不需要借助任何的软件和硬件的支持，可以随时随地地实验，你甚至可以把你的程序打印出来，在纸面上进行调试。

那么，为什么这个方法叫做橡皮鸭呢？一是因为橡皮鸭子貌似是西方人在泡澡时最喜欢玩的一个小玩具，所以，这个东西应该家家户户都必备的。二是这个方法由西方人发明，所以，就被取名为“橡皮鸭”了。下面是整个调试方法的流程：

 

 

• 找一个橡皮鸭子。你可以去借，去偷，去抢，去买，自己制作……反正你要搞到一个橡皮鸭子。

• 把这个橡皮鸭子放在你跟前。标准做法是放在你的桌子上，电脑显示器边，或是键盘边，反正是你的跟前，面朝你。

• 然后，打开你的源代码。不管是电脑里的还是打印出来的。

• 对着那只橡皮鸭子，把你写下的所有代码，一行一行地，精心地，向这只橡皮鸭子解释清楚。记住，这是解释，你需要解释出你的想法、思路、观点。不然，那只能算是表述，而不是解释。

• 当你在向这只始终保持沉默的橡皮鸭子解释的过程中，你会发现你的想法、观点、或思路和实际的代码相偏离了，于是你也就找到了代码中的Bug。

• 找到了BUG，一定要记得感谢一下那个橡皮鸭子。

这个方法是否让你感觉太“愚蠢”，太“弱智”了？不过，这个方法的确有效。因为，这就是“Code Review”的雏形！它的核心思想可以概括为：一旦一个问题被充分地描述了他的细节，那么解决方法也是显而易见的。

相信各位都有过这样的经历，当你死活都找不到问题的原因的时候，当你寻求他人的帮助时，对别人解释整个你的想法和意图或是问题背景的时候，你自己都没有解释完，就已经找到问题的原因了。这就是这个方法的意义所在。

所以，“橡皮鸭”只是一个形式，其主要目的是要你把自己写的代码做“自查”，也就是自己解释给自己听。当然，为了不让你像个“精神分裂”的程序员，引入“橡皮鸭”是很有必要的（虽然这样还是有点精神病，但比起精神分裂来说算是好的了）。所以，真实的本质是Code Review。

那么，对于Linux、OpenStack等大型项目来说，为了保证代码评审的有效进行，首先需要做的是为我们寻找合适的道具“橡皮鸭”，然后提供一个将这些道具和我们有效联结起来的平台。

对于这里另一个重要的步骤——代码的重构，简单的说，就是在代码写好之后改进它的设计，存在于我们测试、小修改、测试、小修改……这条不归路中。复杂来说的话，推荐大家可以去看看Martin Fowler有关重构的神作《重构-改善代码既有的设计》。

 

呆呆的天空

如我的脑袋

总是游荡啊，游荡啊

还好，岁月静好，一切从容。那么接下来应该会有两篇来分别看看Linux和OpenStack为了保证自己的代码质量又做了什么。

 

相关阅读

代码质量保证体系（上）

 

喜欢的话，欢迎扫码关（打）注（赏） ^-^