refactoring - 什么算法可以分析库裂变的调用依赖关系？

Question

假设我有一个包含一堆相互依赖的函数的库，这个库太大了，我想把它拆分。有哪些算法可以找到合适的分区？

简单的例子，里面有四个函数:alpha，beta，gamma，delta。

beta 和 gamma 都称为 delta。

module1 调用 alpha 和 beta。

module2 调用 gamma。

module3 调用 alpha、beta 和 gamma。

算法的输出可能是:

LibA 包含 (alpha,beta)

LibB 包含 (gamma)

LibC 包含(增量)

module1 依赖于 LibA

module2 依赖于 LibB

module3 依赖于 LibA 和 LibB

LibA 依赖于 LibC

LibB 依赖于 LibC

即它找到具有以下属性的最细粒度的 Lib* 分区

For all X, if LibX is partitioned by any method into LibY and LibZ then all modules/libraries which depend on LibY also depend on LibZ and vice-versa.

有没有标准的解决方案？

Answer 1

(这与人们在 C 和 C++ 程序中的头文件中遇到的问题相同。)

创建依赖关系的不仅仅是“调用”；它是对成员变量、静态变量甚至常量定义的任何类型的引用。

基本上你需要做的是发现所有细粒度的依赖关系(这通常需要一个类似编译器的分析工具来读取代码并发现声明的语言元素之间的这种依赖关系(声明、字段、方法、类、包，如果你是以java为中心等)和其他语言元素。使用编写库的语言的语义。(这样的分析可能是保守的)。这是本质给你一个巨大的图，节点是语言元素，并且弧是“用途”。

摘要中的库打包问题是将这个图分成 block ，最小化跨 block 依赖弧。这可能会为您提供大量的小型库。

实际问题是将一些彼此没有实际依赖关系但通常一起使用的 block 组合在一起。例如，一组缓冲区访问过程可能对默认缓冲区大小的定义没有任何显式依赖，但您可能想要一个包含两者的库，而不是两个库，其中一个仅包含默认缓冲区大小声明。这种一起使用的概念实际上是一个有问题的域工件，并且在代码中的任何地方都不可见，除非可能有一些统计上的使用共现。

这个问题的难点在于发现细粒度的语义依赖。您可以手动估算此值，但如果问题有任何规模，您将没有兴趣去做。 (出于同样的原因，人们不会重新组织头文件)。您几乎需要语言工具来进行分析，大图管理来提出 block ，统计分析来获得启发式分组，并且可能需要一个 UI 来允许领域专家编辑分组以生成修改后的库。

然后，您需要一个工具来返回使用遗留库的代码，并修改它们以使用修改后的库。库重构和代码库修订都需要大量的代码分析和更改，这需要自动化。

我们的DMS Software Reengineering Toolkit有许多 language front ends可能是实现此类图书馆重组的良好基础。我们已经考虑为 C 和 C++ 执行此操作 [这就是我有此回复的原因]，但即使对我们来说，这也是一项艰巨的任务。我们想要一些严肃的额外动力!