问在不改变外部行为的情况下，我能推进多远的重构？

EN

外部只是它真正的语言意义上的界面。以一头牛为例。只要你吃一些蔬菜，得到牛奶作为回报，你就不在乎它的内脏是如何工作的。现在如果上帝改变牛的内脏，使它的血液变成蓝色的颜色，只要入口和出口点(口和奶)不改变，就可以认为是重构。

对我来说，当测试和/或正式规范设置边界时，重构是最有效率的/最舒适的。

• 这些边界是足够严格的，让我感到安全，如果我偶尔跨越，它将很快被检测到，所以我将不必回退很多变化，以恢复。另一方面，这些可以提供足够的余地来改进代码，而不必担心更改无关的行为。
• 我特别喜欢的是，这种界限可以说是自适应的。我的意思是，1)我做了修改，并验证它是否符合规范/测试。然后，它被传递给QA或用户测试--注意，它仍然可能失败，因为在规范/测试中缺少了一些东西。好的，如果3a)测试通过了，我就完了，好吧。否则，如果3b)测试失败，那么我将回滚更改，5)添加测试或澄清规范，以便下次不会重复此错误。请注意，无论测试通过还是失败，我都会得到一些东西--代码/测试/规范中的任何一个都会得到改进--我的努力不会变成完全的浪费。

至于其他类型的界限--到目前为止，我运气不佳。

“用户可观察”是一个安全的赌注，如果一个人有遵守它的纪律--对我来说，这在分析现有的/创建新的测试时总是花费了很多的精力--也许是太费劲了。我不喜欢这种方法的另一件事是，盲目地遵循它可能会变得过于限制性。-这个更改是被禁止的，因为加载数据将需要3秒而不是2秒。-嗯，那么，向用户/ UX专家检查这是否相关如何？-不可能，禁止任何可观察行为的改变。安全？行!没问题!有效率吗？不怎么有意思。

我尝试过的另一个方法是保持代码逻辑(阅读时我理解它的方式)。除了最基本的(通常不是很有成效的)变化，这个总是一罐蠕虫.或者我应该说一罐虫子？我指的是回归错误。在使用意大利面条代码时，破坏一些重要的东西太容易了。

重构书非常强大，它的信息是，只有当您有单元测试覆盖率时，才能执行重构。

因此，您可以说，只要不破坏任何单元测试，就会进行重构。当您中断测试时，您将不再进行重构。

但是:这种简单的重构(比如更改类或成员的名称)如何？他们不通过测试吗？

是的，在每一种情况下，您都需要考虑这种中断是否重要。如果您的苏特是一个公共API/SDK，那么重命名确实是一个突破性的更改。如果不是的话，可能没问题。

但是，考虑到这一点，通常情况下，测试失败并不是因为您更改了您真正关心的行为，而是因为测试是脆弱试验。