第六章代码的可维护性——可维护性的度量和构造原则

1.软件的维护与演化

我们一直说软件维护，那么什么是软件维护呢？其实就是修改错误、改善性能的过程。运维是软件开发中最困难的工作之一，他需要处理各种来自用户报告的问题与故障。

软件维护主要针对一下几种（数据来源未知2333）：

• 纠错性25%
• 适应性21%
• 完善性50%
• 预防性4%

“变化”在软件生命周期中是不可避免的！那么如何在最初的设计中充分考虑到未来的变化，避免因为频繁的变化导致软件复杂度增加和质量的下降呢？这就是我们这章要说的事情——提高软件的适应性，延续软件生命。注意软件维护不仅仅是运维工程师的工作，而是从设计和开发阶段就开始了。所以在设计开发的过程中就要考虑到将来的可维护性，使设计方案容易改变。

这张将会着重讲解几个基于可维护性建设的例子：

• 模块化
• OO设计原则
• OO设计模式
• 基于状态的构造技术
• 表驱动的构造技术
• 基于语法的构造技术

2.可维护性的度量

首先来说几个常用的可维护性度量指标：

• 圈复杂度（Cyclomatic Complexity）：度量代码的结构复杂度。
• 代码行数：……
• 可维护性指数（Maintainnbility Index）MI：计算0到100之间的索引值。表示维护代码的相对容易性，高价值意味着更好地可维护性。
• 继承的层次数（Depth of Inheritance）：就是继承深度，英文更通俗些。
• 类之间的耦合度（Class Coupling）：通过参数，局部变量，返回类型，方法调用，泛型或模板实例化，基类，接口实现，在外部类型上定义的字段和属性修饰来测量耦合到唯一类。
• 单元测试覆盖率（Unit test coverage）：只是代码库的那些部分被自动化单元测试覆盖。

3. 模块化设计和模块化原则

其设计目的只有两点：

• 模块内高内聚
• 模块间低耦合