描述了怎样反向工程一个巨大的系统，从而理解它是如何工作的；以及怎样才能发现它潜在的问题。
包含了在面向对象编程中经常会遇到的、某些著名再工程技术所涉及的再工程模式，例如引入多态、提取公共行为、检测重复代码和理解设计。
展示了如何为获得灵活和可维护的面向对象系统而建立一种不断再工程的文化。
大部分有关软件工程的书讨论的都是如何进行正向的软件项目开发，而少有提及如何处理有价值的遗留系统。然而在现实中，许多人在工作中面临的都是处理现有的代码库。
本书作者从自身参与欧洲工业研究项目FAMOOS的实践出发，总结了对面向对象的软件系统进行再工程时的最佳实践，并把它们精炼成模式。每个模式都从分析问题人手，然后给出权衡考虑了各方面影响因素后的解决方案，并解释其合理性或给出例子。本书是一本实践性很强的面向对象软件再工程指南。

本书的赞誉
序1
序2
前言
第1章 软件再工程模式
为什么我们要实施软件再工程
对象技术有什么特殊
再工程生命周期
再工程模式
再工程模式的形式
再工程模式图谱
第一部分 反向工程
第2章 设定方向
影响因素
概述
模式2．1：遵循基本准则，
模式2．2：指派一名领航员
模式2．3：在圆桌会议上发言
模式2．4：最有价值的优先
模式2．5：修正问题，而非消除症状

一个童话故事
从前有一位优秀的软件工程师，他的客户都确切地知道自己的需求。这位优秀的软件工程师努力地工作，并设计了一个完美的系统，这个系统能够解决客户当前和以后的所有问题。当这个完美的系统经过设计、实现和最终部署之后，客户都感到非常高兴。系统的维护工程师无需做任何工作就能让这个完美的系统很好地运行，客户和系统维护工程师从此以后一直快乐地生活着。
为什么现实生活不能像这个童话故事一样呢?
难道是因为没有优秀的工程师吗?难道是客户没有真正了解他们自己的需求吗?或者是因为根本就不存在完美的系统呢?
也许上面所说的都有一点道理，但真正的原因恐怕在于多年以前由Manny Lehman和LesBelady所总结的软件发展的基本规律。这些基本规律中最重要的两点是：
持续变化规律。在一个真实的应用环境中使用的程序，一定是不断被改变的，否则那个应用环境本身就会变得越来越没有用处。
复杂性不断增长的规律。当一个程序不断地发展，它会变得越来越复杂，并需要消耗额外的资源来保持并简化它自己的结构。
换句话说，如果我们认为自己能够了解所有的需求，并能构建完美的系统， 那么就是在自己骗自己。我们所能够做到的最好情况是构建一个有用的系统，并且能够运行足够长的时间，直到需要它做新的工作为止。
本书内容
本书的起因在于充分认识到这样一个事实--软件工程最有意义和最具挑战性的一面不是建立一个新的软件系统，而是重构既有系统。
从1996年11月到1999年12月，我们参加了一个名为FAMOOS的欧洲工业研究项目 (ESPRIT项目21975--掌握面向对象软件发展的基于框架的方法研究，Framework-based Approach forMastering Object-Oriented Software Evolution)。合作伙伴包括Nokia(芬兰)、Daimler-Benz(德国)、Sema Group(西班牙)、Forschungszentrum lnformatik Karlsruhe(德国)和伯尔尼大学(瑞士)。Nokia和Daimler-Benz都是面向对象技术的早期应用者，他们期望从这项研究中获益。目前，他们正面临遗留系统中的许多典型问题：有许多大型的和极有价值的面向对象软件系统，但这些系统很难适应不断变化的需求。FAMOOS项目的目标就是开发新的工具和技术，使这些面向对象的遗留系统恢复生机，从而能够持续发挥作用并更好地适应未来需求的变化。
在项目一开始，我们的思路是将这些大型的、面向对象的应用转换成框架--也就是通用的应用，从而能够使用大量不同的编程技术进行简单的重新配置。但我们很快发现，这件事说起来容易做起来难。尽管这个基本的研究思路听起来不错，但我们却很难决定应该转换遗留系统中的哪一部分以及到底如何转换。实际上，一开始光是理解遗留系统就不是一件很容易的事，更不用说发现其中的错误了(如果有的话)。
我们从这个项目中学到了许多东西。我们首先学到的是，遗留系统的代码并非都是不好的，遗留系统之所以有问题只是因为在原有系统设计和部署之后需求已发生了许多变化。软件系统经常被多次修改以适应变化的需求，系统忍受着设计漂移--初始的体系结构和设计不可能了解未来的所有需求变化，这就导致了不可能对系统进行更多的改进。这一点就像Lehman和Belady所总结的软件发展规律所描述的那样。
研究中最使我们吃惊的是，尽管我们研究的每一个案例都是因为不同原因需要进行软件再工程，例如不再与原系统匹配、需求扩大、移植到新的环境等原因，但所有这些系统所出现的实际问题却都惊人的相似。这就启发我们，可能采用一些简单的技术就能够很好地解决许多相似的问题。
我们发现几乎所有的软件再工程活动都必须从某种反向工程开始，因为你无法信任原有文档(如果你碰巧有一些文档的话)。基本上，你会分析源代码，运行系统，采访用户和开发者，以建立遗留系统的模型。那么你必须确定，要进一步开发并修正系统，存在的障碍在哪里。这是再工程的关键。如果你有足够的先见之明，并且了解所有你今天所知道的新需求，这将帮助你将遗留系统转化为你即将建立的新系统。因为你不可能重建所有的系统，所以必须忽略细枝末节，仅仅再工程最重要的部分。
在FAMOOS项目之后，我们又参加了许多其他软件再工程项目，并将FAMOOS的研究成果进一步加以验证和优化。
本书中总结了我们所掌握的研究成果，希望它能够帮助那些需要对面向对象系统进行软件再工程的人们。我们并不认为我们能够给出解决所有问题的答案，但是我们确实阐明了一系列简单有效的技术，这些技术必将给大家带来很好的帮助。为什么使用模式
模式是一个重复的基调，一个不断重复出现的事件或者程序结构。设计模式是一种通用的解决方案，用来解决重复的设计问题[Gamm95]。由于这些设计问题从来都不是一模一样的--仅仅是非常类似，因此相应的解决方案就不是一段程序，而是能够传达最佳实践的文档。
近年来模式不断在文献中出现，它被用来归档那些解决许多不同问题的最佳实践。尽管许多问题和解决方案都可以通过模式来表述，但如果只应用于简单问题就有点大材小用了。模式作为一种文档描述形式是非常有用和有意义的，它要解决的问题常常是设计上的许多必然的矛盾影响因素，而相应的解决方案则描述了这些必然因素间的权衡。举例来说，很多著名的设计模式都是以增加设计的复杂性为代价来提高系统运行的灵活性。
本书阐述了一系列用来对遗留系统进行软件再工程和反向工程的模式。这些模式都不能盲目地使用。每一个模式解决一些矛盾影响因素，也涉及到某些权衡。理解这些权衡考虑是成功使用模式的基础。因此，模式形式看起来是记录我们最佳实践的最自然的方式，这些最佳实践是我们通过再工程项目所认识到的。

在很长一段时间里，我一直对一件事情比较困惑--那就是在大部分讨论软件开发过程的书里，所讨论的都是从零开始编辑程序。我之所以对此感到困惑，是因为在人们开始编写代码时，这并不是他们最通常所面临的情境。很多人必须从改进既有代码库开始，即使这些代码库并不是他们自己编写的。理想情况下，这些代码经过了很好的设计和重构，但我们都知道理想情况在我们职业生涯中出现的几率。
本书很有意义的一个原因在于它采用的角度，它是从如何处理一些不完善但却有价值的代码库的角度撰写的。我还喜欢这样一个事实--那就是本书基于将学术理论与工业实践相结合的角度来写作。我曾经在FAM00S团体成立之初在一个寒冷的初冬到伯尔尼拜访过他们。我非常喜欢他们的工作方式，他们在理论领域和实验室实践之间建立起了一个循环，尝试先将理论思想放入到真正的项目中检验，然后再从实验室实践中返回到理论总结。
以上的工作使得本书的实践性很强。本书为读者提供了构造模块，可以用来制定一个计划，以处理某个困难的源代码库。本书还阐述了使用各种技术(例如软件重构)时的语境。目前像本书这样的著作太少，这是一件让人遗憾的事情，因为目前进行软件再工程已经是一种非常普遍的工作了。但我至少可以很高兴地看到，虽然有关这个领域的书不多，但这些书都写得非常好，本书就是一个例子。
Martin Fowler
ThoughtWorks公司
好模式的标志之一是：当专家们读了它可能会说："当然如此，这是众所周知的!"但是初学者却可能会说："这很有趣，但它是否有效果呢?"模式应该容易被效仿，但是最有价值的模式却是一些不那么让人一目了然的模式。专家们已经从经验中明白了模式是有效的，但初学者在'使用模式并获得自己的经验之前，就必须相信模式的作用。
在过去的几年里，我有机会将本书中的模式提供给许多人，并与之进行讨论。在我的这个模式讨论圈里，有一些人有数十年的咨询经验，他们能够很快与他人分享使用这些模式的经验。而讨论圈里年轻的成员们一旦信服了模式的价值之后，都开始喜爱这些经验了。
我让我的软件工程课上的学生学习了一些模式，将模式作为有关软件再工程的一个章节来学习。尽管一开始学生们都没有被模式的概念所打动，但这一章节的课程仍然上得很好。一开始学生们缺乏评估这些模式的实际经验；然而，还是有一个学生在做完暑假功课后跑来告诉我，在课程的所有内容中，反向工程中的模式最有用。在学生们取得这种经验之前，模式对他们而言似乎是可信的。而一旦他们获得经验之后，他们就会坚信模式的作用。
如果你在软件再工程方面有许多经验，你也许从本书中学不到太多的东西。但你仍然有必要阅读本书，因为你可以将本书送给同你一起工作的人们，在与他们讨论问题时可以使用本书的术语和概念。如果你是软件再工程的新手，那就更应该阅读本书，学习其中的模式，并且试用它们。你将学会许多有价值的东西；但是不要期望在使用模式之前完全理解它们，因为模式是实践中总结出的东西，而从实践得出的知识在没有实践之前是无法被人真正理解的。尽管如此，本书仍然会给你很大的帮助。当你在实践中有章可循时，你将很容易掌握需要学习的东西，而本书正为你提供了一个可靠的指南。
Ralph E．Johnson，伊利诺伊大学厄巴纳-尚佩恩分校