开发过程架构分析的问题领域
高内聚，低耦合一直是软件架构追求的原则，也有很多设计模式实现了具体的方法。但复杂系统往往存在局部优化和全局优化的冲突，微服务架构的复杂性在这一点尤为突出，如何识别复杂系统组件之间的关系，进而确定系统整体优化的方向，这将是我们试图回答的第一个问题。
当团队规模超过百人，维护的服务数超过数十个，乃至数百个，系统架构往往存在设计到落地的失真，尽管有了ArchUnit这样的架构守护方法存在，系统实际的架构往往还是隐藏在层层迷雾之后，以各种迂回的方法响应业务的实现。于是这就产生了我们的第二个问题，如何从实现的角度反映真实的系统架构。
分析方法
软件系统的构建过程就是开发者的活动过程。架构作为关系集合， 在开发阶段可以映射为两类关系，开发者作为个体之间的沟通关系，组件（微服务）作为团队之间的沟通关系。从人类脑力活动能够承担的复杂度来看，上面的两类沟通关系与社交网络都存在着比较大的相似性。
基于这个假设，我们采集了一些大型项目中的代码仓库提交数据，采用社交网络的分析方法对项目架构进行建模。从分析的结果来看，模型的有效性基本可以得到验证，在项目架构的治理过程中也可以起到积极的指导作用。
模型设计
基础模型
开发者在不同子系统间的流动，所携带的隐性知识构成了系统的复杂度，也形成了子系统之间的关系。如果以子系统为节点，在不同子系统上同时工作的开发者就形成了项目间的连接关系。假设Dev1在P1，P2，P3项目上同时工作，我们可以构建出来一个关系网络。多个关系的叠加进而会形成子系统之间的网络，我们可以直接观察到一些网络的连通性
[图片上传中...(pasted image 0.png-83e4f7-1584253488017-0)]
如果我们以开发者为节点，以他们共同工作的项目为连接，这样就可以形成开发者视角的网络，开发者视角的网络图可以帮助我们有效识别团队的实际沟通路线，以及判断系统的核心关键角色.
网络分析
领域划分之社团结构
社交网络中，有的节点之间的连接较为紧密，有的节点之间的连接关系较为稀疏。其中连接较为紧密的部分可以被看成一个社区，其内部的节点之间有较为紧密的连接，而在两个社区间则相对连接较为稀疏。这个整体的结构被称为社团结构。
系统复杂度之Modularity
社团分析的量化指标是Modularity，反映了整个系统的复杂度，当Modularity变低时，系统复杂度增加，稳定性降低，图9是三个mod下的系统划分结果，虽然系统A的节点数和边数都超过系统B，C，但整体稳定性要由于B，C
时间对网络的影响
时间对架构的累计效应
项目关系网络中，考虑到开发人员的项目流动性，我们需要把活动数据按照时间窗口切分，以去除人员流动时产生的伪相关性。系统的复杂度是研发活动的累计值，因此在分析系统某个时间点的状态时，我们需要对历史数据进行回溯，把各时间窗口形成的网络进行累加计算。
开发者关系的时间属性
开发者关系网络一般是个短时间状态，随着项目变化，人员的联系也会减弱，在这种情况下我们不再对关系进行累计，只要观测网络的阶段状态即可
系统运行时的分析方法
上述模型是系统在开发阶段的分析方法，我们看到分析的核心在于对服务之间的关系进行建模，系统运行时的关系基本的方法可以从数据流入手，同时运行时关系还需要考虑数据的方向。
获取数据流的方法可以是系统日志分析，也可以是服务网格的采样数据。对于基于消息的系统，我们也可以通过对订阅发布的数据获取对应的关系。
