所以，你有可能在一种虚拟机上优化了性能，但拿到另一种虚拟机上，却减慢了其运行速度。对此，你要特别小心。对象池就是一个很好的例子。 很多人热衷于对象池，但起码有一半的情况下，人们并不去测量对象池的效果到底是好是坏。在 Java 的早期日子里，对象池非常重要，因为垃圾回收（garbage collection）功能还不是很完善。但在垃圾回收技术更新换代之后，对象池的效果就大大降低了，因为那些生存周期很短的对象可以被低成本地回收。只 有那些生存周期很长的对象，才适合使用对象池技术，因为对它们进行垃圾回收的成本很高。

　　从这里可以看出，规则也是在不断变化的。这就是为什么要对性能调优很仔细的原因所在。不要妄想根据源代码就能预测机器会做什么。当你与虚拟机或优化型编译器打交道时，性能调优是唯一的手段，因为编译器和虚拟机所做的事情，远远超出你的想象。记住，不要预测，要实测。

　　模式的意义

　　比尔：你在《设计是否已死》这篇文章中表示：“对我来说，模式仍然是至关重要的，”尤其是考虑到极限编程的话。那么今天，模式处于一个什么样的地位呢？

　　马丁：模式给了我们瞄准的目标。我还会做一些预先设计。模式就是用来干这个的。模式还给了我们以重 构的目标。我们得以知道我们改进的方向。了解模式还有助于我们找到设计美感，因为模式至少都是一些好的设计。你可以从它们身上学到很多。因此，我仍然认为 模式起着重要的作用。其实，很多积极推动极限编程运动的人，本身就活跃在模式社区里。这两个社区在很大程度上是重叠的。

　　敏捷宣言

　　比尔：最后一个问题，敏捷宣言到底是怎么一回事？

　　马丁：哦，那是一群投入到敏捷软件方法领域的人，聚在一起，彼此印证心得。这个领域包括极限编 程，scrum，crystal，修错驱动开发（fix-driven development），和动态系统开发方法（DSDM）。我们意识到我们之间有很多共同之处，因此决定把我们所认同的写下来。我们把这份宣言看作是一 种象征——在这面大旗下汇聚了支持此类方法的人们。在那次聚会中，我们决定使用“敏捷方法”这个词。这份宣言可以作为敏捷软件开发的一个定义。借助这份宣 言，我们共同呼吁，软件业的主流应该朝着这个方向前进。

　　比尔：让我们来看看四条原则中的一条：“个人与交互重于过程和工具”。这是什么意思？

　　马丁：这条原则大意是说，与其借重过程和工具来加强对软件开发的管理，不如更多地关注于团队及其成员，关注于每个个体以及他们之间在个人层面上的交互。

　　比尔：你是说提升他们的技能么？

　　马丁：要远比这个丰富得多。它包括了提升技能；它还包括要竭尽全力使程序员们身心愉悦，从而得以留 住人才；它还意味着更认真地对待个性冲突，注重人与人的相处，而不是试图找出某个完美的软件开发过程，然后要求大家都来遵守这个过程。我对这条原则的理解 是，应该是团队选择适合其的软件开发过程，而不是让团队来适应指定的开发过程。

　　尽管在那次聚会上，我们中的许多人都津津乐道于自己所采用的开发过程，并且我们当中的几个人还是软件工具销售商，但我们一致同意，对于一个项目的成功来说，软件开发过程和工具只是次要的因素，最主要的因素还是团队，是团队中的成员，是他们人性化的合作与努力。