1.软件维护和变化
软件维护:修复错误,改善性能。
变化在软件生命周期内是不可避免的,因为在最初的设计中为充分考虑到未来的变化,应避免因为频繁变化导致软件复杂度的增加和质量的下滑。
软件维护不仅仅是运维工程师的工作,而是从设计和开发阶段就开始了,在设计与开发阶段就要考虑将来的可维护性。
2.可维护性的常见度量指标
圈复杂度:度量代码的结构复杂度。
代码行数:指示代码中的大致行数。
HalsteadVolume:基于源代码中(不同)运算符和操作数的数量的合成度量
可维护性指数(MI):计算一个值介于0到100之间,表示维护代码的相对容易性。高价值意味着更好的可维护性。 它的计算基于:
HalsteadVolume(HV);
圈复杂性(CC);
每个模块的平均代码行数(LOC);
每个模块注释行的百分(COM)。
3.模块化编程
设计的目标是将系统划分为模块,并通过以下方式在组件之间分配责任:
模块内部高内聚;模块间低耦合
模块化降低了程序员必须在任何时候处理的总体复杂度,假设:
将功能分配给远离的模块,将相似的功能组合在一起(分离关注点);
模块之间存在小的,简单的,明确定义的接口(信息隐藏)。
内聚和耦合的原则可能是评估设计可维护性的最重要的设计原则。
4.耦合(coupling)和聚合(cohesion)
耦合是模块之间依赖关系的度量。如果两个模块之间的变化可能需要另一个模块的变更,则两个模块之间存在依赖关系。
模块之间的耦合程度取决于模块之间的接口数量和每个接口的复杂性。
聚合是衡量一个模块的功能或责任有多强烈程度的一个指标。如果模
块的所有元素都朝着相同的目标努力,则模块具有高度的聚合。
5.SOLID
The Single Responsibility Principle(SRP) 单一责任原则:不应有多于1个的原因使得一个类发生变化,一个类应该仅仅有一个责任,如果多余一个责任,那么会引起不良后果,如占据资源、导致频繁的重新配置。
![](https://i-blog.csdnimg.cn/blog_migrate/fef6e7b0eeecb1e3f7a87c84864cb26d.png)
The Open-Closed Principle (OCP) 开放-封闭原则:对扩展性开放,模块的行为是可扩展的,从而该模块可以表现出新的行为以满足需求的变化;对修改的封闭,模块自身的代码不应被修改,扩展模块的行为一般是修改模块的内部实现,如果一个模块不能被修改,那么它通常被认为有固定的行为。
![](https://i-blog.csdnimg.cn/blog_migrate/36fbd197b566e74039ca8b3e53afc97f.png)
TheLiskov Substitution Principle (LSP) Liskov替换原则:子类型必须能够替换其基类型,派生类必须能通过基类的接口使用,客户端无需了解二者的差异。
TheDependency Inversion Principle (DIP) 依赖转置原则:客户端不应依赖于它们不需要的方法,“胖”接口不够聚合,需要分解为多个小的接口,不同的接口向不同的客户端提供服务,客户端只访问自己需要的接口。
The Interface Segregation Principle (ISP) 接口聚合原则:抽象的模块不应依赖于具体模块应该让具体依赖于抽象。
![](https://i-blog.csdnimg.cn/blog_migrate/6e26b5ae7f378970e1aaa29b43f8ab9c.png)