注重纪律——读《浮现式设计》有感

题记：正在读《浮现式设计:专业软件开发的演进本质》(荣获第19届Jolt生产力大奖)一书，顺手写下了一点自己的感想与浅见，是以为记。

这一章的主题是单元测试，给我带来了很多思考。
首先就是测试经济学，作者为我们带来了非常有趣的辩证逻辑：
大多数软件开发专业人员都会称赞测试的好处，而大部分现代软件开发过程亦会包含测试，将其作为项目中必备的元素之一
许多软件开发人员除了确保他们的代码能够编译成功（让我们看看它是否能够运行）并进行手动的功能测试外，并不会做任何的测试

这两个现象在我身上的体现都很明显，一方面我也在推动工程过程当中重视测试并建议引入单测，另一方面我也与许多软件开发人员一样，认为单测的成本太高。“我太忙了，写不了测试”，“如果我写单测，就没时间写代码了”，“我的代码都已经实现功能了，为何还要去写单测来再次进行这个无谓的不严谨的证明呢？”
其实在三章前的内容里，作者提到可测试性是一个基本的质量准则时，我就开始反思自己对单测和测试的认识。在我的众多代码实践中，我是忽视了可测试性这个指标的。而且只看到了单测的成本，而没有看到单测的收益，甚至都没有给自己找个理由来试行单测。尽管软件工程的理论学了不少，但还是单纯的把测试作为了一个工程阶段，没有与开发融合在一起。即使使用了敏捷开发方法，也没有重新审视在敏捷方式下编码和测试的变化。
据我了解，单元测试在很多类型的开发领域中都已经或正在起着越来越重要的作用，并且获得了很好的收益，在代码质量上均有所提高，比如server开发。不过在需要快速响应变化的移动客户端领域，还很少有较好的施行单测的案例，一方面是在这方面的单测框架、技术还没有那么丰富的积累，另一方面可能受到开发方法、设备、快速变化的需求的限制。但是本章中作者已经展现了测试的收益给我们，我想这是我要弥补的地方了。
最后用作者的原文结束本章。
编写测试是对类的预期行为进行研究的一个过程。在动手之前先理解自己要做的是什么，这会让你对整个工作流程有更清楚的认识。
测试为重构提供了安全网。浮现式设计是一个渐进的流程，也就是说会出现很多变更（甚至比我们习惯的还多）。要想积极地做出变更，则需要进行测试，以确认我们没有破坏任何东西，从而增加我们进行变更的信心。
测试是一种文档，它记录的不是类是如何运行的，而是表达了从外部视角看，类应该做什么。

——欢迎转载，请注明出处 http://blog.csdn.net/caowenbin ——