TDD可以在没有前期设计的情况下处理复杂项目吗？

Question

TDD的想法很棒，但如果没有提前设计，我正试图解决如何实现复杂系统的问题。

例如，假设我有多种服务用于支付处理应用程序。我不确定我是否理解如果没有一个先前有点可靠的设计，开发将如何/可以在多个开发人员之间进行。

如果有人可以提供一个示例和高级步骤以这种方式组合系统，那将是很棒的。我可以看到TDD如何能够实现更简单，更健壮的代码，我只是不确定它如何将1）不同的开发人员集中到一个共同的架构愿景中; 2）导致系统可以抽象出行为以防止必须重构大量代码（例如，根据长期发展路线图接受不同的支付方式或定价模式）。

我认为重构是生产系统中的巨大开销，数据模型的变化会增加客户和公司的风险。

显然，我可能遗漏了TDD专家发现的东西......

Answer 1

恕我直言，这取决于球队的组成和风险偏好。

• 如果团队由几位经验丰富且优秀的设计师组成，那么您需要一个不太正式的“架构”阶段。它可能只是餐巾纸涂层的背面或白板上的几个小时，接着是激烈的编码来证明这个想法。如果团队是分布式的和/或包含许多不太熟练的设计师，那么在每个人走上自己的道路之前，你需要在设计阶段投入更多的时间/精力（思考和记录）
• 我能想到的下一个项目是先冒风险。持续评估项目的风险，计算您的风险/影响并制定缓解计划。首先关注风险和难以扭转的决策。如果决定很容易逆转，那就花更少的时间。

熟练的设计师能够以微小的步骤发展架构......如果你拥有它们，你可以在明确的设计阶段降低严谨性

Answer 2

TDD可能需要一些前期设计，但绝对不是大设计。因为无论你在开始编写代码之前你的设计是多么完美，大多数时候它都不会通过现实检查TDD强制它并且会在你的TDD会话中途爆炸（或者你的代码会爆炸）如果你绝对想把它弯曲到原来的计划中）。

TDD的巨大力量恰恰在于它可以让您的设计在编写测试和重构时出现并完善。因此，您应该从小而简单开始，事先对细节做出最少的假设。

实际上，你可以做的是勾勒出几个UML图表（如果你真的需要就你将要编写的内容的大局而达成共识的整个团队），并将这些图表用作测试的起点。但是，一旦你编写了前几个测试，就要摆脱这些模型，因为它们会弊大于利，误导你坚持不再真实的愿景。

Answer 3

首先，我并不认为自己是TDD大师，但这里有一些基于你问题中信息的想法。

我对上述＃1的看法：正如你所提到的，你需要预先设计一个建筑设计 - 我想不出没有这个可以成功的方法论。该架构为您的团队提供了凝聚力和愿景。您可能希望在前期进行足够的设计，但这取决于您希望的灵活程度。开发人员团队需要知道在开始编码之前他们将如何将系统的各个组件组合在一起，否则它将只是一个大的hackfest。

  

如果有人可以提供一个例子和高水平的话会很棒   以这种方式组建系统的步骤

如果要组建一个由服务组成的系统，那么我首先要定义服务接口以及它们将要交换的任何消息。这定义了系统的各个组件将如何交互（这将是您的前期设计的一个示例）。完成后，您可以分配各种开发资源来并行构建服务。

＃2; TDD的一个优点是它在重构过程中为您提供了“安全网”。由于您的代码包含单元测试，当您更改某些代码时，如果您遇到了某些问题，您很快就会知道，特别是如果您正在运行持续集成（大多数人使用TDD方法）。在这种情况下，您需要调整单元测试以覆盖新行为或修复代码以便单元测试通过。

  

导致系统可以抽象出行为以防止   必须重构大块代码

这仅仅取决于您的设计，使用例如一个strategy pattern，允许您抽象和替换行为。 TDD没有规定您的设计必须受到影响。它只是要求您只执行满足某些功能要求所需的操作。如果要求系统必须能够适应新的支付方式或定价模型，那么这就是您的设计要点。 TDD，如果操作正确，将确保您满足您的要求，并确保您的设计符合正确的要求。

  

我认为重构是生产系统中的巨大开销   数据模型的变化增加了客户和公司的风险。

软件设计的一个问题是它是wicked problem，这意味着重构几乎是不可避免的。是的，重构在生产系统中存在风险，但您可以降低风险，TDD将对您有所帮助。您还需要一个柔软的设计和一个低耦合系统。由于您设计的代码是可测试的，因此TDD将有助于减少耦合。编写可测试代码的副产品之一是减少对系统其他部分的依赖性;您倾向于编写接口，允许您使用模拟或存根替换实现。一个很好的例子是用一个返回一些已知数据的mock / stub替换对数据库的调用 - 你不想在单元测试中命中数据库。我想我可以在这里提到一个好的模拟框架对于TDD方法是非常宝贵的（Rhino mocks和Moq都是开源的。）

我确信有一些真正的TDD大师可以给你一些智慧的珍珠......就个人而言，我不会考虑用TDD方法开始一个新项目。