Paula Paul 和 Rosemary Wang 撰写的一篇博文中介绍了适应度函数（fitness function）的基本概念、入门方法，并给出了如何验证各种架构质量的一些实例。文中提出，适应度函数驱动开发的方法可用于编写测定系统符合架构目标的测试，这类似于使用测试驱动开发（TDO）的方法验证功能是否符合所需的业务输出。
Paul 和 Wang 均供职于 Thoughtworks 。文中强调指出，架构标准完全独立于功能需求，它是随着目标和限制条件的更改而持续演进的。作者们引用了《构建演进架构》（“Building Evolutionary Architecture”）一书中的说法：
从多个维度上看，演进架构的首要原则是支持受控的增量更改。
Paul 和 Wang 认为，对于支持这样的架构演进，适应度函数有助于自动确定系统在多大程度上符合特定的架构目标和限制条件。举个例子，打日志的方法通常是事后诸葛亮，并缺少一些重要的信息。如果引入适应度函数功能，可确保日志具有良好的结构化，并包含足够的有用信息。
对于使用适应度函数的时机，作者们给出的建议是首先收集所有利益相关者的意见，了解在他们看来最为重要的架构功能。之后对这些功能区分为通用主题组，比如弹性、安全性、可操作性和稳定性等。有时，在分组时会暴露出一些相互冲突的目标。例如，稳定性和敏捷性这二者的目标通常是截然相反的。稳定性是通过建立对更改的控制而实现的，而敏捷性是通过减少实现更改的障碍而实现的。为了解决目标冲突的问题，必须对各项功能的动机加以评估，对组织最为重要的功能应优先处理。
在描述所有适应度函数的意图时，应使用对团队和利益相关者有意义的客观度量。度量有助于团队测定技术债务，同时也避免架构偏移。所有的适应度函数都应在测试框架中制定，并添加到适当的交付流水线中。这样，所有新的软件都需要通过适应度函数的测试。Paul 和 Wang 将此视为持续集成的一种自然延伸。
文中给出了一个针对代码质量的适应度函数示例。该例测定了可修改性、可管理性和适应性，以防止将质量过低的代码部署到生产环境中。
describe "Code Quality" do it "has test coverage above 90%" do expect(quality.get_test_coverage()).to > .9 end it "has maintainability rating of .1 or higher (B)" do expect(quality.get_maintainability_rating()).to < .1 end end
文中还给出了一个针对性能的示例。Paul 和 Wang 指出，由单独团队完成的常规做法会延迟交付时间，并且结果并非总是提供给开发人员的。而将自动化性能测试实现为适应度函数并添加到构建流水线中的做法，可以尽早地运行测试，并且也可以立即看到结果。
除了上述两个示例，作者们还在文中针对弹性、可观测性、符合度、安全和可操作性给出了示例。
Paul 和 Wang 最后强调，架构（例如业务功能）可通过适应度函数的方式在代码中予以表达。他们在文中提出，使用适应度函数具有三方面的优势：
- 适应度函数客观地衡量了技术债务，并提高了代码的质量。一旦由于新的安全性或操作标准等原因而发生更改时，适应度函数还可提供实时反馈。
- 适应度函数可提供编码选择的信息，包括与下游进程相关的接口、事件和 API 的选择。在应用“绞杀者模式”（strangler pattern）时，适应度函数可用于验证业务逻辑解耦过程是否满足要求。
- 适应度函数支持以代码形式表达架构标准，从而有助于开发人员交付更加符合架构的功能。使用同一方式，用户可以请求更改功能，架构师可以请求更改某些架构问题，这些都可以在构建过程中加以验证。
在一篇博文中，Ben Morris 强调了使用适应度函数而非实际度量的重要性。在 Morris 看来，适应度函数为更具迭代性的架构提供了基础，并可引导持续演进的设计朝着理想的结果发展。
Vijini Mallawaarachchi 介绍了适应度函数的一般需求 ( https://towardsdatascience.com/how-to-define-a-fitness-function-in-a-genetic-algorithm-be572b9ea3b4 )，以及如何针对特定问题给出适应度函数。
Tim Sommer 撰文指出，适应度函数可用于为各种架构特性添加约束条件，进而引导架构的演进方向。
查看英文原文： Fitness Functions to Ensure Architectural Goals Are Met
评论