重构是一种规范化的技术，用于重构现有代码库，在不改变其外部行为的情况下改变其内部结构。其核心是一系列保持行为的小型转换。每个转换（称为“重构”）作用不大，但一系列这样的转换可以产生重大的重构。由于每次重构都很小，因此出错的可能性较小。每次重构后，系统都能保持完全正常运行，从而降低了系统在重构过程中严重崩溃的可能性。

重构第一版和第二版之间变化的简要概述

我正在完成我的重构书籍的新版本。以下是有关我工作的详细信息和定期备忘录。

计算和格式化视频商店账单的简单示例开启了我 1999 年的重构书籍。如果使用现代 JavaScript 完成，则可以采用多种方向进行重构。我在这里探讨了四种方法：重构为顶级函数、使用调度程序重构为嵌套函数、使用类以及使用中间数据结构进行转换。

在本文中，我将逐步介绍真实代码库中的一组重构。这并非旨在展示完美，而是代表现实。

许多现代 Web 服务器代码与返回 JSON 数据的上游服务进行通信，对这些 JSON 数据进行少量处理，然后使用流行的单页应用程序框架将其发送到富客户端网页。与使用此类系统的人员交谈时，我听到很多关于他们需要做多少工作来操作这些 JSON 文档的抱怨。通过封装加载策略的组合，可以避免许多此类麻烦。

我们的大多数软件逻辑都是用我们的编程语言编写的，这些语言为我们提供了编写和演进此类逻辑的最佳环境。但在某些情况下，将该逻辑移动到我们的命令式代码可以解释的数据结构中是很有用的——我将其称为自适应模型。在这里，我将展示 JavaScript 中的一些产品选择逻辑，并展示如何将其重构为以 JSON 编码的简单生产规则系统。此 JSON 数据允许我们在使用不同编程语言的设备之间共享此选择逻辑，并在不更新这些设备上的代码的情况下更新此逻辑。

随着程序规模的增长，将其拆分为模块非常重要，这样您就不需要了解所有内容即可进行小的修改。这些模块通常可以由不同的团队提供并动态组合。在这篇重构文章中，我使用表示-领域-数据分层拆分了一个小程序。然后，我重构了这些模块之间的依赖关系，以引入服务定位器和依赖注入模式。这些适用于不同的语言，但看起来不同，因此我以 Java 和无类 JavaScript 风格展示了这些重构。

循环是处理集合的经典方法，但随着编程语言中对一流函数的更多采用，集合管道成为一种有吸引力的替代方法。在本文中，我将通过一系列小示例来研究将循环重构为集合管道。

当我编写处理外部服务的代码时，我发现将访问代码分离到单独的对象中很有价值。在这里，我将展示如何将一些凝结的代码重构为此分离的常见模式。

如果您要验证某些数据，通常不应使用异常来表示验证失败。在这里，我描述了如何将此类代码重构为使用通知模式。

一个简单的示例，说明了如何通过首先重构代码以使更改更容易来更轻松地进行更改。

重构已发展成为一种众所周知的技术，大多数软件开发团队至少声称定期进行重构。但是，许多团队并不了解重构可以使用的不同工作流程，因此错过了将重构有效地纳入其开发活动的机会。在本篇文章中，我将探讨各种不同的工作流程。我希望它能鼓励团队将重构更深入地集成到他们的工作中，从而形成设计更好的代码库，从而更快、更容易地添加新功能。

James Shore 的《敏捷开发的艺术》是我最喜欢的关于敏捷软件开发的单卷本。原因之一是它非常重视使其有效运作所必需的技术实践。James 和我讨论了重构对软件开发的作用、我们看到的设计变更的性质，以及如何将大变更分解成小块。

在过去十年左右的时间里，重构已成为一种广泛使用的技术，用于保持代码库的高内部质量。然而，大多数团队没有充分利用重构，因为他们不知道可以使用它的各种工作流程。在慕尼黑 OOP 2014 的这次主题演讲中，我将探讨其中一些工作流程：例如垃圾收集重构、理解重构和准备性重构。我还提醒人们，为什么重构的常见理由会破坏您最大的努力。（本次演讲还以信息平台的形式进行处理。）

在过去十年中，我们开发并完善了许多技术，允许数据库设计随着应用程序的发展而发展。这对敏捷方法论来说是一项非常重要的能力。这些技术依赖于将持续集成和自动化重构应用于数据库开发，以及 DBA 和应用程序开发人员之间的密切协作。这些技术适用于预生产和已发布的系统，适用于全新项目以及遗留系统。

Ruby Rogues 是一个关于 Ruby 世界编程的热门播客。他们邀请我回来讨论Ruby 版本的重构。我们谈到了重构的定义、为什么我们发现我们不经常使用调试器、可以做些什么来使这本书现代化、重构工具的作用、注释是否可以很好地使用、重构和重写之间的权衡、模块化和微服务，以及软件行业在过去二十年中是如何变化的。

2001 年 1 月，两个 Java 工具跨越了重构的卢比孔河。Java 中的重构现在有了强大的工具支持

Kent Beck 在 1990 年代后期开发极限编程时提出了他的四条简单设计规则。我这样表达它们。

到目前为止，重构工具已经出现在许多语言中。在 Smalltalk 的带领下，我们看到了几个用于 Java 的工具和几个用于 C# 的工具。一种语言的缺失引人注目，那就是 C++，尽管有呼吁。所有这一切都尽管第一个重构论文是由Bill Opdyke完成的，他的背景是 C++。

代码异味是一种表面迹象，通常对应于系统中更深层次的问题。这个词最初是由 Kent Beck 在帮助我编写重构一书时创造的。

每当将两个或三个值收集在一起时 - 将它们变成一个 $%#$%^ 对象。

——我（用声音说更有趣）

这是我最喜欢的重构书籍中的代码异味之一。当您不断看到相同的几个数据项一起传递时，您就会发现它。start 和 end 是想要成为范围的数据块的一个很好的例子。数据块通常是没有人想过要变成对象的原始值。

在我的重构一书中，我给出了重构的几个定义。

重构这个词是从哪里来的？

自从我开始谈论和撰写有关重构的文章以来，人们就一直问我如何将重构纳入更广泛的软件开发流程中。软件开发生命周期中是否应该有重构阶段？迭代中应该将多少比例分配给重构任务？我们应该如何确定谁应该负责重构工作？虽然有些地方会安排一些重构工作，但我更倾向于鼓励将重构作为一种机会主义活动，无论何时何地，只要代码需要清理，任何人都可以进行重构。

对影响所有使用者的接口进行更改需要两种思维模式：实现更改本身，然后更新所有使用位置。如果您尝试同时执行这两项操作，这可能会很困难，特别是当更改是在具有多个或外部客户端的已发布接口上进行时。

**并行变更**，也称为**扩展和收缩**，是一种以安全的方式实现接口向后不兼容更改的模式，它将更改分为三个不同的阶段：扩展、迁移和收缩。

您可以使用重构来构建平台吗？

最近，Robert Cringely 的一篇文章在重构社区引起了一些轰动，因为他批评了重构。Phlip 在重构邮件列表上以一种异常克制的语气总结了回应：“……他听起来像是一个‘怀疑论者’，他会写那些他根本不打算读的书的评论。”

“重构”一词曾经只有少数人知道，现在却在计算机行业中被广泛使用。我乐于认为我对此负有一定责任，并希望它能改善一些程序员的生活和一些企业的利润。（重要的一点是，我不是重构之父或发明者，只是一个记录者。）

看起来 UIUC 的那些狡猾的家伙们正准备重构 Fortran。Brian Foote 以其无与伦比的风格撰写了关于该项目的文章。（他是软件领域最有趣的作家之一，但让他写任何东西通常就像戴着刚宰杀的羊排项链，试图从一只活的剑齿虎嘴里拔牙。）（是的，我知道这是旧闻了，但我在他的博客上看到了其他东西，然后发现了这个。）

当人们想到代码审查时，他们通常会想到开发团队工作流程中的一个明确步骤。如今，在拉取请求上执行的集成前审查是最常见的代码审查机制，以至于许多人愚蠢地认为不使用拉取请求就等于放弃了所有进行代码审查的机会。这种狭隘的代码审查观点不仅忽略了许多明确的审查机制，更重要的是，它忽略了可能最强大的代码审查技术——由整个团队进行的持续改进。

自测试代码是我在重构一书中用来指代编写全面的自动化测试以及功能软件的做法。如果做得好的话，这将允许您调用一个执行测试的命令——并且您有信心这些测试将揭露隐藏在代码中的任何错误。

在听取我们的开发团队谈论他们的工作时，一个共同的主题是他们不喜欢静态的东西。通常，我们会看到常见的服务或组件保存在带有静态初始化器的静态变量中。静态变量（在大多数语言中）的一个大问题是，您不能使用多态性用一个实现替换另一个实现。这给我们带来了很多麻烦，因为我们非常热衷于测试——为了做好测试，能够用服务桩替换服务非常重要。