“测试驱动开发”重构设计复杂性

Question

我目前正在研究测试驱动开发。如果我们在每两个单元的开发之后进行重构，而不是在时间上更加分散的专用重构会话，我正在询问设计的改进。

我知道技术债务会更大。但我想知道其他影响。当有更大的时间间隔时，重构过程可能没那么有效，因为......？

谢谢..

Answer 1

对于TDD的基本定义，您编写一个失败的测试，编写将使测试通过，重构，重复的最小代码量。推迟重构的空间不大。 ;）

我认为这有很多原因，主要是因为像我的老板这样的人在假设“重构”这个词是重写的极客代码字时是不正确的。编写一种方法，比如从网络上获取一些信息要容易得多。你编写测试，让它通过，然后说，“好的，现在把这个硬编码的URL移动到类的顶部，或者属性文件。”一旦你的课程完成并且在数百行或更多代码中称重，那么要做的难度更大。

设计部分进入的地方，在大“D”设计中较少，至少在我对TDD的理解和使用中，而不是在它鼓励和/或要求的良好实践中。回到我的用例，好吧，我已经编写了我的方法来获取我的数据，现在我需要用它做一些事情，我是否回去开始向我的getData方法添加代码？不，当然不是，它“完成了”。我继续写一个或者三个新方法来处理数据。所有方法都保持简短，在任务上，可测试，简而言之，是一种更好的代码设计。

我认为这就是混乱的来源.TDD产生设计更好的CODE，可能会产生更好的软件，但如果整体系统设计不好，那么宇宙中最好的编码实践不会产生好的产品/系统。

当然是YMMV。

Answer 2

我发现短迭代结合TDD /持续集成效果最好。

长迭代具有以下缺点：

1）你忘记了自己在做什么 2）很难估计你可以在2个月内做什么比说1周 3）它使业务持有者没有时间重新确定开发任务的优先顺序。

短周期更容易：“我必须在本周完成a和b”。你保持专注。你的会议时间较短。您的TDD和持续集成可以让您了解代码的状态。

你的重构问题，我认为你应该在你去的时候进行重构。在你进行重构之前，你不会以错误的方式做几周。通过测试，您将很快能够看到重构中断的地方。

编辑 - 对于更长的开发周期而言，另一个缺点是人们会自满：“呃，我还有4个星期以后生病了所有这些东西......”

Answer 3

应用TDD的一个有益的附带效果是您的设计趋于更薄和更健全。因此，重大的重构变得不必要了。在我看来，这是通过测试设计系统的效果，从“顶部”到“向下”（其中“顶部”是外部接口，约束和要求，“向下”是内部实现和合同）。有时我甚至对TDD意味着“测试驱动设计”而不是“开发”感到困惑。

因此，重新设计是由约束和要求的变化驱动的，而不是技术债务的驱动，而技术债务在最内层界面得到缓解。更改的范围将决定重构的范围 - 如果这是真的，只有当最顶层的接口发生变化时才会出现“主要”重构。

您提到计划的重构是长期开发周期中的一个步骤。我认为这是一个脆弱的策略，不是因为我们不应该清理技术债务 - 我们应该尽快这样做，而这是TDD的核心实践 - 但是因为风险很大。举例说明：为了计划您的重构步骤，您将如何评估技术债务的规模？如果估计的重构时间不够怎么办？如果你削减重构去做其他重要的事情，那么系统会健康吗？这些是重要的问题，而不仅仅是技术债务管理的问题。从风险管理的角度来看，TDD意味着更好的控制。