程序可维护性

一、概念

1.什么是软件维护
在软件发布后，修改软件以修正错误 和提升性能
维护不只是运维工程师的工作
软件维护不仅仅是运维工程师的工作，而是从设计和开发阶段就开始了
设计和开发者需要考虑软件未来的变化和扩展
设计方案的“easy to change”
这也就是我们说的软件构造的可维护性、可扩展性和灵活性。
面向可维护性的软件构造的例子
模块化、OO设计原则、OO设计模式、基于状态的构造技术、表驱动的构造技术、基于语法的构造技术

软件演化：对软件进行持续的更新
软件的大部分成本来自于维护阶段
软件生命周期中的多个版本：从 1 到 n

2.可维护性的度量
可维护性：修改软件系统或组件以纠正错误、提高性能或其他属性或适应变化的环境的难易程度。
可扩展性：软件设计/实现考虑了未来的增长，并被视为扩展系统能力和实现扩展所需的工作水平的系统度量。
灵活性：软件根据用户需求、外部技术和社会环境等轻松更改的能力。
可适应性：一种交互系统（自适应系统）的能力，它可以根据获取的有关其用户及其环境的信息来调整其行为以适应各个用户。
客管理性：监控和维护软件系统以保持系统运行、安全和平稳运行的效率和容易程度。
支持性：根据包括质量文档、诊断信息和知识渊博且可用的技术人员在内的资源，软件在部署后保持运行的效率如何。

二、模块化设计和模块化原则

模块化编程
模块化编程是将程序的功能分散到独立可交互的模块中，是高层的功能分解技术
高内聚、低耦合、分离关注点、信息隐藏
1.评估模块性的五个标准
可分解性、可组合性、可理解性、可持续性（发生变化时受影响范围最小 ）、出现异常之后的保护（出现异常后受影响范围最小）
可分解性
将问题分解为各个可独立解决的子问题，从而使模块之间的依赖关 系显式化和最小化。
可组合性
可容易的将模块 组合起来形成新的系统，目标是使模块可在不同的环境下复用。
可理解性
指每个子模块都可被系统设计者容易的理解。
可持续性
小的变化将只影响一小部分模块，而不会影响整个体系结构
保护性
运行时的不正常将局限于小范围模块内。
2.模块化设计的五个规则
直接映射
模块的结构与现实世界中问题领域的结构保持一致
受影响的评价标准：可持续性，可分解性
尽可能少的接口
模块应尽可能少的与其他模块通讯
受影响的评价标准：可持续性、保护性、可理解性、可组合性
”不要对太多人讲话…”
尽可能小的接口
如果两个模块通讯，那么它们应交换尽可能 少的信息
受影响的评价标准：可持续性、保护性
”不要讲太多…”
显式接口
当A与B通讯时，应明显的发生在A与B的接口之间
受影响的评价标准：可分解性、可组合性、可持续性、 可理解性
信息隐藏
经常可能发生变化的设计决策应尽可能隐藏在抽象接口后面
受影响的评价标准：可持续性
3.耦合和内聚
耦合
耦合是模块之间依赖性的度量。 如果一个模块中的更改可能需要更改另一个模块，则两个模块之间存在依赖关系。通常由接口数量和接口复杂度来评价。
内聚
内聚是衡量模块的方法或职责的相关程度。
内聚和耦合
最佳的设计模式是高内聚、低耦合。

三、OO设计原则：SOLID

1.单一责任原则（SRP）
不应该有多于1个原因让你的ADT发生变化，否则就应该拆分开
一个类，只能有一个责任（否则会引起不良后果）
2.开放/封闭原则（OCP）
OCP对扩展是开放的 ，对修改是封闭的，应通过继承和组合改变/扩展功能。模块的行为应是可扩展的，从而该模块可表现出新的行为以满足需求的变化，但模块自身的代码是不应被修改的；扩展模块行为的一般途径是修改模块的内部实现；如果一个模块不能被修改，那么它通常被认为是具有固定的行为。
关键的解决方案：抽象技术
3.里氏代换原则（LSP）
子类型必须能够替换其基类型
派生类必须能够通过其基类的接口使用，客户端无需了解二者之间的差异
4.接口隔离原则（ISP）
不能强迫客户端依赖于它们不需要的接口：只提供必需的接口，而“胖”接口具有很多缺点，例如不够聚合。
5.依赖转置原则（DIP）
抽象的模块不应依赖于具体的模块，具体应依赖于抽象。或者说高层模块不应该依赖于低层模块,二者都应该依赖于抽象，抽象不应该依赖于实现细节,实现细节应该依赖于抽象