8.1什么是软件演化

由于种种不可避免的原因，系统开发完成后的软件需要进行修改来适应变更的需求，我们对软件的修改就叫软件演化。

8.2为什么软件会演化

1. 由于业务的变更或者为了满足用户期待的改变，使得对已有的系统的新需求浮现出来。由于各种原因，软件的某些部分需要进行修改。
2. 对于已安装的系统，随着业务流程和它的环境的变化，其需求也随之改变。

8.3软件演化的优点

1. 可以更好地满足用户的需求，提高软件的性能和可用性等性能

8.4软件演化的缺点

1. 对于一些大规模的企业来说，软件演化的代价及其昂贵

8.5演化和开发的螺旋模型

1. 每次有了新的需求都需要新的SRS，根据SRS来进行软件演化，直到软件的退役。
2. 螺旋模型的每一圈都是一个生命周期，都会发布一个新的版本
3. 这是这本书唯一一个与风险控制结合的模型

（螺旋模型通过在每个开发周期的各个阶段（规格说明、实现、确认和运行）中不断进行风险评估和控制，将风险控制与软件开发过程紧密结合。在螺旋模型中，每个周期的开始阶段都涉及风险评估，以识别和分析项目可能面临的风险。随着螺旋的旋转，每个阶段都提供了机会来评估项目进展，确保风险得到管理，并在必要时采取措施来减轻风险。通过这种方式，螺旋模型确保了项目在开发过程中持续地进行风险控制，从而提高了项目成功的可能性。）

8.6将演化和维修区别开的一个软件演化生命模型

8.7变更识别和演化过程

在所有的组织中，正式或者非正式的系统变更建议都是系统演化的动力。

8.8变更的实现流程

1）一般的变更流程

2）紧急的变更流程

1>紧急的变更流程

 

紧急的系统修补需要尽快地完成，应当选用一种快速地可行方法

2>为什么紧急的变更流程不可以直接修改代码

紧急的变更流程不直接修改代码的原因是为了确保软件的稳定性和质量。直接修改代码可能会引入新的错误或问题，特别是在没有充分测试的情况下。以下是几个关键原因：

1.代码审查：在修改代码之前进行代码审查可以确保变更符合代码标准和设计模式，减少引入错误的风险。

2.测试：变更后需要进行充分的测试，包括单元测试、集成测试和系统测试，以确保变更没有破坏现有功能。

3.版本控制：通过版本控制系统（如Git）进行变更，可以跟踪变更历史，便于回滚到之前的版本，同时确保团队成员可以访问最新的代码。

4.构建和部署：变更需要通过构建和部署流程，确保变更正确地集成到软件中，并且可以被部署到生产环境。

5.文档更新：变更需要更新相关的文档，包括设计文档、用户手册等，以确保文档与代码保持一致。

6.风险管理：直接修改代码而不遵循标准流程可能会导致不可预见的风险，如安全漏洞、性能问题等。

7.团队协作：遵循标准的变更流程可以确保团队成员之间的协作和沟通，避免因信息不对称导致的冲突。

8.合规性：对于某些行业（如医疗、金融等），直接修改代码可能违反法规要求，需要遵循特定的变更管理流程。

因此，即使在紧急情况下，也应遵循标准的变更管理流程，以确保软件的稳定性和质量。这有助于减少风险，提高软件的可靠性和可维护性。

3>紧急的修复过程带来的缺陷

紧急修补后，会加速软件的老化，所以在紧急修补后，最好对软件进行一次重构来提高代码质量和避免软件的老化。

*8.9遗留系统(Legacy System)

1）什么是遗留系统

遗留系统是比较老的系统，它们依赖于一些在新系统开发中不再使用的语言或者技术。经典情况下，它们已经被维护了很长的一段时间，它们的结构可能已经由于所做的修改而发生了退化。遗留软件可能无法依赖于更老的硬件

2）造成遗留系统的原因

1. 更老的硬件
2. 不再使用的语言或者技术
3. 应用的数据会出现很多重复且不一致的情况，分散在大量的数据库中
4. 业务流程的变动
5. 业务政策和规则

3）遗留系统维护成本高的原因

1. 遗留系统往往会缺少一个完备的规格说明
2. 业务过程以及遗留系统的允许方式经常不可避免地交织在一起
3. 重要的业务流程可能会蕴含在软件中，并且可能并没有进行专门的文档描述
4. 新的软件开发从内在来讲也是充满风险的，因此新系统中可能会存在无法预见的问题

4）管理遗留系统

1. 彻底废弃这个系统：当遗留系统不能再对业务流程过程产生有效的作用的时候。
2. 对系统进行再工程以改善其可维护性：当系统质量由于经常性的变更已经下降，而且仍然需要进行做经常性地变更的时候
3. 不再大量修改系统仅仅保持常规维护：当一个系统仍然由存在的必要，系统运行地平稳，而且用户没有提出太多对系统的变更要求的时候
4. 用一个新的系统来代替整体或者部分系统：当其他因素使得新系统开发的成本非常合理的时候，就应该做出这样的改变。

8.10软件维护（Software maintenance）

1）什么是软件维护

软件的维护是指在软件发布后，为了保持其正常运行、修复缺陷、改进性能、适应环境变化或满足用户新需求而进行的一系列活动。软件维护是软件生命周期中的一个重要阶段，它确保软件能够持续满足用户的需求，并延长软件的使用寿命。

2）软件维护的类型

1. 修复软件缺陷
2. 使软件适应不同的操作韩环境
3. 增加或修改系统功能

8.11软件再工程（reengineering）

1）什么是软件再工程

1. Software Reengineering是指对现有软件系统进行分析、重构和改进的过程，以提高其可维护性、可扩展性、可重用性和性能。再工程通常涉及对软件的内部结构和外部行为的修改，而不改变其原有的功能。再工程的目的是为了使软件系统能够适应新的技术环境、业务需求或用户期望。
2. 一般来说软件再工程不会对软件的功能产生改变，也应该尽力避免对系统体系结构的大的改动。

2）*软件再工程包括什么

1. 对系统重新建立系统文档
2. 重构系统体系结构
3. 用一重更加先进的重新设计语言来转换系统
4. 修改和更新系统的数据结构和系统的数据取值

3）什么时候使用reengineering

当系统使用了很长的时间了，性能不太好了，这时候我们需要再过程，增强结构性和可理解性。

8.12软件重构（refactoring）

1）什么是软件重构

1. 软件重构是提升程序以减缓其由于更改或退化的过程。它意味着通过修改程序来改进程序的结构性，让程序变得更加容易理解。它意味着通过修改程序来改进程序的结构性，降低程序复杂性，让程序变得更加容易理解。重构有时被认为局限于面向对象的开发，但是其原理可以被任何开发方法使用。
2. 重构是极限编程这样的敏捷方法中必有的过程，极限编程会让软件的体系结构很快退化，通过重构来减缓这个由于更改或退化的过程。

2）重构哪些不好的地方（坏味道）

1>冗余代码：

在程序的不同地方多次出现的代码

2>长方法：

如果方法太长了，我们应该重新设计这个方法，或者将它分解为几个短方法

3>选择语句：

这种情况往往会牵扯到重复，因为选择语句switch依靠的是同一个值的不同类型，选择语句可能会分散在程序的各个地方。

【可以使用表驱动法（Table-Driven Method）：使用表（如数组或哈希表）来存储逻辑，通过查找表来决定执行哪个操作，而不是使用条件语句。

多态（Polymorphism）：通过继承和多态，可以使用基类的引用指向派生类的对象，并调用派生类的方法。这样，可以在运行时根据对象的实际类型来执行不同的行为，而不需要在编译时使用条件语句。】

 

1》表驱动法（Table-Driven Method）的例子

假设我们正在开发一个简单的计算器程序，该程序能够执行加法、减法、乘法和除法运算。使用表驱动法，我们可以创建一个操作表来决定执行哪种运算。

 

解释

在这个例子中，我们定义了一个 operations 的哈希表，它将运算符（如"+"、"-"、"*"、"/"）映射到相应的 BiFunction<Double, Double, Double> 函数。当用户请求计算时，我们通过查找表来决定执行哪个操作，而不是使用 if-else 语句。

2》多态（Polymorphism）的例子

假设我们有一个动物类 Animal，它有一个 makeSound() 方法。我们创建了几个继承自 Animal 的子类，如 Dog、Cat 和 Bird，每个子类都重写了 makeSound() 方法来发出不同的声音。

在这个例子中，我们使用了多态性。尽管 dog、cat 和 bird 都是 Animal 类型的引用，但它们指向的是 Dog、Cat 和 Bird 的对象。当调用 makeSound() 方法时，实际执行的是每个对象的 makeSound() 方法，这取决于对象的实际类型。这样，我们就不需要在编译时使用条件语句来决定调用哪个方法，而是让 Java 运行时根据对象的实际类型来决定。

 

 

4>数据聚集：

当同样的一组数据项（类中的域，方法中的参数）在程序中不同地方重复出现时，数据聚集就出现了。着通常可以通过用一个对象封装所有的数据来解决

 

假设我们正在开发一个在线书店系统，其中有一个订单类（Order）和一个订单项类（OrderItem）。每个订单包含多个订单项，每个订单项包含商品信息和数量。

未

解释

在这个例子中，Order 类和 OrderItem 类都包含了商品ID（productId）、商品名称（productName）、数量（quantity）和价格（price）。这些数据项在两个类中重复出现，导致了数据聚集。

优化后的代码：

为了解决数据聚集的问题，我们可以创建一个新的类 Product 来封装商品信息：
 

解释

通过将商品信息封装到 Product 类中，我们消除了 Order 和 OrderItem 类中的数据聚集。现在，如果商品信息需要修改（例如，商品名称或价格），我们只需要在一个地方修改 Product 类即可，这使得代码更加易于维护。

优点：

• 减少重复代码：通过封装数据到一个对象中，减少了代码中的重复。
• 提高可维护性：修改数据结构时只需在一个地方进行，降低了维护成本。
• 提高可读性：代码更加清晰，因为数据项的含义和用途更加明确。

 

 

5>假设的一般性：

即开发者为了以后万一使用到在程序中包含了一般性。这通常可以简单地删除掉。