
28
|
第
3
章
设计持续交付的架构
从头开始设计和建造一个用途明确的房子要容易得多,设计和构建软件也是一样的。
架构不好的另一个隐性成本是,你不得不花费大量时间来修补系统,而没有时间创新。
如果你的时间都像“打地鼠”一样用来解决各种软件
bug
,而不是开发新的功能,那么
你肯定知道架构是有问题的。良好的软件架构会降低
bug
出现的可能,并且降低
bug
带
来的负面后果,这样的系统会把错误“包裹”起来,并且能够通过架构所提供的机制,
用最小的成本来解决任何问题。良好的架构也更加鼓励创新,因为它更清楚需要如何来
支持创新,架构本身也可以成为创新的催化剂,让你看到隐藏在表面之下的机会。
尽管从某种程度上讲,对架构质量的持续监控和分析,直接影响持续交付的水平,但
是构建管道可以成为一种收集相关指标的有效方式。你可以在构建过程中加入像
SonarQube
之类的工具,用来显示代码的内聚性、耦合性和复杂性,还可以使用高级的
复杂性指标报告,例如圈复杂度(检查程序源代码中依赖路径的数量)和设计结构质量
指数(
DSQI
,一种用于评估计算机程序设计结构和模块效率的架构设计指标)。
其他工具,例如
Adam Tornhill
的
Code Maat
,也可以通过对版本控制系统的数据挖掘和
分析,显示被频繁调用的代码库。这可以向企业证明,花费时间和金钱来改进架构,有
助于理解代码中频繁调用的复杂逻辑,并且反过来能得到更高的投资回报。
复杂性和变更成本
成熟的、遗留的架构一般都会由多种技术组成,主要基于当时流行的框架和相关工程师
的经验。这就是架构中缺乏结构(或者结构过于复杂)会对组织产生很大影响的地方 ...