先整理？

第 21 章 先、后、再、从不

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

让我们就系统中的行为改变来谈谈 Tidy 的时间安排。先 Tidy，再改变行为？先改变行为，再整理？还是仅仅注意到混乱（从这个意义上说，未来的行为改变会比需要的更难）， ，然后再回来整理？或者，根本不整理？

从不

让我们从最后一条开始。一如既往，我们需要审视完全不做 Tidy 所涉及的利弊得失。什么时候我们应该说："是的，这是一个巨大的混乱，我们有意识地选择不做任何事情"？最好的理由是，我们再也不会改变代码的行为了。

我之所以这样说明条件，是因为很少有代码真的永远不需要改变其行为。不过，这种情况确实存在。对于真正的静态系统来说，"如果没坏，就不要修 "是很有道理的。

稍后

有些人认为 Tidy later纯粹是幻想，是独角兽，是诚实的政客。Tidy later "的神话地位被用作现在整理太多的理由，不管是之前还是之后。 我在这里要告诉你，你真的可以以后再整理。不过，你可能不喜欢这个前提条件。

是否有足够的时间完成工作？我不是问你是否有足够的时间，因为当然不够。我不是问你要做的事情是否多于你的时间，因为当然多。问问你自己，"如果我们有足够的时间，我们将如何工作？如果答案与你正在做的事情大相径庭，那么不，没有足够的时间来完成你的工作。

但是，我请你审视一下 "没有足够的时间完成工作 "这一假设。我曾与一些大型、成功、长寿、高利润的企业合作过，但他们在面对所有大型、成功、长寿、高利润的证据时，仍然认为没有足够的时间来完成工作。 这看起来很奇怪，就像一只质疑物理定律的鸟突然从天上掉下来一样。

如果你暂时相信有足够的时间完成工作，你会怎么做？你可能会列出一个待整理的混乱清单（我称之为 "乐趣清单"，因为我对 "乐趣 "的概念很奇怪）。然后，你可能会看一眼你的 "趣味清单"，然后想："我还有一个小时。我不想开始做一件大事。我为什么不先做第 4 项呢？然后你可能会这样做。

那是以后的 Tidy。它可以发生。试试看然后它就会发生。

Tidy 可以让系统行为的未来变化变得更容易（通过我们将在本书下一部分探讨的机制）。如果系统中有一个区域是一定会发生变化的（用词很重，"一定"），那么在这个大区域进行整理，如果能简化未来的变化，就能创造价值。

事后 Tidy（即不与立即改变行为挂钩）还能通过其他几种方式创造价值。其一，减少混乱税。您正在从旧的 API 迁移到新的 API。您已经更改了立即受到影响的调用站点，但稍后还要迁移 100 多个调用站点。全部迁移完毕后，就可以删除旧的 API。但在此之前，您必须在旧 API 中反映对新 API 所做的更改。

Tidy 所有这些调用网站并不是毫无意义的瞎折腾。一旦迁移了所有变更，某一类变更的成本就会降低。也许并没有降低成本的迫切需要，但去掉鞋里的小石子能让你走得更好。

稍后进行 Tidy 的另一个原因是将其作为一种学习工具。代码 "知道 "自己想要怎样的结构。如果你认真倾听，并将代码从当前结构移向它想要的结构，你一定会学到一些东西。Tidy 是一种很好的方法，可以让你意识到设计的详细结果。Tidy 整理能让你看到设计的本来面目。

最后，后期 Tidy 只是感觉良好。软件开发是一个人性化的过程。我们是有人类需求的人。有时，我实在没有精力去处理一个新功能，但我又想工作。从 "乐趣列表 "中挑出一个项目并加以整理，会给我带来快乐。不要低估快乐时程序员的能力。

之后

您需要改变行为。 ...