测试->代码->重构，何时开始重构？

Question

TDD圈是：

"Write failing Test" -> "Write Code to fit a Test" -> "Refactor"

在“编码”步骤中，假设我们编写的代码尽可能简单，只是为了修复失败的测试。在真正需要之前，我们不应该编写复杂的代码。

下一步是重构。我们应该重构一下写好的代码吗？我认为没有真正的意义，因为只要测试通过，我们就应该对代码感到满意。

可能重构活动应该是由某些事情强制进行的，比如代码编写是通过失败的测试来进行的。以下是一些可能的因素：

下一个要编写的测试需要对系统(refactoring)

• Performance进行一些更改，这是很糟糕的。我们需要在不破坏functionality

• Code审查的情况下对其进行改进，这表明编写的代码很难理解。

您认为启动重构的其他原因是什么？

此外，这一计划是否正确：

"Write failing Test" -> "Code" -> "Refactor" -> "Write failing Test"

或者可能是应该被视为

"Write failing Test" -> "Code/Refactor" -> "Write failing Test"
+
"External factor (like bad performance)" -> "Refactor".

Answer 1

TDD是一个很好的工具，可以让你继续工作。问题在于：

“写入失败测试”->代码/重构“->”写入失败测试

你提议，它很容易变成：

“写失败测试”->重构“->”代码“->”写入失败测试

或者那时

“写失败测试”->重构“->”代码“->”写入失败测试

这就是你想要避免的。通过在实现开始时进行重构，您将沉溺于推测开发，而不是实现编码会话的目标。这是很容易避免切线和建设的东西，你不一定需要。如果功能能够正常工作并通过测试，那么决定什么时候停止重构要容易得多。你可以随时停下来，因为你的测试已经通过了。

此外，当您的测试不是绿色时，您不希望重构。

另外还有几篇小文章：

，

1. ，我认为大多数文献都有一个稍微不同的定义:重构是什么。它不是“对系统的一些改变”或性能增强，而是特定的更改，而不是改变行为，而是改进设计。如果您接受该定义，那么性能改进实际上并不合格:它们是正常的开发任务，需要自己的验收测试。我通常试着把这些描述成面向终端用户的故事，这样做的好处是显而易见的。有意义吗？
2. ，我认为您是对的，TDD实践没有专门解决代码评审过程中暴露的设计问题。(有关此问题的其他解决方案，请参见反射和配对编程。)这些往往是更大的，跨层的问题，建立为“代码债务”，并需要一些时间来清理它定期。这可能是一个单独的项目，但我个人，总是喜欢这样做，作为另一个“真实”的故事的一部分。上一次我这么做的时候，我们发现我们有一个问题，但最后我们等了几个星期，直到我们有了一个相关的故事来研究它。我们遵循TDD的做法，首先实现新特性--尽管我们知道这是错误的。但是，我们真正理解了发生了什么，为什么会很混乱，然后花在重构阶段的时间比平时长。工作得很好。

Answer 2

您可以在通过测试的同时编写一些非常难看的代码；重构现在并不是因为它不能工作，但是它不是很容易维护。这才是重点。

在编写了适合几个测试的代码之后，您可以开始从更大的角度来看--这些代码之间是否存在重叠，您可以从中推断出一些重复吗？

Answer 3

嗯..。我通常认为这些“外部”重构与TDD周期本身是分开的。在使用TDD完成特性XYZ之后，应该有一组健康的测试，以防止通过重构引入bug(假设代码覆盖率是最佳的，等等)。无论如何，性能瓶颈和难以理解的代码通常都会出现在事实之后，因此，我认为在这一点上进行重构是理想的。您可以提高性能，使代码更容易理解，并在使用测试时做任何其他需要做的事情，以确保您没有在系统中引入bug。

因此，为了回答您的问题，我不认为外部重构符合TDD模式，尽管在开发代码时，标识符(如果您愿意的话，代码闻起来很明显)绝对是要跟踪的。