2020.04.24软件构造听课笔记

软件维护：修复错误、改善性能

运维是软件开发中最困难的工作之一，涉及到其他所有环节
处理来自用户报告的故障/问题

阿里运维工程师职责：
负责系统稳定性工作；
生产系统部署、上线；
维护生产系统网络安全、稳定、可靠；
维护生产系统数据备份

岗位要求：
深入理解运维体系结构，精于容量规划、架构设计、性能优化；
熟悉服务管理、单元部署、自动扩容等运维系统建设，对成本控制和效能提升有深刻的理解和实践；
熟悉故障、监控、限流、降级、预案、扩容工作原理；
熟悉java虚拟机，对java应用的部署及系统优化有一定的经验；
熟悉自动化发布工具、熟悉docker技术优先

更多的步骤：
测试所做的修改
回归测试
记录变化

除了修复问题，修改中不能引入新的故障
最大的问题：修改有没有足够的文档记录和测试

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

软件演化：对软件进行持续的更新
软件的大部分成本来自于维护阶段

软件维护不仅仅是运维工程师的工作，而是从设计和开发阶段就开始了
在设计与开发阶段就要考虑将来的可维护性
设计方案的“easy to change”

可维护性、可扩展性、灵活性、可适应性、可管理性、支持性

判断程序的可维护性：
圈/环复杂度：独立路径的数量
代码行数
继承的层次数
类之间的耦合度
单元测试的覆盖度

模块化编程：高内聚、低耦合、分离关注点、信息隐藏

评价软件的模块化是否好的：
可分解性、可组合性、可理解性、可持续性、出现异常之后的保护

将问题分解为各个可独立解决的子问题
目标：是模块之间的依赖关系显示化和最小化

可容易的将模块组合起来形成新的系统
目标：是模块可以在不同的环境下复用

每个子模块都可以被系统设计者容易的理解

规格说明小的变化将只影响一小部分模块，而不会影响整个体系结构

运行时的不正常将局限于小范围的模块内

模块化设计的五个规则：直接映射、尽可能少的接口、尽可能小的接口、显式接口、信息隐藏
直接映射：模块的结构与现实世界中问题领域的结构保持一致
模块应该尽可能少的与其他模块通讯
如果两个模块通讯，那么他们应交换尽可能少的信息
当A与B通讯时，应明显的发生在A与B接口之间
经常可能发生变化的设计决策应尽可能隐藏在抽象接口后面

OO的SOLID原则：
SRP：单一责任原则
OCP：开放-封闭原则
LSP：Liskov替换原则
DIP：依赖转置原则
ISP：接口聚合原则

单一责任原则：ADT中不应该有多于1个原因让其发生变化，否则就拆分开
开放-封闭原则：模块的行为应该是可扩展的，从而该模块可表现出新的行为以满足需求的变化
Liskov替换原则：子类型必须能够替换其基类型；派生类必须能够通过基类的接口使用，客户端无需了解二者之间的差异
接口隔离原则：不能强迫客户端依赖于他们不需要的接口：只提供必需的接口
依赖转置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于实现细节，实现细节应该依赖于抽象

 

OO的GRASP原则：
Controller
Information expert
Creator
Low coupling
High cohesion
Indirection
Polymorphism
Protected variations
Pure fabrication