纳什维尔项目

我最近花了一些时间与我最喜欢的 Thoughtworks 项目之一在一起。这是一个始于 1998 年的项目，当时使用的是新兴的 J2EE 技术。多年来，它经历了一段引人入胜的历史：从 EJB 开始，到将其移除，再到将项目外包到班加罗尔，最后回到芝加哥。许多人进进出出这个项目，项目的人员数量在 6 到 60 之间波动。总的来说，这个项目已经投入了超过 300 人年的工作量，代码行数约为 10 万行。

我之所以喜欢它，是因为它体现了我对软件开发的偏好观点的一个重要特性：通过精心设计的代码库来长期支持业务功能。他们能够在十年后仍然为业务提供有价值的功能，这绝对值得称赞。他们能够在需要时快速添加新功能，因此没有陷入典型的遗留应用程序的泥潭。

这次访问中，我有一些想法引起了我的注意。

首先，他们在验收测试方法以及如何随着新功能的添加而更新验收测试方面经历了有趣的演变。在他们最初（也是常见）的观点中，每次实现一个新的 用户故事 时，都会添加一个或多个测试。这会导致一个简单的跟踪结构，其中每个故事都由一个或多个验收测试验证。但这种方法的问题在于，随着时间的推移，测试会变得越来越复杂，重复性也会增加。

在他们的新观点中，有一套验收测试，以 示例规范 的风格描述了应用程序的行为。每次他们执行一个新的故事时，他们都会决定如何更新这套测试以反映新的行为。这打破了简单的故事到测试的关系，但最终得到了一套更简单、更连贯的测试。

该项目第二个有趣的方面是它如何持续改进代码库。他们想出了一个很好的（尽管非正式的）指标来描述这一点。几年前，如果他们想招募新人，他们希望这个人至少承诺工作一年，这样他们才能在新人熟悉代码库后获得有价值的贡献。现在，这个时间缩短到了三个月。对于一个有如此多人参与的十年老项目来说，这是一个相当大的成就。

对我来说，良好设计的关键目的是它允许你继续快速地使用代码（设计耐力假设）。评估开发人员在代码库中变得高效需要多长时间，是衡量这种设计质量的一个好方法。最小承诺时间指标是这个想法的另一种体现。它不是我们可以客观地衡量的东西，但它是一个团队可以考虑观察的东西。

我希望更多来自该项目的人能谈谈他们的经验。他们去年做了一个播客（访问 Thoughtworks 播客 并搜索“保持灰色代码的健康”）。