1 软件再工程的过程
一般来说，没有被很好的维护和控制的代码可能是由没有很好组织的遍布在很多地方的 多个文件组成的，或是在一个大文件中有上万行的代码，也可能存在同一文件的多份拷贝。看看这些文件，你会发现它们基本都没有注释，或是只有很少的基本的注释。任何相关的文档都没有及时的更新。。。看起来是一片混乱。
针对这类情况的再工程过程（大多数情况都是这样的）可以分为11个步骤：
1. 阅读并辨识现存的源代码和文档。
2. 检查并调试已经被辨识出的源代码，用它们建立一个baseline(基线)。
3. 熟悉现有的应用程序。
4. 整理再工程需求，了解需要什么。
5. 编写一个再工程计划。
6. 提供一个测试计划，以及相应的测试数据和测试脚本。
7. 对原始版本进行测试，获取测试结果。
8. 对已移植的版本进行测试（如果存在这个版本），获取测试结果。
9. 分可以明确划分的阶段对代码进行重构。
10.在每个阶段过后，对代码进行测试。
11.更新（或是编写）文档。
在最初几步上花费些时间可以使我们在以后的再工程中节省大量时间，明白这一点是非常重要的。如果缩减在这些步骤上的时间，可能会造成我们浪费大量的时间在对不应该重构的代码上。
1.1 阅读并辨识现存的源代码和文档
再工程过程的第一步就是阅读并辨识再工程针对的软件的所有文件（包括源代码和文档）。一般来说，应该有原始工程的参与者参与这一步骤，他会比较清晰地解释代码逻辑。对于项目中使用的第三方的软件工具，也应该对其进行检查。
在配置计划中会定义所有这些已经被辨识的文件的组织形式（存放的目录结构等）。根据这个配置计划辨识所有需要的组件、他们的版本号等。
在再工程的所有步骤中，开发者应该记录所有的相关因素以及它们的来源（比如：这个文件需要被包含，因为XX说它包括了对X参数的解析，在1.x版本中使用了这个文件）
1.2 检查并调试已经被辨识出的源代码，用它们建立一个baseline
希望在上一个步骤中，用来构建应用程序所需要的文件都被顺利辨识出来了。因为在这一个步骤中，我们需要重新构建这个应用程序。这可能需要我们研究一下编译选项，使得我们可以成功构建出那个应用程序，一模一样的那个应用程序，没有任何改变（比如使用的第三方产品的版本，编译器的版本，编译器选项等）。
在构建完毕后，我们可以在同一个平台上运行这个程序，并输入测试数据或测试文件，通过验证软件行为来确定这个应用程序和原来的那个程序是一样的。在这个过程中使用的测试数据和文件，测试的结果以及被测试的应用程序的版本都要记录下来。
源代码文件以及任何相关的数据文件应该被写入文档，并使用这些文件来构成现有版本的baseline。
1.3 熟悉现有的应用程序
现在，对于进行再工程的开发者来说，最重要的就是要开始熟悉这个应用程序。通做测试不同情况下程序的运行情况，做code review以及和用户进行讨论，开发者可以了解这个应用程序是用来做什么的，是怎么做的。在这一步中，与熟悉代码的人进行一些接触是必要的。
在这一阶段中，开发者可以开始向代码中添加一些对于重构有帮助的注释。其它相关的想法，比如如何改进代码、使用到的算法描述、流程图等都可以写入到项目日志中。
在这一阶段中很可能会发现一些bug。关于这些bug的处理需要与客户商量解决。一般来说，要将这阶段发现的bug编号，以便再编码时针对性的解决它们。
1.4 整理再工程需求，了解需要什么
下一步就是要明确本次再工程过程要达到什么目的，它可能是以下条目中的一条或几条：
1. 为代码添加注释
2. 模块化
3. 为代码生成文档
4. 辨认并去除无用的代码
5. 辨认并去除重复的代码
6. 辨认并去除重复的参数或定义
7. 将代码移植到另一个平台
8. 改善用户界面（界面美化、使用新技术改善用户体验）
9. 代码标准化
10.将代码“翻译“为另一种编程语言
11.改进运行性能
12.优化代码
13.改进内部异常的处理
14.修改已经存在的bug
15.使用可选的第三方产品
其中每一条都可以分解成一组详细的软件需要说明。
1.5 编写一个再工程计划
一旦确定了再工程的需求，就要写一个关于如何实施的详细计划。为了能很好地控制这个过程，应该将整个再工程过程分解成一个个阶段。在每一个阶段结束的时候，要使用已有的代码生成一个baseline. 使用这些代码生成可执行文件，并检验它是否和原始版本的功能行为一致。以阶段为单位进行这样的工作，是为了保证所有可以在再工程中引入的新问题都可以很快到被发现，并找出原因。
在进行下一步之前，要与客户在这个计划上达成一致。
1.6 提供一个测试计划，以及相应的测试数据和测试脚本
为了测试、验证一个应用程序，需要编写一个测试计划及相应的测试脚本。测试计划就是解释测试如何进行，测试脚本就是提供一系列的操作来完成测试。测试人员根据测试脚本提供的一系列测试用例完成测试，并且要保证这些测试用例每次的结果都是一致的。一个测试用例包括一个唯一的编号、一个简要的测试过程说明、期望得到的结果以及一个空白区域让测试人员填写此测试用例的结果。测试脚本应该记录被测试的应用程序的版本、测试平台、操作系统的版本、使用到的第三方产品、测试人员的名字以及测试日期等一切相关信息。
为了辅助测试，可能需要使用大量的数据文件做为输入，并会产生大量的输出文件。这些输出文件应该被保存下来，并用来确认当前版本与原始版本的一致性。
1.7 对原始版本进行测试，获取测试结果
使用定义好的输入数据，在原始版本的应用程序中运行测试脚本。测试产生的结果数据，结果文件将被用来检验再工程的代码。
如果需要的话，在这阶段中还要测量代码的性能。
1.8 对已移植的版本进行测试（如果存在这个版本），获取测试结果
如果代码被移植到了其它的平台上，那么有必要也在移植的版本上运行测试脚本。如果需要对测试脚本做出修改，比如使用目标平台上的一些特定语言扩展来代替现有的，要保证这些修改尽可能的少，并且要记入文档中。
如果原始版本和移植后的版本的测试结果出现了不同，应该与客户就此进行讨论，并对解决方法达成一致。
如果软件性能也在范围之内，则在这一步骤中也要测量性能，并与其在原始平台上的性能进行比较。
1.9 分可以明确划分的阶段对代码进行重构
在代码重构过程中，软件工具可以被用来检测代码覆盖、无用的变量以及代码是否符合代码标准等。手动的代码检测可以被用来帮助检测并移除重复代码、优化存储、合并参数定义等。
代码重构过程是改进代码性能的好机会。很多小的细节都可能对软件性能产生很大的影响。比如不同语言对于数据存储的方式不同，那么访问数据的方式就可能对软件性能产生影响。
1.10 在每个阶段过后，对代码进行测试
在每个阶段完成以后，应该在重构后的代码上运行系统测试脚本，并将得到的测试结果与原始版本的测试结果进行对比。只有在保证两者一致之后，才能进行一下个步骤。
每一步完成之后，应该使用现有代码生成一个baseline，同时一份可辨识的版本连同相关的测试结果应该被保存下来。这样做可以帮助开发者很容易地返回到以前的任何一个版本中。这对于追踪bug以及准确定位bug的位置很有帮助。同时它允许用户在任何一个阶段结束时生成一份完整的代码。
1.11 更新（或是编写）文档
最后，当整个再工程过程结束后，应该更新所有已有的系统文档，并补充缺少的文档。文档是软件再工程过程中十分重要的一部分，它是信息的主要来源，可以在将来帮助支持和维护应用程序。一份明确完整的文档可以使任何一个熟悉相应编程语言的程序员很快的了解代码，并在很短的时间内提供技术支持。
文档的内容依赖于进行再工程的软件的类型以及已有的支持文档。但文档中有一个部分是肯定要有的，那就是在整个再工程过程中做出的变化（修改）的描述。另外的一些应该被包括的部分是：
1. 安装/反安装的步骤说明，以及如何确认是哪一个版本被安装了
2. 软件的简明使用手册
3. 软件的设计概述（如果需要的话，可以写得更详细些）
4. 关于如何构建release版本的软件的详细说明
最后，使用完成的代码，连同相关文档以及项目日志生成baseline。现在一个经 过再工程的软件已经完成了。
