超越TDD：打破规则

封面图片由Mark Duffel拍摄，来自Unsplash。

规则就是用来打破的，对吧？TDD 是一套严格的规则，它定义了软件构建流程。但经验丰富的实践者已经超越了这些规则，追求完全不同的目标。

Ron Jeffries 在推特上发表了一系列推文，讨论了他所谓的纯粹 TDD（PTDD ）的概念，这种方法有时也被称为严格 TDD。他谈到自己并不喜欢这种最纯粹的方法。

但打破规则是任何熟练过程中可以接受的一部分。

德雷福斯技能习得模型指出，熟练的专家能够凭直觉感知规则，并在无需意识思考的情况下做出决策。这意味着他们不仅知道如何运用规则，也知道何时应该忽略规则。

然后是能力的四个阶段模型，它从无意识的无能（你不知道你不知道什么）开始，经过有意识的无能和有意识的胜任，最终达到无意识的胜任，这再次表明专家们能够凭直觉意识到自己在做什么，而无需思考。

什么是直觉？

从某种意义上说，“直觉”意味着你不再需要规则。相反，你理解规则背后的核心价值，并朝着这些价值而非规则本身努力。

因为你了解规则背后的价值，所以你能理解其中涉及的权衡取舍。你能开始意识到规则何时可能不适用。你能开始回答“何时应该使用TDD，何时不应该使用TDD？”这个问题。

与此形成鲜明对比的是TDD的拥趸们。他们中的许多人会想一直使用TDD，因为一旦掌握了TDD，它就变得无比强大。（我并非讽刺，它确实很棒。）我们用一句谚语来形容这种态度：“如果你只有一把锤子，那么所有东西看起来都像钉子。”

假设你同意我的观点，即可以打破规则，那么我们应该在什么情况下这样做呢？

以下是我能想到的一些例子。

当你的团队不熟悉或不遵循测试驱动开发（TDD）时，你只能接受这个事实，并努力说服他们，但这可能不会很快奏效。
当风险较低时，情况就变得很有意思了。因为经验越丰富，所有功能和对象看起来都越来越相似。这意味着开发风险会降低，因为一切都变得熟悉了。然而，如果你疲惫不堪或独自工作，出错的风险就会增加。这其中有很多需要考虑的因素。懂得如何权衡这些因素需要相当丰富的经验。
当成本效益比对你不利时，例如 React 组件，它们通常难以测试。但你可以做出设计决策，将所有业务逻辑从组件中移到 Redux reducer 中。这样做可以大大减少测试组件的必要性，因为它们相对于代码库的大小已经降低。你可以转而测试 Redux 函数。它们只是普通的函数，因此应该更容易测试。
当你进行实验时，很多应用并不需要立即达到高质量标准，而是需要一个探索期，在此期间功能可以灵活调整。在这种情况下，测试驱动开发（TDD）反而会拖慢你的进度，而不是加快速度。

教育界普遍认为专家不擅长教学。如果你认为凭直觉行事就意味着忽略规则，那么这种观点自然而然地就符合德雷福斯模型。

这并不意味着所有专家都是糟糕的老师。事实上，他们完全可以成为优秀的老师。他们只需要付出额外的努力，否则很可能就会很糟糕。

如果你要和新手一起工作（这在当今行业中很常见，因为团队的技能水平参差不齐），那么你必须能够切换回“纯粹的TDD”模式。

所以现在我们可以看到，在某些情况下，测试驱动开发（TDD）至关重要，不容忽视。以下是我能想到的两种情况：

当你教TDD新手时，为了帮助他们学习，你必须向他们展示规则，而不是你的捷径！
当你和从未合作过的人结对编程时，即使对方是专家，他们也会有一套与你不同的“作弊”和权衡取舍。因此，你应该坚持严格的测试驱动开发（TDD）。一旦你们中任何一方考虑使用“作弊”手段，就应该停下来讨论。如果无法达成一致，那就使用TDD。