TDD能带来好的设计吗？

Question

我正在从“编写单元测试”状态过渡到TDD状态。

我看到约翰斯布罗德沃尔创造了相当可接受的设计，避免任何一个架构阶段之前。我很快就会问他，这是否真的是即兴创作，还是他事先有了一些想法。

我也清楚地明白，每个人都有经验，不能写出显式的设计错误模式。

但是，在参加了代码撤退之后，我几乎不相信先编写测试可以避免错误。但我也相信，代码之后的测试会导致错误发生得更快。

因此，这个晚上的问题是问那些长期使用TDD的人，分享他们对设计结果的经验，而无需预先思考。如果他们真的练习，并得到大多数合适的设计。或者这是我对TDD的一点了解，也许是敏捷。

Answer 1

根据经验：

TDD不一定会导致良好的设计。使用TDD来获得设计糟糕的程序是可能的，也是非常容易的。

TDD只是一个工具，可以帮助我们使用重构来更快地设计，它永远不会让程序的设计看起来神奇。TDD是一个设计帮助工具。您将从TDD中获得的设计质量在很大程度上取决于开发人员使用重构来设计模式或重构到坚实的原则的能力。

开发人员将使用持续重构使设计出现。这是TDD最重要的方面:重构。

在不进行持续重构的情况下应用TDD通常会导致设计非常糟糕的系统，这比应用BDUF更糟糕。

TDD经常与“紧急设计”的概念相关联。在敏捷中，您通常会逐步构建您的软件，逐个特性。所以你不能从一开始就知道你需要什么样的架构，它会随着时间的推移而发展/出现。因此，每当您添加新功能时，您都会进行一些重构，以改进应用程序的设计。它是连续的/增量式的设计。这就是为什么TDD是敏捷过程中的关键。

BDUF并不与TDD不兼容。在考虑设计的同时，启动一款软件并没有什么问题。然后，TDD将使您能够快速地将该设计放在适当的位置。如果您认为的设计是错误的，TDD将允许您很好地、安全地重构它。再说一遍，它只是一个工具，它的存在是为了帮助我们更快地开发我们的想法，更安全、更快地设计东西。

因此，您可以执行BDUF+TDD或紧急Design+TDD，后者由于迭代的工作方式在敏捷社区中更为常见。

在任何情况下，你都不应该尝试在不愿意做一些不断的重构的情况下去做紧急的设计，它们都是一起进行的，这确实需要很多的纪律。如果您继续添加新特性而不应用重构，事情就会迅速失控。

重构适用于生产代码和测试代码。

为了更深入地了解这个问题，我们可以在这里找到一篇有趣的文章：

向Sudoku Solvers学习

Answer 2

这完全取决于程序员是如何思考的：

1. 如果他们以前使用过TDD，那么就有机会获得好的设计
2. 如果TDD是从外部强加的，那么它只能打破程序员习惯使用的现有模式。
3. 另一方面，团队应该使用共同的模式，这样每个人都在创建同一个设计的一部分，而不是随机地走向不同的方向。

因此，这是一种平衡，在您想要强加的破坏性过程和您可以信任多少程序员使用他们自己的技术，以创造最好的设计。对程序员来说，获得关于以前代码有多坏的反馈是一个很好的质量指标。

Answer 3

毫无疑问，TDD导致更好的设计，TDD导致更好的代码质量，TDD导致更好的代码可维护性。

但是，TDD无助于创建没有bug的代码，就像它没有提供良好的设计一样。

对我来说，TDD是更快地解决问题的方法，仅此而已。也许是因为我是个糟糕的先见之明者。对我来说，从一些想法开始，然后再进行一些测试，就更容易了。

TDD并不能保证在一天之内有好的设计。正如你提到的，“生命的游戏”可能是一个很好的例子。我曾经用过一次纯实施。我刚做了一堆单元测试，一切都很好。但是，在我实现了一些UI并试图在64x64网格上运行游戏之后，这个应用程序的性能完全下降了。这意味着我有100%的代码覆盖率--但该应用程序不会在生产中运行。这种情况可以很容易地预测到我们在办公室工作的一些项目。

所以，我更喜欢另一种方法。让我们称之为post-prototype设计。一旦我有了一些TDD的工作代码(或没有)，我就开始更好地理解任务，开始看到不同的实现方式。我可以花一些时间在一张纸上找到一些设计思路。在此之后，我可以从头开始任务，或者重用已经创建的单元测试来实现这些想法。