Spark Notes

Appearance

软件设计质量属性 ​

软件工程的本质是管理复杂性。随着数字系统规模的指数级增长，开发者面临的最大挑战不再是单纯的逻辑实现，而是如何确保代码在不断变化的需求中保持可维护性、可扩展性和可读性。

软件设计质量属性（Software Quality Attributes，又称 -ilities）并非教条式的规则，而是经过数十年工业实践总结出的启发式方法论。它们为架构决策提供科学导航，帮助开发团队规避隐性技术债务，防止代码腐化，并提升软件系统的整体生命周期价值。

在一个成功的软件系统中，维护成本往往占据总成本的 80% 以上。设计原则通过鼓励代码重用、促进模块间的松耦合以及增强代码的透明度，直接降低了后续维护和功能扩展的成本。

核心质量属性体系 ​

功能与性能 ​

属性定义关键指标/实践
正确性程序按照预期实现了所需要的需求需求设计、需求发掘
效率资源利用率（CPU/内存/网络/存储）利用率<70%、GC暂停、尾延迟
极限负载系统处理负载增长的能力（用户/数据/流量）QPS、吞吐量、水平/垂直扩展、分片
响应性端到端延迟（P50/P95/P99）<200ms UI、<50ms API、异步处理
易用性用户交互直观、学习曲线低NPS、任务完成率、A/B测试
国际化支持多语言/区域i18n、RTL、时区处理

代码质量 ​

属性定义关键指标/实践
可读性代码是否能够被快速读懂圈复杂度、命名、注释
可复用性代码能否被复用代码重复率、代码冗余

可用性与容错 ​

属性定义关键指标/实践
健壮性系统在异常输入或环境下持续运行的能力输入校验、熔断降级、错误处理边界测试
可靠性系统在规定条件下和时间内执行预期功能且无故障的概率MTBF、错误率、SLA达标率
可用性系统正常运行时间比例99.99%（"four 9s"）、MTBF/MTTR
恢复性从故障/崩溃中恢复速度RPO/RTO、快照回滚、蓝绿部署
安全性抵抗攻击、数据保护、可攻击面零信任、加密、RBAC、OWASP Top10

演进与变更 ​

属性定义关键指标/实践
可维护性修复缺陷、添加功能的难易程度可读性、圈复杂度、代码重复率、模块耦合度
可扩展性添加新功能而不改核心代码插件系统、接口隔离、事件驱动
可修改性修改现有功能成本低模块化、SOLID、ADR 记录
可移植性跨环境/平台迁移容易容器化、多云支持、标准协议

操作与部署 ​

属性定义关键指标/实践
可测试性代码易于验证和测试的程度单元测试覆盖率、依赖注入、接口抽象
可观测性通过外部输出推断系统内部状态的能力结构化日志、分布式链路追踪、指标监控
可部署性快速、安全部署CI/CD、GitOps、无缝升级
可配置性通过配置调整行为外部化配置、环境变量、Feature Flags
互操作性与外部系统集成API 标准（gRPC/REST）、Schema 演进

按生命周期阶段划分 ​

质量属性也可以按照软件生命周期的不同阶段来划分，这种划分有助于理解不同阶段各方的关注点和责任。

阶段主要关注点典型质量属性（-ilities）
开发内部结构、可修改性、可读性、可测试基础可维护性、可修改性、可测试性、可重用性、可移植性、可扩展性、可读性、模块化、架构一致性
测试正确性、缺陷发现效率、验证覆盖度可测试性、可靠性、正确性、健壮性、可观测性
运维运行稳定性、故障恢复、监控效率可用性、可靠性、可观测性、可伸缩性、容错性、恢复性、安全性、性能效率、可部署性

度量工具

阶段典型度量方式 / 实践
开发代码审查、SonarQube静态分析、架构决策记录（ADR）、单元测试覆盖率、认知复杂度、耦合/内聚度
测试测试覆盖率（代码/分支/路径）、缺陷密度、缺陷泄漏率、自动化测试通过率、MTTR（缺陷修复时间）
运维SLO/SLI、错误预算、MTBF/MTTR、P99延迟、变更失败率、告警准确率、Chaos工程覆盖

开发阶段的质量是质量保证的根基 ​

缺陷在开发阶段修复成本最低，越往后（测试→上线→生产）成本呈指数增长（业界常见估算：1:10:100甚至更高）。

架构是否分层清晰、是否遵守 SOLID/DDD/整洁架构，直接决定可测试性和可维护性。如果开发阶段就把副作用到处散布、状态到处共享，后续测试几乎不可能写出确定性强的用例，运维也无法快速定位。

可观测性、可测试性等运维阶段关心的属性，必须在开发阶段就设计好。开发阶段的坏决策会让每一次需求变更都变成大手术，测试和运维只能被动救火。

  • 架构选错 → 测试难写、改一处动全局、运维频繁出故障
  • 开发阶段缺乏可测试设计 → 测试用例爆炸、mock困难、 flaky 测试多
  • 开发阶段忽略可观测性 → 故障定位慢、根因难找、反复重启、用户体验差

Shift-left 策略 ​

把质量把控前移到开发阶段：

  • 开发阶段就要写单元测试、契约测试、架构健身函数
  • 可观测性优先设计：OpenTelemetry、结构化日志、trace 从开发阶段就内置
  • 架构决策显式化：用 ADR 记录每个重要权衡
  • 内建质量：CI 包含 lint、静态分析、架构违规检查、测试覆盖门限

以下 C 代码示例体现了多属性设计思想：

c
// 模块化设计：可维护+可测试（接口隔离），容错（错误码）
typedef struct {
    int (*init)(void *cfg);         // 可配置
    int (*process)(void *data);     // 纯函数倾向，易测试
    void (*cleanup)(void);
} ModuleOps;

int reliable_module(const ModuleOps *ops, void *cfg) {
    if (!ops || !ops->init) return -EINVAL;  // 健壮性
    int ret = ops->init(cfg);
    if (ret) return ret;                     // 恢复性
    // 核心逻辑：不可变输入，日志副作用隔离
    ret = ops->process(cfg);
    ops->cleanup();
    return ret ? -ret : 0;                   // 一致错误处理，可观测
}

这个设计覆盖了 SRP（单一接口）、DIP（ops 抽象）、Fault Tolerance（检查+回滚）等多个原则。

多角色视角的设计 ​

生命周期的划分正好对应了不同流程上负责不同任务的人。不同的人之间分工合作，但是也需要密切配合。

  • 开发人员视角：对开发人员来说，最好的设计是不言自明。KISS 原则在这里发挥重要作用，复杂的抽象层、过度的设计模式都会增加理解成本。最小惊讶原则要求代码的行为应该和它的名字完全一致。比如一个 getName() 方法绝对不应该在后台偷偷修改数据库。接口设计要符合直觉，如果一个功能需要跳转多层代码才能找到核心逻辑，那就是过度设计。

  • 测试人员视角：测试人员最怕的是黑盒和逻辑耦合。依赖注入与解耦是解决之道：代码里到处是 new 出来的对象或单例，导致无法进行 Mock 测试。确定性也很重要，尽量减少代码对系统时间、随机数或外部状态的隐式依赖。一个不可测试的函数，其设计往往存在问题。

  • 运维人员视角：对运维来说，代码只是在服务器上跑的进程。坏了怎么办？如何快速定位问题？可观测性设计要求在设计时就考虑结构化日志、链路追踪和健康检查接口。报错只抛出一个 Internal Server Error 而没有任何上下文，是运维人员的噩梦。防御式设计要求引入超时、限流和熔断。运维人员希望系统在压力过大时能优雅降级，而不是直接雪崩。

为了平衡开发、测试、运维三个视角，现代软件设计引入了一些交叉领域的概念。契约测试明确 API 的输入输出规范，开发不用猜接口，测试有据可依。功能开关通过配置决定代码是否生效，运维可以随时关闭出问题的模块，开发可以小步快跑上线。12-Factor App 是一套云原生应用的设计准则（如配置与代码分离），极大降低了运维在不同环境下部署的难度。

权衡框架 ​

质量属性之间经常存在冲突，需要进行权衡。

常见冲突 ​

高优先 → 低优先冲突示例缓解策略
可用性增加冗余 → 效率下降自动缩放 + 监控
可伸缩性分库分表 → 可维护性变差CDC + 物化视图
安全性加密/校验 → 性能下降硬件加速 + 零拷贝
可测试性依赖注入 → 部署复杂容器 mock + 契约测试

ISO/IEC 25010 标准 ​

ISO 25010 将质量属性分为产品质量（功能性、性能、兼容性、安全性等）和使用质量（可用性、效率等）。这为系统性地评估和权衡质量属性提供了标准框架。