因此,为了满足以上考虑点,我们在指标选取的过程中采用了如下步骤:简单解读下上面的步骤。首先,通过头脑风暴的方式,让业务架构SIG中各个业务线的技术同学根据自身业务场景和系统现状,发散思维,提供自己认为的可以作为复杂度指标的维度,这要做的目的是充分保证指标的丰富性,为后面能够得到足够通用的模型打下基础。在通过头脑风暴得到足够丰富的信息之后,接下来将大家贡献出来的内容识别成一个个维度,识别的标准是可以独立定义并测量的指标。接着,将这些识别出来的维度进行筛选,过滤掉具体业务特性的,不合理的,高度近似的维度。经过筛选后的维度需要进行精简,因为我们认为,一个模型最好的状态是只有一个指标,如果能够找到全面且唯一的指标是我们这个模型的最优解,在精简的过程中,我们进一步得到了彼此独立、能够测量、和复杂度高度相关的一组正交维度。经过以上步骤,我们识别出了29个维度,经过筛选和精简最终我们得到了8个复杂度相关维度:这里需要为大家说明的是,在这8个维度中,有6个复杂度核心指标和2个辅助指标。辅助指标的意义在于,当我们衡量一个系统的复杂度是否合理时,需要结合辅助指标来判断合理性。比如,和业务重点方向(Epic)关联程度高的系统,对于复杂度的容忍上限就会高一些,同理,处于核心链路路径上的系统,具备相对高一些的复杂度也是合理的。确定维度之后,下一个问题是维度的量化。通过上面的维度表格可以看到,我们选取的复杂度指标的量纲和量级差异比较大,一个系统的代码行数可能会有几万或者十几万,但是依赖数量可能是百级别或者几十这样的级别。量纲和量级的差异会导致这些指标难以进行加和。因此,需要对这些指标进行归一映射,我们将这些指标按照一定的算法映射到了[0,10]的区间。同时,上文对于公式的描述中还提到了权重因子 weight k 的确认,根据维度含义和特性的不同,我们赋予了不同的权重。需要特别说明的一点是,由于我们的模型指标中包含有效代码行数和代码总行数,为了保证这两个指标能够在代码覆盖率提升的过程中是收敛并复杂度应处于下降趋势,我们又引入了代码覆盖率因子加入到权重中。建模到这一步,已经很接近得到最终模型了。但是,在此之前,我们还需要思考一个问题:所有应用都通过这个模型计算出来复杂度然后放到一起对比是合理的吗?会不会存在一些不在核心链路但是仍然很重要的系统比如一些配置类系统无法充分评估其复杂度?我们对这个问题思考的结论是: