本书分为三部分：第1部分介绍代码的整理（微型重构）；第二部分讨论如何将整理工作整合到开发工作流程中；第三部分深入探讨什么是软件设计、软件设计如何驱动软件开发和运营成本以及软件开发和运营成本又如何驱动软件设计、投资软件结构与不投资软件结构之间的权衡是什么、我们可以利用哪些经济和人文原则来决定是否以及如何改变软件结构。

杂乱无章的代码令人烦恼。要想整理代码，使其更具可读性，就需要将代码分成易于管理的部分。在这本实用指南中，极限编程的创始人、软件模式先驱Kent Beck对代码整理的时机和位置给出了建议，可以在改善代码的同时保持系统的整体结构。本书不会试图让你一次性掌握所有的整理方法，而是带你尝试一些对你的问题有意义的例子。如果你有一个包含多行代码的大函数，你将学习如何合理地将其分割成小块。同时，你还将学习软件设计背后的理论：耦合、内聚、现金流贴现和期权。本书将帮助你：·理解软件设计的基本理论和驱动因素。·探索系统行为变化和系统结构变化之间的区别。·通过优先整理或事后整理来改善编程体验。·学习如何安全小步地进行大改动。·将软件设计视为人际关系的一种实践。

什么是整理优先

我必须修改这段代码，但它很乱。我应该先做什么？

也许我应该在修改之前整理一下代码。是整理一部分，还是根本不整理呢？

这些都是你可能会问自己的问题，如果有简单的答案，我就没有必要写一本书来解决这些问题了。

本书内容包括：
? 在修改代码之前，何时整理这些杂乱无章的代码。
? 如何安全高效地整理杂乱无章的代码。
? 如何停止整理杂乱无章的代码。
? 整理为什么有效。

软件设计是一种人际关系实践。在本书中，我们从程序员与自己的关系开始谈起。为什么我们不花时间关心自己？为什么不花时间让工作更轻松？为什么我们会陷入整理代码的兔子洞译注，而忽视了能帮助用户的工作呢？

本书是为了让极客们在这个世界感到安全。良好的软件设计是提高软件开发效率的强大工具，但如果使用不当，它就会变成另一个压迫工具，拖累软件开发的效率。

本书以软件设计为主题。我希望使软件设计变得易于理解并得到重视，让大家以有益于日常工作的方式来理解和实践软件设计。

假设有一个包含很多行代码的长函数。在修改它之前，你需要阅读代码，了解其中的内容。在这个过程中，你会发现可以从逻辑上将代码分割成小块。提取这些代码块的过程就是整理代码的过程。其他类型的整理工作包括使用卫述句（guard clause）、使用解释型注释和使用辅助函数。

本书实践了它提出的理念将这些整理技巧分成小块并指导你何时何地可以使用哪些技巧。所以，与其试图一次性掌握全部整理技巧，不如先尝试一些能解决你的问题的技巧。本书还讲述了软件设计背后的理论：耦合、内聚、现金流贴现和期权。

目标读者

本书面向程序员、资深开发人员、实践型软件架构师和技术经理。本书与编程语言无关，所有开发人员都可以阅读并将书中的概念应用到自己的项目中。

你将学到什么

读完本书，你将理解：
? 系统行为变化与系统结构变化之间的根本区别。
? 当单个程序员修改代码时，结构和行为交替变化的魔力。
? 软件设计的工作原理和驱动因素。

你还能够：
? 通过优先整理（有时是事后整理）来改善编程体验。
? 安全小步地进行大改动。
? 将设计作为一种具有不同激励机制的人类活动。

本书内容

本书分为三部分。
第一部分
整理就像一个小巧的迷你重构。每一个短章涵盖一个整理技巧。只要看到这样的代码，就将它改成那样的代码，然后将其发布到生产环境。

第二部分
该部分介绍整理过程的管理。整理的理念之一是它永远不应该成为一件大事。它不需要打报告、跟踪、计划和安排时间。之所以优先进行整理，是因为你需要改动代码，但代码很混乱，改起来很困难。即使作为日常工作的一部分，这仍然是一个需要用心改进的过程。

第三部分
在这一部分，我终于可以放飞自我，深入探讨让我兴奋的主题了。当我说软件设计是一种人际关系实践时，我在说什么？这些人是谁？如何通过更好的软件设计来更好地满足他们的需求？为什么软件成本如此之高？我们可以采取什么措施来解决这个问题，耦合？内聚？幂律？

我的目标是让读者从早上开始阅读，然后在当天下午就能进行更好的软件设计。之后每天都能稍微提升一点设计水平。很快，软件设计将不再成为软件交付价值链中的薄弱环节。

为什么是经验性软件设计

在软件设计中，设计成什么样似乎是争论最激烈的问题：
? 服务应该有多大？
? 代码库应该有多大？
? 是事件还是显式服务调用？
? 是对象、函数还是命令式代码？

这些争论掩盖了软件设计人员之间更根本的分歧：什么时候设计？下面是这一分歧的两个极端：

投机性设计
我们知道接下来要做什么，所以今天就可以开始设计，并且成本更低。此外，一旦软件投入生产，将再也没有机会进行设计，所以我们今天就设计出全部内容吧。

反应式设计
功能是所有人都关心的问题，所以我们今天要尽可能少地进行设计，这样才能回到功能开发上来。只有当功能几乎无法添加时，我们才会勉为其难地改进设计，而且只会改进到刚刚能够继续开发功能的程度。

我对什么时候这个问题的回答是中间的某个时刻。当发现某类功能很难添加时，我们就会进行设计，直到压力得到缓解。我们从刚刚好的设计开始，以启动反馈循环：

功能
用户想要什么？

设计
如何为程序员提供最好的支持，以实现这些功能？

经验性软件设计的时机取决于具体的情况。要为设计预留一些时间。回答什么时候这个问题需要设计嗅觉、谈判能力和鉴别能力。需要嗅觉和鉴别能力是缺点吗？当然，但这是一种无法避免的缺点。投机性设计和反应式设计同样需要鉴别能力，但软件设计师没有多少工具可用。

我喜欢用经验性这个词来描述这种风格，因为它似乎澄清了我对投机性设计和反应式设计时机的区分。它的基础、关注点和验证方式是观察或经验，而不是理论或纯逻辑。这听上去没有问题。

Kent Beck是程序员、极限编程（Extreme Programming）创始人、软件模式先驱、JUnit合著者、测试驱动开发（Test-Driven Development,TDD）的重新发现者,以及3X（Explore/Expand/Extract，探索/扩展/提取）的观察者。Beck还是《敏捷宣言》按字母顺序排列的第一位签署人。他现在是Mechanical Orchard公司的首席科学家，教授帮助极客在世界上感到安全的技能。

序1
前言3
引言11
第一部分 整理
第1章 卫述句15
第2章 无用代码17
第3章 对称归一19
第4章 新接口，旧实现21
第5章 阅读顺序23
第6章 内聚顺序25
第7章 将声明和初始化放在一起27
第8章 解释型变量29
第9章 解释型常量31
第10章 显式化参数33
第11章 语句分块35
第12章 提取辅助函数37
第13章 积沙成堆39
第14章 解释型注释41
第15章 删除多余注释43
第二部分 管理
第16章 单独整理47
第17章 整理链51
第18章 批大小55
第19章 节奏59
第20章 解开乱麻61
第21章 优先，事后，以后，从不63
第三部分 理论
第22章 将元素关联起来创造收益69
第23章 结构和行为73
第24章 经济学：时间价值和期权性77
第25章 现在的一块钱大于未来的一块钱79
第26章 期权81
第27章 期权与现金流85
第28章 可逆的结构修改87
第29章 耦合89
第30章 康斯坦丁等价定律93
第31章 耦合与解耦97
第32章 内聚101
第33章 结论103

附录 阅读清单和参考文献105