对《Tidy First? A Personal Exercise in Empirical Software Design》一书的感想
I’m sorry, but I can’t retrieve the article from the link you provided. If you paste the text you’d like translated here, I’ll be happy to translate it into Simplified Chinese while preserving the formatting and markdown.
引言
首先，很高兴看到我们领域中一位知名人物和作者写了一本关于并非每个人每天都在追求的主题——代码质量的新书。这本书出版于其他里程碑作品之后多年，例如 Fowler 的 Refactoring（第一版，1999）和 Robert Martin 的 Clean Code（2008）。因此，尽管该书并未开辟全新的领域，但它仍然激励实践者像我们（在 CQSE）一样，用放大镜审视 小范围的代码质量，正如我们所做的那样。
我将本文分为两部分，基于我在书中发现的两个最有趣的维度。
- Part I – 与我们（在 CQSE）每日赞扬的内容直接相关的关键点：让开发者生活更轻松的小动作。
- Part II – Kent 提供的时间和经济视角。标题 Tidy First? 中的 “First?” 部分暗示了其涵义——整理代码的最佳时机是什么？先整理？在进行行为改变的修改之前？之后？稍后？还是永不？
第 I 部分 – 基础：让开发者生活更轻松的小改动
什么是 “tidying”？
如果你在想 “tidying” 是否与 “refactoring” 不同，让我们来澄清一下。书中将 tidying 定义为一种 小规模、细微的重构。而重构被定义为 不改变行为 的结构性改动，tidying 则是：
“那种可爱、模糊、微小的重构，没人会讨厌的。”
Kent 还指出：
“当人们开始把 ‘重构’ 用来指代功能开发中的长时间停顿时，‘重构’ 受到了致命的伤害。他们甚至把 ‘不改变行为’ 的条款删掉了，于是重构很容易破坏系统。”
的确，我也听到过人们用各种方式谈论重构，正呼应了 Kent 的观察。所以，无论这个词能否流行下来，我们现在有了另一个术语——Tidying。
书中列出的 tidying
Kent 并未深入探讨它们；有些条目只占半页，这也没关系，因为它们并不新鲜。
- Guard Clauses（防卫子句）
- Dead Code（死代码）
- Move Declaration and Initialization Together（把声明与初始化放在一起）
- Explaining Variables（解释变量）
- Explaining Constants（解释常量）
- Explicit Parameters（显式参数）
- Chunk Statements（块状语句）
- Extract Helper（抽取帮助函数）
- One Pile（单一堆）
- Explaining Comments（解释注释）
- Delete Redundant Comments（删除冗余注释）
虽然这些并不新颖，但 Kent 为它们专门设立章节是有充分理由的：
- 使本书 自成一体。
- 具体展示 作者所说的 “可爱、模糊、微小的重构” 是什么，而不是仅仅引用 Fowler 或 Martin 的工作。
双子概念：耦合‑与‑内聚
耦合‑与‑内聚是关键
Kent 多次提到 Ed Yourdon 和 Larry Constantine 的研究。Yourdon 与 Constantine 在 1970 年代奠定了软件设计中耦合与内聚的概念基础。
内聚 与 耦合 实际上是大脑处理复杂系统的方式。
内聚顺序（以及是否要解耦）
- 目标是避免在代码的多个分散位置进行修改。
- 将需要修改的代码元素重新排序，使它们相邻（不仅在同一源文件中，也跨文件、跨文件夹）。
为什么不直接消除导致这些分散修改的耦合呢？
如果你知道怎么做，而且能够做到，就去做吧！
但请注意成本关系：
cost(decoupling) + cost(change) // Constantine’s Equivalence
// cost(software) ≈ cost(change)cost(change) 遵循 幂律分布：少数极高成本的改动占据了总成本的大部分。换句话说：
“最昂贵的行为改动，加在一起，远远超过所有最便宜的行为改动的总和。”
形式化表达：
cost(change) ≈ cost(big changes)是什么让这些大改动如此昂贵？通常，它们 不是孤立在单一内聚元素中；它们会在许多高度耦合的地方传播。这把我们拉回核心洞见：
高耦合 → 高改动成本。
cost(software) ≈ cost(change) ≈ cost(big changes) ≈ coupling或者简化为：
cost(software) ≈ coupling然而，解耦本身也有成本（当然，任何软件中总会存在一定程度的耦合）。权衡是什么？这归结为本书第二个维度——何时进行 tidying（或解耦）是合适的，或者是否根本不需要进行。
简而言之，这取决于：
- 现在支付耦合的代价是否值得，因为很快可能会从中获利；
- 还是现在支付 解耦 的代价更划算，以便在以后收获解耦带来的好处（即使这些好处会稍后才出现）。
我们将在第 II 部分进一步展开这些内容。