测试打破常规

　　过多的设置意味着不佳的模式。你应该只需要设置那些与你正在测试的类直接相关的对象。

　　尽量让单元测试精细化，这将带来可移植性更强的代码，并将它推向更加清晰、更加独立的实现。

通过回调制针测试

　　回调制针（backpointer）完全就是个麻烦事，应该避免其出现。它会带来相当多的异常，状态模式就是其中一个。一定要了解自己实现回调指针的理由。如果理由是“它会起作用”，那么你就在失去什么东西。

视图测试——将测试三要素实例化

　　在一个构造完好的应用程序里，视图层应该从域抽象出来，达到一种不需要创建视图就能够测试该应用程序的程度。不够精细的测试需要更加经常地更改。见上文测试打破常规。

　　这只是来自一个不断改进的小例子。我再提醒一遍，从简单的开始，保持其基本框架，得到所有人的同意。

连续集成
　　瀑布式方法的一个缺陷是代码库的集成往往每隔数周或者数月之久才进行一次。新的错误常常会随着代码的集成而不断暴露出来，我们不得不花额外的时间来更正错误并重新集成。如果集成不是频繁进行，那么反馈就不可能像应该的那么紧密。敏捷开发要求进行更加频繁的集成——在3Q的案例里，这意味着每天要集成一到两次。

　　大多数小组一般都会有一台构建计算机，成对的开发人员能够利用其检查在测试－编码－重整循环里编写好的代码。每对开发人员都有确信其代码在被集成到代码库之前就已经经过测试和重整。一旦检验完毕，自动化的构建计算机就会编译所有的代码，运行所有的测试，并通过显示器（向小组）显示出来——构建过程是否需要引起注意——例如：新加入的代码有没有破坏什么东西？

这会做两件事情：

·         从代码被集成（进代码库）到小组意识到存在问题之间的时间间隔会被减到最小。

·         构建显示器将信息传达给整个小组——不论是集成成功完成——还是需要引起注意——这让小组可以立即作出相应的反应。

　　像这样频繁的集成意味着软件的构建是不停进行的，任何人在任何时候都可以参与构建过程。构建过程需要被自动化，以便使集成尽可能地容易，这是十分重要的。下面就是3Q公司的构建监视器的向小组传达信息的一个例子。

　　就如上面图画所显示的，构建服务器能够向小组提供额外的信息。

重要的成功因素

o        自动化——这需要成为一个自动化的过程。否则你将不得不专门找一个开发人员来维持构建过程——这可不是一个有意思的工作。首先就要营造环境，取得设备和实现自动化。

o        TCR和配对编程——对于这一层次的集成工作，小组必须按照测试－编码－重整循环来进行，这样他们才有信心保证所有的问题只会发生在集成过程里。如果没有TCR循环，这一部分的过程将会非常困难。

o        按部就班——就像这个小标题说的，不慌不忙地从简单的地方开始，然后随着时间的推移来逐步改进——尤其是在代码编写标准这一块。

保持高效率——第三步
　　就如我们在《上篇》里说的，敏捷开发过程是一项工作强度很大的编程方式。除此之外，软件开发本身就压力重重，而小组累垮的可能性非常高。

　　可持续的步伐意味着开发小组现在和未来的工作都将非常艰苦。加班不是我们希望鼓励的事情，尽管有的时候需要如此。如果小组不得不加班工作，那么我们想要尝试将可持续步伐里的加班时间控制在一到两周而不是一到两个月。再强调一遍，敏捷开发是一项强度很大的工作；配对编程要求很多交互和重视，测试－编码－重整循环也是如此。尽管敏捷开发会引发我们小组的最大潜能，但是我们需要清楚很多时候的大量加班会累垮整个小组的风险。

重要的成功因素
　　这是管理者必须十分清楚的一个领域。确保小组在整个项目里保持合理的步伐是其主要职责。

开始转移到统一小组——第四步
　　有的人可能认为Metaphor的概念应该来得更早一些，但是我们建议在这一阶段快结束的时候才引入它，因为这是我们首次提到客户／业务方（customer／business）。Metaphor是客户与开发人员之间系统的通用语言。它看起来可能不重要，但是以Exoftware的政府顾客为例，开发小组一般都把业务方（也就是定义系统需求的人）当作客户。但是对于业务方而言，“客户”指的是最终用户。这就导致开发人员和“业务方”之间的困惑和挫折。

　　Metaphor的作用不只是一门通用语言——它还与上下文和对系统是什么的高层次理解有关。在这里我们能够采取步骤做到真正地与我们的业务合作伙伴沟通并共享共同的目标。3Q公司使用一种叫做Adaptor Tree Hierarchy体系，它通过一门客户／业务方共同认可的语言给予开发人员一个广阔的系统视野。例如：

ThreeQData

·         todaysDate

·         marriage

o        spouse

o        economicindicators

o        client

§         lossofincomestory

§  annualincome

§  coveramortisationeroision

§  ...

§         managedfundstory

§         pensionstory

　　这个树形结构的每一部分都可以扩展出更多细节，能够轻易地改变，并提供一个很好的系统视角，同为整个小组提供一门通用的语言。