本书特点：
描述了怎样反向工程一个巨大的系统，从而理解它是如何工作的；以及怎样才能发现它潜在的问题。
包含了在面向对象编程中经常会遇到的、某些**再工程技术所涉及的再工程模式，例如引入多态、提取公共行为、检测重复代码和理解设计。
展示了如何为获得灵活和可维护的面向对象系统而建立一种不断再工程的文化。 作者简介：
Serge Demeyer 是比利时安特卫普大学数学和计算机科学系教授。
St'ephane Ducasse 是瑞士伯尔尼大学软件合成组织的副教授，并担任FAMOOS项目的技术负责人。
Oscar Nierstrasz 是伯尔尼大学的计算机科学系教授，负责领导该校的软件合成组织。

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

书评
面对**系统，人们经常遇到的情况是：文档丢失或过时了；原有的开发人员不知去向；现有的开发团队对系统知之甚少；系统组件有很多都没有经过单元测试；修改了一处错误，又出现了另一种错误；系统重建时间很长，以至于对系统做任何改进都很困难。然而，**软件又是业务工作所必需的，不能简单丢弃，需要继续使用或升级更新。这时，开发人员要如何理解系统，充分降低**系统的复杂性，以便能以可接受的代价继续使用和改进原有系统呢？这就是本书要传达给读者的技术。
如何对**系统进行反向工程以理解系统中的问题，然后对系统进行再工程以满足新的需求。本书就是一本关于这方面内容的指南。
再工程模式清晰地界定和解释了如何理解现有大型代码库，如何转换它们以满足新的需求。关键是要认识到，系统的正确设计和组织，并非简单地因为理解了系统的初始需求，而是由于认识到这些需求是不断变化的。