tdd - 单一开发人员应该使用 TDD 的一些原因是什么？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

3年前关闭。




Improve this question




我是一名经验丰富的契约(Contract)程序员。我习惯于被客户雇佣，自己去做一个或另一种形式的软件项目，通常是白手起家。这意味着几乎每次都是白纸黑字。我可以引入我开发的库来快速入门，但它们始终是可选的。 (并且取决于在契约(Contract)中获得正确的 IP 条款)很多时候我可以指定甚至设计硬件平台......所以我们在这里谈论的是严肃的自由。

我可以看到为某些代码构建自动化测试的用途:具有更多功能的库、具有大量引用的核心功能等。基本上，随着一段代码的值(value)因大量使用而上升，我可以看到它自动测试该代码会越来越有值(value)，这样我就知道我不会破坏它。

然而，在我的情况下，我发现很难合理化除此之外的任何事情。我会采用被证明有用的东西，但我不会盲目地遵循任何东西。

我发现我在“维护”中所做的许多事情实际上都是很小的设计更改。在这种情况下，测试不会为我节省任何东西，现在它们也必须改变。高度迭代、 stub 优先的设计方法对我来说非常有效。我看不到通过更广泛的测试实际上为自己节省了那么多时间。

爱好项目更难证明......它们通常是从周末到一个月的任何东西。边缘情况的错误很少有关系，这都是关于玩一些东西。

阅读问题，例如 this one , 投票最多的回应似乎是说，在该发帖人的经验/意见中，如果您的人数少于 5 人，TDD 实际上会浪费时间(即使假设有一定程度的 TDD 能力/经验)。但是，这似乎涵盖了初始开发时间，而不是维护时间。目前尚不清楚 TDD 如何在项目的整个生命周期中叠加。

我认为 TDD 可能是朝着提高整个行业产品质量这一有值(value)目标迈出的重要一步。不过，理想主义本身不再能有效地激励我。

我确实认为 TDD 在大型团队或包含至少一个不可靠程序员的任何规模的团队中是一种好方法。那不是我的问题。

为什么拥有良好记录的唯一开发人员会采用 TDD？

我很想听听关于 TDD 的任何类型的指标(正式或非正式)......专注于单独的开发人员或非常小的团队。

如果做不到这一点，你个人经历的轶事也会很好。 :)

请避免在没有经验的情况下发表意见来支持它。让我们不要把这变成一场意识形态 war 。还有跳过更多就业选择的论点。这只是一个效率问题。

Answer 1

好吧，轮到我了……我什至会自己做 TDD(对于非尖峰/实验/原型(prototype)代码)，因为

三思而后行 : 迫使我在开始编写代码之前思考我想要完成的工作。我想在这里完成什么......“如果我假设我已经拥有了这件作品......我希望它如何工作？”鼓励对象的界面设计。

更容易更改 :我可以放心地进行修改..“当我更改步骤 5 时，我在步骤 1-10 中没有破坏任何东西。”回归测试是即时的

更好的设计出现 :我发现更好的设计正在出现，而无需我在设计事件上投入精力。测试优先 + 重构导致松散耦合、使用最少方法的最少类.. 没有过度工程.. 没有 YAGNI 代码。这些类具有更好的公共(public)接口(interface)、小方法并且更具可读性。这是一种禅宗的事情......你只有在“得到它”时才会注意到你得到了它。

调试器不再是我的拐杖 :我知道我的程序做了什么.. 无需花费数小时逐步完成我自己的代码。如今，如果我在调试器上花费超过 10 分钟.. 心理警报开始响起。

帮我准时回家我注意到自 TDD 以来我的代码中的错误数量显着减少..即使断言类似于控制台跟踪而不是 xUnit 类型的 AT。

生产力/流量 :它帮助我确定下一个离散的婴儿步骤，它将带我完成……让雪球滚滚。 TDD 帮助我更快地进入节奏(或 XPers 所说的流程)。我在单位时间内完成了比以前更多的高质量工作。红绿重构循环变成了……一种永动机。

我可以证明我的代码有效只需按一下按钮

熟能生巧我发现自己学习和发现龙的速度更快.. 有更多的 TDD 时间。也许是不和谐......但我觉得即使我不先去测试，TDD 也让我成为了一个更好的程序员。发现重构机会已成为第二天性...

如果我想到任何更多，我会更新..这是我在最后 2 分钟的反射(reflection)中想到的。