本文主要是介绍Architectural fitness function,架构你好我也好,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
写在前面
ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势)
一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。
今天是《雷达哔哔哔》的第二篇,依然关注架构,Blip是Architectural fitness function。
位置
2018年5月第18期技术雷达,技术象限,建议试验
目标受众:
系统架构师,技术管理者,开发人员
关注问题:
技术架构腐化带来系统响应度降低,可维护性下降,技术债缠身。而盲目优化或是单纯的技术驱动的架构优化又常常偏离初衷,容易造成过度优化,不但没有解决之前的问题,还会引入新的问题。那如何度量技术架构的好与坏?如何拿捏技术架构演进的度?如何用目标驱动的方式做技术架构的持续演进?如何衡量技术架构演进的成果?如何进行架构守护?
解决方案:
通过识别架构演进度量指标,编写Architectural fitness function(适应度函数),以此量化及可视化系统架构演进效果,并通过持续反馈不断调整技术架构演进方向,避免架构演进脱离初始目标。
解读:
Architectural fitness function(适应度函数)借鉴自进化计算,被用来衡量方案对满足目标的适合度。
当定义演进式算法时,算法设计者会寻求更优解,而适应度函数则定义了在此上下文中“更优”的含义。
将适应度函数应用于软件架构,则为系统的架构演进提供了一个度量的目标,开启了“【目标(测试)驱动架构演进】”的新时代。
记住,如果你无法为系统演进、架构升级优化定义出度量的Metrics,并通过Fitness Function写一个测试来驱动和可视化你的架构演进成果。那就表明你还没有想清楚架构演进要解决的问题,就先不要开始!
《演进式架构》一书定义了架构适应度函数的概念,为衡量架构特征提供了一个客观全面的方法,包括已有的验证标准,比如单元测试、业务指标、监控等等。
感兴趣的可以了解一下。
工具:
ArchUnit:一个可以测试Java系统架构本身的测试工具,例如所有的Service只能被Controller或是Service调用的测试如下:
延展阅读
- 演进式架构设计 - 图书 - 图灵社区
- 架构腐化之谜 - InfoQ
- 聊聊演进式架构 - 掘金
- 微服务即演进式架构 - ThoughtWorks洞见
- 微服务和演进式架构 - ThoughtWorks洞见
文/ThoughtWorks王健
更多精彩洞见,请关注微信公共号:思特沃克
这篇关于Architectural fitness function,架构你好我也好的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!