大部分有关软件工程的书讨论的都是如何进行正向的软件项目开发，而少有提及如何处理有价值的遗留系统。然而在现实中，许多人在工作中面临的都是处理现有的代码库。
　　本书作者从自身参与欧洲工业研究项目FAMOOS的实践出发，总结了对面向对象的软件系统进行再工程时的最佳实践，并把它们精炼成模式。每个模式都从分析问题入手，然后给出权衡考虑了各方面影响因素后的解决方案，并解释其合理性或给出例子。本书是一本实践性很强的面向对象软件再工程指南。

无

一个童话故事
　　从前有一位优秀的软件工程师，他的客户都确切地知道自己的需求。这位优秀的软件工程师努力地工作，并设计了一个完美的系统，这个系统能够解决客户当前和以后的所有问题。当这个完美的系统经过设计、实现和最终部署之后，客户都感到非常高兴。系统的维护工程师无需做任何工作就能让这个完美的系统很好地运行，客户和系统维护工程师从此以后一直快乐地生活着。
　　为什么现实生活不能像这个童话故事一样呢？
　　难道是因为没有优秀的工程师吗？难道是客户没有真正了解他们自己的需求吗？或者是因为根本就不存在完美的系统呢？
　　也许上面所说的都有一点道理，但真正的原因恐怕在于多年以前由 Manny Lehman和Les Belady所总结的软件发展的基本规律。这些基本规律中最重要的两点是：
　　持续变化规律。在一个真实的应用环境中使用的程序，一定是不断被改变的，否则那个应用环境本身就会变得越来越没有用处。
　　增长的复杂性规律。当一个程序不断地发展，它会变得越来越复杂，并需要消耗额外的资源来保持并简化它自己的结构。
　　换句话说，如果我们认为自己能够了解所有的需求，并能构建完美的系统，那么就是在自己骗自己。我们所能够做到的最好情况是构建一个有用的系统，并且能够运行足够长的时间，直到需要它做新的工作为止。

本书内容
　　本书的起因在于充分认识到这样一个事实—软件工程最有意义和最具挑战性的一面不是建立一个新的软件系统，而是重构既有系统。
　　从1996年11月到1999年12月，我们参加了一个名为FAMOOS的欧洲工业研究项目（ESPRIT 项目 21975—掌握面向对象软件发展的基于框架的方法研究，Framework-based Approach for Mastering Object-Oriented Software Evolution）。合作伙伴包括Nokia(芬兰)、Daimler-Benz(德国)、Sema Group（西班牙）、Forschungszentrum Informatik Karlsruhe（德国）和伯尔尼大学（瑞士）。Nokia和Daimler-Benz都是早期的面向对象技术的应用者，他们期望从这项研究中获益。目前，他们正面临遗留系统中的许多典型问题：有许多大型的和极有价值的面向对象软件系统，但这些系统很难适应不断变化的需求。FAMOOS项目的目标就是开发新的工具和技术，能够使这些面向对象的遗留系统恢复生机，从而能够持续发挥作用并更好地适应未来需求的变化。
　　在项目的开始，我们的思路是将这些大型的、面向对象的应用转换成框架—也就是通用的应用，从而能够使用大量不同的编程技术进行简单的重新配置。但我们很快发现，这件事说起来容易做起来难。尽管这个基本的研究思路听起来不错，但我们却很难决定遗留系统中的哪一部分应该转换以及到底如何转换。实际上，一开始光是理解遗留系统就不是一件很容易的事，更不用说发现其中的错误了（如果有的话）。
　　我们从这个项目中学到了许多东西。我们首先学到的是，遗留系统的代码并非都是不好的，遗留系统之所以有问题只是因为在原有系统设计和部署之后需求已发生了许多变化。软件系统经常被多次修改以适应变化的需求，系统忍受着设计漂移—初始的体系结构和设计不可能了解未来的所有需求变化—这就导致了不可能对系统进行更多的改进。这一点就像Lehman 和Belady所总结的软件发展规律所描述的那样。
　　研究中最使我们吃惊的是，尽管每一个我们研究的案例都是因为不同原因需要进行软件再工程，例如不再与原系统匹配、需求扩大、移植到新的环境等原因，但所有这些系统所出现的实际问题却都惊人的相似。这就启发我们，可能采用一些简单的技术就能够很好地解决许多相似的问题。
　　我们发现几乎所有的软件再工程活动都必须从某种反向工程开始，因为你无法信任原有文档（如果你碰巧有一些文档的话）。基本上，你会分析源代码，运行系统，采访用户和开发者以建立遗留系统的模型。那么，你必须确定要进一步开发并修正系统的障碍在哪里。这是再工程的关键，如果你有足够的先见之明，并且了解所有你今天所知道的新需求，这将帮助你将遗留系统转化为你即将建立的新系统。因为你不可能重建所有的系统，所以必须忽略细枝末节，仅仅再工程最重要的部分。
　　在FAMOOS项目之后，我们又参加了许多其他软件再工程项目，并将FAMOOS的研究成果进一步加以验证和优化。
　　本书中总结了我们所掌握的研究成果，希望它能够帮助那些需要对面向对象系统进行软件再工程的人们。我们并不认为我们能够给出解决所有问题的答案，但是我们确实阐明了一系列简单有效的技术，这些技术必将带来很好的帮助。

为什么使用模式
　　模式是一个重复的基调，一个不断重复出现的事件或者程序结构。设计模式是一种通用的解决方案，用来解决重复的设计问题[Gamm95]。由于这些设计问题从来都不是一模一样的—仅仅是非常类似，因此相应的解决方案就不是一段程序，而是能够传达最佳实践的文档。
　　近年来模式不断在文献中出现，它被用来归档那些解决许多不同问题的最佳实践。尽管许多问题和解决方案都可以通过模式来表述，但如果只应用于简单问题就有点大材小用了。模式作为一种文档描述形式是非常有用和有意义的，它要解决的问题常常是设计上的许多必然的矛盾影响因素，而相应的解决方案则描述了这些必然因素间的权衡。举例来说，很多著名的设计模式都是以增加设计复杂性的代价来提高系统运行的灵活性。
　　本书阐述了一系列用来对遗留系统进行软件再工程和反向工程的模式。这些模式都不能被盲目地使用。每一个模式解决一些矛盾影响因素，也涉及到某些权衡。理解这些权衡考虑是成功使用模式的基础。因此，模式形式看上去是用来记录我们最佳实践的最自然的方式，这些最佳实践是我们在我们的再工程项目中所认识到的。
　　一种模式语言是一组相关模式，这些模式可被结合使用以解决一系列复杂问题。我们发现将一些模式组合起来形成模式簇很有用。因此我们是按照模式簇（一个较小的模式语言集合）来组织本书章节的。
　　我们并不认为本书的模式簇在任何情况下都是“完备的”，我们也不认为本书的模式覆盖了软件再工程的所有方面。我们当然也不会认为本书阐述了面向对象软件再工程的系统化方法。我们在本书中所要表达的，仅仅是我们曾遇到和曾采用的一些最佳实践，这些实践展示出非常有意思的协同作用。这种很强的协同作用不仅包括在每一种模式簇中，而且还包括各个模式簇间以各种重要方式相互关联。因此，书中的每一章都不但包含一个模式图谱—模式图谱阐述了如何将模式作为一种“语言”来实现某种功能，而且每个模式还列出并解释了怎样与其他模式结合或组合，无论这些模式是否在同一个模式簇里。

本书的读者对象
　　本书主要是献给那些需要实现面向对象系统软件再工程的实践者们。如果从一个极端的观点来看，可以说每一个软件项目都是一个软件再工程项目。因此本书面向的读者群是非常广大的。
　　我们认为，对任何哪怕只有些许面向对象开发经验的读者来说，本书中的大部分模式都应该是比较熟悉的，本书的目的是阐述实践它们的细节。

序1
　　在很长一段时间里，我一直对一件事情比较困惑—那就是在大部分有关软件开发过程的书里，讨论的内容都是从编辑程序中的空白页开始工作。我之所以对此感到困惑，是因为在人们开始编写代码时，这并不是他们会面临的最通常的情境。很多人必须从改进既有代码库开始，即使这些代码库并不是他们自己编写的。理想情况下，这些代码经过了很好的设计和重构，但我们都知道理想情况在我们职业生涯中出现的几率。
　　本书很有意义的一个原因在于它采用的角度，它是从如何处理一些不完善但却有价值的代码库的角度撰写的。我还喜欢这样一个事实—那就是本书是基于将学术理论与工业实践相结合的角度。我曾经在FAMOOS团体成立之初在一个寒冷的初冬到伯尔尼拜访过他们。我非常喜欢他们的工作方式，他们在理论领域和实验室实践之间建立起了一个循环，尝试先将理论思想放入到真正的项目中检验，然后再从实验室实践中返回到理论总结。
　　以上的工作使得本书通过实践说话。本书为读者提供了构造模块，可以用来制定一个计划，以处理某个困难的源代码库，本书还阐述了使用各种技术（例如软件重构）时的语境。目前像本书这样的著作太少，这是一件让人遗憾的事情，因为目前进行软件再工程已经是一种非常普遍的工作了。但我至少可以很高兴地看到，虽然有关这个领域的书不多，但这些书都写得非常好，本书就是一个例子。

Martin Fowler
ThoughtWorks公司

序2
　　好模式的标志之一是：当专家们读了它可能会说：“当然如此，这是众所周知的!”但是初学者却可能会说：“这很有趣，但它是否有效果呢？”模式应该容易被效仿，但是最有价值的模式却是一些不那么让人一目了然的模式。专家们已经从经验中明白了模式是有效的，但初学者在他们使用模式并获得自己的经验之前，就必须相信模式的作用。
　　在过去的几年，我有机会将本书中的模式提供给许多人，并与之进行讨论。在我的这个模式讨论圈里，有一些人有数十年的咨询经验，他们能够很快与他人分享使用这些模式的经验。而讨论圈里年轻的成员们一旦信服了模式的价值之后，都开始喜爱这些经验了。
　　我让我的软件工程课上的学生学习了一些模式，将模式作为有关软件再工程的一个章节来学习。尽管一开始没有学生被模式的概念所打动，但这一章节的课程仍然上得很好。一开始学生们缺乏评估这些模式的实际经验。然而，还是有一个学生在做完暑假功课后跑来告诉我，在课程的所有内容中，反向工程中的模式最有用。在学生们取得这种经验之前，模式对他们而言似乎是可信的。而一旦他们获得经验之后，他们就会坚信模式的作用。
　　如果你在软件再工程方面有许多经验，你也许从本书中学不到太多的东西。但你仍然有必要阅读本书，因为你可以将本书送给同你一起工作的人们，在与他们讨论问题时可以使用本书的术语和概念。如果你是软件再工程的新手，那就更应该阅读本书，学习其中的模式，并且试用它们。你将学会许多有价值的东西；但是不要期望在使用模式之前完全理解它们，因为模式是实践中总结出的东西，而实践得出的知识在没有实践之前是无法被人真正理解的。尽管如此，本书仍然会给你很大的帮助。当你在实践中有路可循时，你将很容易掌握需要学习的东西，而本书正为你提供了一个可靠的指南。

Ralph E. Johnson, 伊利诺伊大学厄巴纳-尚佩恩分校

(美)Serge Demeyer：Serge Demeyer: 是比利时安特卫普大学数学和计算机科学系教授。

莫倩 王恺 译：暂无简介

第1章　 软件再工程模式 1
为什么我们要实施软件再工程 1
对象技术有什么特殊 3
再工程生命周期 4
再工程模式 7
再工程模式的形式 8
再工程模式图谱 9
第一部分　 反向工程
第2章　 设定方向 13
影响因素 13
概述 13
模式2.1：遵循基本准则 14
模式2.2：指派一名领航员 14
模式2.3：在圆桌会议上发言 15
模式2.4：最有价值的优先 15
模式2.5：修正问题，而非消除症状 17
模式2.6：如果还没有坏，就不要修补它 18
模式2.7：保持简单 18
第3章　 首次接触 21
影响因素 21
概述 22
下一步 23
模式3.1：与维护人员交谈 23
模式3.2：在一小时内通读所有代码 27
模式3.3：浏览文档 31
模式3.4：在演示中采访 35
模式3.5：模拟安装 40
第4章　 初始理解 45
影响因素 45
概述 46
下一步 46
模式4.1：分析持久数据 47
模式4.2：推测设计 52
模式4.3：研究异常实体 57
第5章　 详细模型获取 65
影响因素 65
概述 65
下一步 66
模式5.1：绑定代码和问题 66
模式5.2：为理解而重构 70
模式5.3：步进执行 72
模式5.4：寻找约定 74
模式5.5：向过去学习 76
第二部分　 再工程
第6章　 测试：生命的保障 81
影响因素 81
概述 82
模式6.1：为推动演化而编写测试 82
模式6.2：增量式扩充测试库 85
模式6.3：使用测试框架 87
模式6.4：测试接口而非实现 92
模式6.5：记录业务规则作为测试 94
模式6.6：为理解而编写测试 96
第7章　 移植策略 99
影响因素 99
概述 99
模式7.1：让用户参与 100
模式7.2：建立信心 101
模式7.3：增量式移植系统 102
模式7.4：原型化目标解决方案 104
模式7.5：总保持一个运行版本 105
模式7.6：每次改变之后进行回归测试 106
模式7.7：建立通往新城镇的桥梁 107
模式7.8：提供正确的接口 108
模式7.9：区分公共的和已发布的接口 109
模式7.10：失效过时接口 110
模式7.11：保持熟悉度 112
模式7.12：在优化前使用分析器 112
第8章　 检测重复代码 115
影响因素 115
概述 115
模式8.1：机械地比较代码 116
模式8.2：将代码可视化成点状图 120
第9章　 重新分布责任 125
影响因素 125
概述 125
模式9.1：使行为更靠近数据 126
模式9.2：消除导航代码 133
模式9.3：分解全能类 140
第10章　 转换条件分支到多态 145
影响因素 145
概述 145
模式10.1：转换对自身类型的检查 146
模式10.2：转换对调用者类型的检查 152
模式10.3：提取状态 158
模式10.4：提取策略 160
模式10.5：引进空对象 162
模式10.6：转化条件分支为注册 164
附录　 模式简介 171
参考文献 176