代码“工作”意味着什么？

极限编程联合创始人 Ron Jeffries 曾著名地写道：“诀窍是永远不要让代码不工作。”

Jeffries 的引言指出，软件工程是一项非常复杂的活动，充满了不确定性。软件工程还处理不完整性的问题——一开始，您似乎永远无法获得制定最佳方法所需的所有信息。项目后期总会有一个时候，您会了解到一些东西，表明您最初理解中的一些事情是不正确的。此外，即使您积累了足够有用的信息来正确定位自己，这些信息也往往包含歧义——沟通很少，即使有，也是清晰的。歧义似乎在口头和书面交流中都很普遍。

由于这些限制，在开发软件时，唯一安全的进行方式是依赖于工作的代码。运行中的、工作的代码是最终的预言。它会告诉您您是否在做正确的事情并朝着正确的方向前进。

您如何知道代码是否在工作？

如果代码没有运行，就不可能知道您的代码是否按设计工作。代码编译时没有错误，并且始终运行而没有异常，并不意味着代码正在工作。它可能在执行所有这些活动，但没有任何用处。因此，工作代码的定义是，它在没有任何问题的情况下运行，同时执行您期望它执行的操作。

找出您的代码是否按预期工作的唯一方法是关注可观察的行为。仅仅阅读和分析源代码是不够有说服力的；您需要看到代码执行才能判断其执行是否符合您的期望。

有两种方法可以衡量可观察的行为

1. 观察运行代码的计算机执行某些操作
2. 测试运行代码的计算值

第一种可观察的行为类型（观察正在执行的某些操作）不是确保您的代码按预期工作的最佳方法。例如，您可能会观察到您的代码执行了一个操作，例如发送电子邮件。但这本身不足以确认代码按预期工作。如果代码正在发送的电子邮件包含不正确的信息怎么办？

确认您的代码是否按预期工作的唯一方法是观察计算值。而这个过程（即，观察计算值以查看它们是否与预期值匹配）正是测试驱动开发 (TDD) 的优势所在。

如果代码不工作，编写软件感觉如何？

在我发现 TDD 之前，我花费了很长时间编写代码，而没有担心代码是否在工作。每隔一段时间，当我感觉自己在编码方面达到了一个里程碑时，我就会运行我正在开发的应用程序。我会以虚构用户的身份登录，并手动触发一些操作，以查看程序是否执行了我告诉它执行的操作。

这种方法类似于仅通过测量冰山的一角来测量冰山——冰山在水面以上可见的部分。虽然我的手动测试为应用程序提供了健康的证明，但自然而然地，一旦它投入生产，各种错误和缺陷开始出现（由冰山的“水下部分”引起）。

回顾过去，很明显，在不始终使其工作的情况下编写代码类似于放风筝。在强风中放风筝是令人兴奋的，甚至是令人振奋的。但是风筝几乎从不接触地面，并且在强风中控制其方向非常具有挑战性。而且，几乎不可能将风筝降落在您瞄准的确切位置。

使用 TDD 编写软件感觉如何？

TDD 基于代码行为方式应独立于代码结构方式的理念。您的目标是期望的行为。当您编写代码时，期望的行为不存在（这就是为什么它被称为“期望的”）。您通过首先编写一个描述它的测试来实现期望的行为。然后您运行该测试，它会失败，因为期望的行为尚未实现。失败会提示您修复它，这迫使您再次运行代码。如果您对代码所做的更改满足了测试中描述的期望，那么您可以得出结论，代码按您的期望工作。

如果您对代码所做的更改不满足测试中描述的期望，则代码不工作，您需要对代码进行更多更改，直到它按预期工作。

当一致地完成此过程时，感觉就像骑着一匹飞奔的马。每隔一段时间，飞奔的马会接触地面，这相当于 TDD 中所有测试通过的时刻。当马“在飞行中”时，它会直线冲锋。马在前进，但无法改变它的路线。只有当马接触地面时，骑马者才有机会改变他们前进的方向。

同样，在编写代码时，您也“在飞行中”。当您编码时，您无法验证您是否朝着正确的方向前进。只有当您停止编码、保存更改并运行代码时，您才能观察到您的代码是否正在执行您期望它执行的操作。每次运行代码时，您都在接触地面。

TDD 是一种纪律，它引导您尽可能频繁地执行此现实检查。这最大限度地降低了您交付不正确代码的风险。

您是应用程序代码的第一个客户

由于您正在编写一个自动化您的期望的测试，因此您是应用程序代码的第一个客户。实际上，最好说您的测试是您的代码的第一个客户。该测试可以被视为一位顾客走进餐厅，因为饥饿而点了一份餐。当顾客点餐时，她心中有一个特定的餐点。厨房工作人员的工作是将顾客的愿望变成现实。

如果服务员送来餐点，并且在品尝后，顾客不同意餐点符合她的期望，她会将其退回厨房。工作人员会修改餐点，直到顾客满意为止。但是，除非厨房工作人员从顾客那里收集反馈，否则他们永远不会知道餐点是否好吃。

以类似的方式，了解您正在编写的代码是否满足期望的唯一方法是从测试中收集反馈。

结论

了解您对代码所做的更改是否正在朝着正确的方向推进您的应用程序的唯一方法是使代码工作。仅仅审查代码，阅读代码的行为，永远不足以得出代码是正确的可靠结论。

大多数开发人员更喜欢长时间编写代码。但是花费数小时编写代码意味着您浪费了数小时而没有使代码工作（回想一下 Ron Jeffries 的建议“诀窍是永远不要让代码不工作”）。如果您沉迷于长时间的代码编写会话，您就是在让代码不工作。

TDD 通过将您的注意力集中在可观察的行为上来帮助控制这一点。在 TDD 中，您定义期望值并继续询问您的代码以查看它是否计算出这些期望值。为了确认或驳斥这些期望，您必须使代码工作。您执行这些“现实检查”的频率越高，您的努力朝着正确方向发展的可能性就越高。

从稳定、就绪状态（准备就绪）到下一个稳定、就绪状态（再次准备就绪）的过渡应尽可能短。TDD 致力于帮助您始终以就绪到就绪的方式旅行。