自动化依赖分析
依赖分析之后，你的架构还好吗？
在过去的几周里，我一直在做一些重构相关的工作，也尝试着去做这方面的自动化。于是乎，就有了上一篇文章：《重构的自动化》。在这个过程中，有一个环节能反应出架构是否有良好的设计，那就是依赖。
依赖的类型
对于一个系统来说，它存在下述的一些依赖类型：
- 类、包依赖
- 第三方依赖
- 服务间依赖
按《架构金字塔》一文所说，它们各属于不同层级。设定好它们间的组织方式，决定了整个系统架构的良好性。
- 类、包依赖。通过职责来聚合服务，单一化类的职责。
- 第三方依赖。通过 Adapter 模式封装三方依赖，隔离外部依赖的变化；还可以通过 Facde 模式来简化 API 的调用。
- 服务间依赖。类似于第三方依赖，只是在接口统一不变时，是 Proxy 模式
在架构的维度里，我们通过 MVC 架构、Clean Architecture 等不同的方式，进行分层架构的设计，以通过明确地职责划分、隔离关注点，来降低系统的维护成本。如果水平维度不能解决问题，那么就采用水平 + 垂直化的方式来解决。在依赖维度里，我们通过度量来观察设计的合理性。
类包依赖：依赖关系可视化
对于类和包的依赖来说，一个有效的解决方案是：对于依赖关系的可视化。如下图（由 tequila + graphviz 生成）：
在图中，我们可以看出类间的依赖关系，从而进一步分析他们的引用问题。虽然，对于采用分层架构的应用来说，这样的问题并不容易出现。但是，我们仍在一定的范围内，看到了 service 间的相互调用。
于是，在参考了公司大佬的开源依赖分析项目：
- 基于 Antlr 进行 Java 依赖分析 https://github.com/XuefengWu/dependence_java
- 基于 Doxygen 进行多种语言的依赖分析 https://github.com/newlee/tequila
随之而后，我便也着手做了一个相关的 Java 依赖分析工具：https://github.com/phodal/coca 。当然在那之前，我已经有了一个 TypeScript 的版本：https://github.com/phodal/dilay ，只不过目的不一样，我的初衷是用于做架构守护。
对于这样的一个工具说，我们所要作的事情也不复杂：
- 编写特定语言的抽象语法树（AST）和 parser
- 构建出每个类包含的所有声明，生成对应的映射
- 识别出依赖相关的 method、type、class、constant 的使用
- 生成对应的调用关系
- 可视化调用关系
一旦出现服务间的双向/循环引用，我们需要着力于关注如何去掉这种错误的引用。去掉的方式有多种多样，诸如于：合并包/服务、提取共用部分。
第三方：包大小可视化
包大小，在出现性能或者网络问题之前，并不会成为我们关注的焦点。可一旦包的大小超过了预期，我们开始分析其中的原因。可视化，依然是解决这一类问题的最有效方式。
对于诸如 JavaScript/TypeScript 这一类的静态语言来说，它们引用包的方式与其它语言有很大的差距。前端领域的引用方式，多数以源码的方式，而诸如 Java 则是以 jar 包的方式。于是，前端应用在构建的时候，前端可以通过摇树优化来减少包大小。但是哪怕如此，一定数量的软件包只能引用全部的代码，这种模式通常出现在前端 UI 库中，如 Ant Design。
对于这些问题来说，前端有一个解决方案：webpack-bundle-analyzer，它可以直接可视化软件包的大小：'
'
当然了，对于后端来说，这也不是问题。只是对于我来说，我仍然在考虑是否有必要去做这样的事。不过呢，如果你引用了一个自己内部的软件包，那么我们有必要写一个软件来做这样的优化：
- 构建时识别软件引用的类与方法
- 依赖识别的类，将软件包不需要的部分自动去除
- 重新打包依赖软件包
- 构建整个应用
O 了。
服务间：API 规范化与服务间依赖
不过，这个故事还涉及到一个 API 规范化的问题。所以在那之前，我们需要：
- 通过扫描代码来寻找对外暴露的 API。生成对应的 API 与参数关系列表
有了这个基本的的结果后，判定每个 API 的设计是否合理。与此同时，我们还可以：*通过调用关系，找到 API 对应的数据库表，生成相应的 Schema。*
随后，再：
- 扫描调用的 API。生成调用服务的关系图
- 分析服务调用关系，及其调用是否合理。
它可以固定作为我们测试的一部分。
第三方依赖：依赖功能分析
TBD
这部分的内容，主要指的是依赖间的功能重复，如各类 Util，像 FileUtils，TimeUtils 诸如此类。'
结论
你呢，有什么建议？