质量是所有人都关心的事

团队的组织架构决定了团队的分工模式，也间接决定了从属不同团队的组件所采用的架构，如果我们在系统立项之初，就构建与目标系统相仿的团队结构，无疑会使项目更容易实现。如果现实并非如此呢？由于人们很难改变其职责范围外的事情，所以软件架构师需要时刻关注团队的分工模式，从而使架构目标和团队结构保持一致。

质量（无论是代码质量还是交付质量）是所有人都关心的事，纵然如此，质量怎么衡量？不同团队考察的维度不同，不限于性能、可靠性、安全性、可操作性和可维护性，而且各个团队通常都会针对眼前的任务优化效率（特别是有工期压力时），这会导致各团队往往专注于交付各自的组件，而不关注端到端的特性价值，导致产出的组件之间可能无法高效协作。

这里面有两个问题需要解决：

质量的可评估性
团队之间的差异

可评估架构

为了能更客观的度量架构，我们想用第三方视角来看待它，于是我们开始考虑将可评估性也作为架构设计的考虑维度之一，以此在不同的设计模式之间、代码规范之间评估它的静态指标，并在自动化测试、服务调用里评估它的动态指标。这些指标包括但不限于：

静态分析产生的 issues 数
自动化测试通过率
服务调用的中位数
冗余的语句
冗余的图片/资源
不规范的库用法
代码的圈复杂度
…

我们采纳了《演进式架构》里提出的一个叫适应度函数的概念，从本质上讲它不是一个新概念，它最大的价值是将那些已有的各种指标术语做了一个统一，将上述那些通通归类到适应度函数这个概念里，从而让团队对架构目标有一个清晰、一致的评估标准。

共建

我们想让大家都参与到质量保障工作上来，并支持大家根据不同的维度实现自己的适应度函数，最终应用到所有的项目中去。

为了实现这一点，我们设计了一个简单的插件系统，插件由 main.py 和 requirements.txt 组成，后者负责申明依赖，前者负责执行函数逻辑：

基于 Python 技术栈，生态丰富，学习成本低。

将不同的指标包装成适应度函数并上传至我们的管理平台：

并在基础设施中建立一个分析流去执行各种函数：

基于 requirements.txt 创建和重用环境，使各函数的执行隔离在不同的物理环境中。

防劣化

无论是代码质量还是交付质量，没有数据（监控）和防劣化的策略，是无法保障的，适应度函数除了有“评分”的作用，还有“对话”的作用。

我们知道架构的关键指标是由关键需求决定的，是基于性能、可靠性、安全性、可操作性和可维护性等维度权衡的结果，对于破坏架构目标的行为，我们通过适应度函数可以与架构进行严谨且明确的对话，并做出各种关键的权衡，如“提高阈值”还是“适应需求”。

听起来适应度函数也可以叫“健康度函数”，以架构为输入，计算后得出一个健康值。

总结

这其实还是一个很基础的可评估工作流，先有一个能跑起来的简单模型，再通过这个模型和架构对话，根据数据做关键权衡（如“提高阈值”还是“适应需求”），而为了能让所有人参与进来，我们构建了一个管理平台去支持自定义的度量指标，以实现架构共建。