先整理？

第 19 章 节奏 节奏

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

让我们回到开头。Tidy 是为了让未来系统行为的改变更容易。你让未来的行为变化变得更容易，因为你值得这么做（如果有人反对，我们稍后再谈经济学）。我们在谈论什么？短短的一瞬间，然后又回到了辛苦的工作中？一小时又一小时的幸福整理？

管理整理的艺术之一就是管理整理的节奏。在上一章中，我们看到了这样一幅画面（图 19-1），鼓励小批量整理。

图 19-1. 结构更改分批或单独进行

在行为改变之后，结构的连续改变需要多少时间？

软件设计是分形的，因此可以是任何时间尺度。不过，在本书中，我们只讨论软件设计的一种规模：具有个人影响力的软件设计。为此，我们讨论的是几分钟，最多一小时。在做出行为改变之前，一次 Tidy 的时间超过一小时，很可能意味着你已经失去了实现理想行为改变所需的最小结构变化集。

不过，另一种可能是，代码已经乱成一团，在进行行为改变之前，你可以利索地整理几个小时。如果这是真的，也不会持续太久。软件设计具有强烈的 "铺路 "倾向。

如果你还没听说过这个故事，事情是这样的：一所大学建了很多楼，规划人员想在楼与楼之间铺设步行道。然而，他们并没有仔细推敲，而是在建筑物之间种满了草。

几个月后，学生们的脚在草地上磨出了一条条小路。规划人员在这些被磨平的地方铺上了路面。

行为变化往往会在代码中集群。根据帕累托理论，80% 的更改会发生在 20% 的文件中。先进行 Tidy 整理的好处之一就是整理也会聚集在一起。而且它们恰恰会聚集在那些最吸引行为变化的地方。

即使一开始你整理了很多，很快你就会发现自己想要在已经整理好的代码中进行行为修改。继续一段时间后，大多数更改都会发生在已经整洁的代码区域。 最终，遇到不整洁的代码将成为例外，尽管系统中的大多数代码都没有被触动过。

因此，我很自信地说，Tidy 是一种几分钟到一小时的活动。是的，有时会持续更长时间，但不会太久。