问题场景:
- 大型系统在开发过程中，团队数量膨胀，模块数量增加。当系统进入稳定状态后，人员缩减，需要对系统进行重构，系统规模和支持团队要匹配。需要对模块进行合并，合并的目标是降低沟通成本，做到应合尽合。
- 系统因为解耦，产生了分离的配置，模块间的依赖关系变成了用户的学习成本，阻碍产品发展。例如isto 1.5的重构就是在尝试解决这个问题。
两种问题场景的核心都需要解决系统模块合并的路径设计问题。
输入:
- 模块间存在依赖关系，方向上不应该发生改变
- 合并模块本身的大小需要受控，大小的定义可能是接口数，圈复杂度，或者行数，或者支持团队的人数。
方法:
映射到有向无环图的节点合并方案问题。通过约束寻找可以合并的节点对，计算每个节点对合并后，图的整体边数变化，选择节约最多边的节点对合并，生成新的图。持续迭代，寻找下一组可以合并的点对。
输出:
满足约束条件最简结构的图
其他的方法: 和聚类的区别，聚类一般难以给出分组数量，也难以施加一些限制条件，对于重构过程，我们需要采纳半监督监督的方式，进行过程仿真。
实例:
以一个10个模块的java系统迭代为例，首先通过gradle对工程中的子模块的依赖关系进行分析，通过shell对jar的大小进行统计，这里我们做个简化，将大小的约束函数定义为jar大小，设置为200K，大致对应1w行代码
-
先使用mermaid做个基本的绘图，由比较资深的架构师尝试手工合并，合并时采纳的原则是模块耦合度
image.png -
使用python的networkx进行合并计算，对比架构师合并完的产出
networkx计算合并结果
架构师人工合并结果
- 对比networkx和手工合并的结果，我们发现，两者近似度较高。当模块变成数十个，数百个之后，采用networkx计算的方式和经过专人数月阅读代码的产出结果类似。
总结:
系统重构的前提有两个，明确依赖关系，明确节点大小，这两个前提是图优化的约束。图优化的收敛目标是简化沟通关系，也就是对边数的改进。
