HIT 软件构造 软件维护 设计原则

什么是软件维护

修复错误、改善性能

软件维护需要注意的问题

测试所做的修改
进行回归测试
记录变化
除了修复问题，修改过程中不能引入新的故障
软件维护不仅仅是运维工程师的工作，在软件开发阶段就要考虑了

可维护性的指标

圈复杂度：程序中不同代码路径的数量（这个数字越大，维护起来就越难）
代码行数：程序的代码的行数（如果一个类的代码行数太多，可能意味着这段代码做了太多的工作，他需要被分割）
继承深度：字面意思（这个数字越大就意味着越难找到在哪里定义的方法和变量）
类之间的耦合度：字面意思（通过类之间的参数、局部变量、返回类型、方法调用等衡量耦合度）（好的软件应该是高内聚、低耦合的，耦合度太高的话表示模块之间的练习非常紧密，维护起来难度比较大）
单元测试的覆盖度：字面意思（越高越好）

计算可维护性指数

halstead volume（HV）
cyclomatic complexity（CC）
模块的代码平均长度（LOC）
每个模块的注释占有率（COM）

面向可维护性的软件构造（设计原则）

模块设计和模块化原则

简述：
模块化编程是一种设计技术，它强调将程序的功能分离成独立的、可互换的模块，这样每个模块都包含执行所需功能的一个方面所需的所有内容。
功能相似的要放在一起，实现分离关注点，实现高内聚
使用小、简单、明确的接口，将信息隐藏，实现低耦合
原则：
直接映射（direct mapping）模块的结构与现实世界中问题领域的结构保持一致，它影响了可持续性和可分解性
尽可能少的接口（few interfaces）它影响了可持续性、保护性、可理解性、可组合性
尽可能小的接口（small interfaces）它影响了可持续性和保护性
显式接口（explicit interface）当两个模块通讯时，应明显的发生在模块的接口之间，它影响了可理解性、可组合性、可持续性、可分解性
信息隐藏（information hiding）经常发生变化的部分应该隐藏在接口后面

评估模块性的指标

可分解性（decomposability）使模块之间的依赖关系显式化和最小化
可组合性（composability）使模块可在不同的环境下复用
可理解性（understandability）
可持续性（continuity）发生变化时受影响范围最小
出现异常之后的保护（protection）出现异常之后受影响范围最小

面向对象设计原则–SOLID

简述：五个类的设计原则（SOLID）

单一责任原则（The Single Responsibility Principle）

不应该有多于1个的原因使得一个类发生变化
一个类一个责任
举个例子，在一个类中同时实现了后台操作和GUI操作，就不合适

开放/封闭原则（open/closed principle）

对扩展是开放的
对修改是封闭的（通常使用继承的方法实现修改）

liscov替换原则（The Liskov Substitution Principle）

子类型必须能够替换其基类型
派生类必须能够通过其基类型的接口使用，客户端无需了解二者之间的差异

接口隔离原则（interfaace segregation principle）

客户端不应一爱与它们不需要的方法
拒绝胖接口

依赖转置原则（dependency inversion principle）

抽象的模块不应依赖于具体的模块
具体应依赖于抽象

面向对象设计原则–GRASP

简述：
如何为“类”和“对象”指派“职责”的一系列原则
[这里我们没讲]
附上源CMU COURSE AND WIKIPEDIA

什么是软件演化

对软件进行持续的更新
欢迎关注公众号BBIT
让我们共同学习共同进步！