TDD不分昼夜

几周前，我举办了“ TDD时钟”会议。 格式很简单：遵循严格的红绿重构TDD循环成对工作，我们完成了一个简单的kata。 但是，我们添加了一个关键的约束条件：导航器将启动一个五分钟的计时器。 五分钟后：

• 如果代码编译并且测试为绿色，请提交 ！
• 否则，请还原 ！

无论哪种方式，当计时器关闭时，两对都将互换角色。 如果驱动程序比五分钟快完成红绿重构周期，他们可以提前提交，但角色仍会交换。

我们在本次会议上选择的kata是保龄球kata 。 这是一个很好的简单问题，我希望我们可以在两个45分钟的会议中的每一个中取得不错的成绩。

困难时期

五分钟的时间限制听起来像是恶魔般的，不是吗？ 你怎么可能在五分钟之内完成任何事情？ 好吧，如果您解决的问题足够小，就可以。 本练习旨在迫使您以较小的功能增量进行思考。

五分钟之内输入的内容少得令人惊讶。 但是，如果您认为打字速度是障碍，那么您就不会对解决问题的正确方法进行足够的思考。 保龄球服中有一个要点，您从第一次处理单帧和简单的比分到备用（或罢工）。 这总是需要一个跳跃，因为以前的内容不适合现在的需求。 在五分钟的期限内工作时，如何逐步解决这一问题是挑战的一部分。 我们小组中的一个有想法，但知道很难在五分钟内完成。 他打字像恶魔一样试图强行解决：他仍然没时间了。 键入速度不是问题（无论看起来多少）。 您需要一种更好的方法，您需要考虑更多而不是更多输入。

品行端正

经过几个周期后，我们发现几乎没有人再按时完成5分钟了。 令人着迷的是，每个人都很快意识到，花5分钟的时间讨论比在更改中途迷路并最终恢复状态要好。 同样，当您发现要在此周期中进行的更改太难或太耗时时，最好先丢弃所拥有的内容，交换对并进行重构，然后再尝试编写失败的测试。

这些都是在日常生活中有用的良好行为，在这些生活中，不断追逐老鼠洞太容易了。 学会以独立的小幅度工作，使自己成为工作中的潜意识部分，将使您成为一名更好的程序员。

错误的学校

我们发现的最大麻烦是，保龄球服不完全适合我认为是“正常”的外在TDD（ 伦敦学校TDD ）。 大多数时候，我将TDD用作设计工具，以帮助我发现正确的角色和职责。 但是，使用保龄球套件，最优雅的解决方案是Bob叔叔驾驶的那个解决方案，它只是简单的类型，没有对象建模。

这对于像打保龄球比赛这样的算法非常有用，它具有最终的真理，并且不会改变。 但是在通常的日常环境中，我们正在设计灵活性和不断变化的产品。 这是一个良好的领域对象模型，可以使事情更容易推理，更容易更改。 这通常是外部TDD可以为您提供帮助的地方。

小组中的几个人决定实施OO版本的保龄球鞋。 这并不容易，因为它不自然地适合逐步建立一个好的对象模型。 但是，只要有足够的固执，就可以做到。 这就引发了关于是否可以使用TDD算法以及TDD是否更适合于以对象模型为期望结果的问题的有趣讨论。

很明显，你可以逐步TDD的算法，不管它是值得的，我不那么肯定。 通常，由于要遵循一组规则 ，因此您正在实现算法。 一次实施一个规则可能有助于保持专注，但是您始终需要整体上了解算法。

使用TDD来驱动OO设计是不同的。 可能存在许多相似而正确的对象模型，它们仅因细微差别而变化。 TDD可帮助您指导设计并在细微差别之间进行选择。 尽管您仍然需要考虑整个系统的设计，但从外而内进行的TDD仍在故意限制您在任何给定阶段需要担心的事情：一次专注于一对交互。 这就是TDD最强的地方：提供一个以可管理的小增量完成大型任务的框架。

即使我们选择的问题不是很理想，总的来说，我发现TDD与时钟会议是一种很好的方法，可以实践使您的提交保持较小规模，不断进行重构，逐步朝着更好的设计努力的原则。

你如何移动一座山？ 只需一次移动一茶匙。

翻译自: https://www.javacodegeeks.com/2015/02/tdd-clock.html