《演进式架构》通篇只讲了一件事：构建可评估架构的重要性。
稍具规模的产品往往都是由不同团队协作完成的，团队之间会划分职责和关键需求，由关键需求定义架构的关键指标，不可避免的产生了团队之间目标不一致的事实。
在团队编制下，各个团队通常都会针对眼前的任务优化效率，而不是针对那些更抽象的战略业务目标（特别是有工期压力时），这会导致各团队往往专注于交付各自的组件，而不关注端到端的特性价值，导致这些组件可能无法高效协作。
为此可以：
- 让团队结构与架构目标保持一致
- 给架构一个统一的评估标准
《演进式架构》提出了一个叫“适应度函数”的概念，从本质上讲它不是一个新概念，它最大的价值是将那些已有的各种指标做了一个统一的归类，如：
- 静态分析产生的 issues 数
- 自动化测试通过率
- 服务调用的中位数
- 冗余的语句
- 冗余的图片/资源
- 不规范的库用法
- 代码的圈复杂度
- …
这些通通归类到适应度函数这个概念中，从而让团队对架构目标有一个清晰的评估标准。
适应度函数除了有“评分”的作用，还有“对话”的作用。
我们知道架构的关键指标是由关键需求决定的，是基于性能、可靠性、安全性、可操作性和可维护性等维度权衡的结果，对于破坏架构目标的行为，我们通过适应度函数可以与架构进行严谨且明确的对话，并做出各种关键的权衡，如“提高阈值”还是“适应需求”。
听起来适应度函数也可以叫“健康度函数”，以架构为输入，函数进行验证后得出一个评分。
最后提一个该书的缺点。
这本书适合有一定设计经验、并希望构建一套明确评估体系的开发者，对初学者而言，该书用大量的篇幅描述了我们认为这样会更好，却没有给出任何示例，这必然导致在实践适应度函数时会遇到很多问题，而且不能解决最核心的诉求：如何改善架构。相比之下，像《代码大全》、《重构》、《架构整洁之道》等书既介绍了架构设计的细节，又充分给出了原因，适用人群更广，为读者带来的价值更大。