SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场code-modularization-evaluator

code-modularization-evaluator

编程与开发

查看项目

更新于 10-15 12:10

技能介绍

用途

Code Modularization Evaluator 用于评估代码的模块化程度，并给出改进建议。它基于 Vlad Khononov 在《Balancing Coupling in Software Design》中提出的平衡耦合模型（Balanced Coupling Model），帮助识别有问题的耦合模式，并提供可操作的重构指导。

其核心原则是：耦合本身并非坏事，设计不当的耦合才是问题。目标是实现平衡耦合，而不是零耦合。

基本公式为：

MODULARITY = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY

即当高集成强度的组件彼此靠近（同一模块/服务），低集成强度的组件可以相距较远（不同服务），以及低易变性组件能够容忍耦合不匹配时，系统即达到模块化。

主要能力

该技能从三个维度评估耦合：

  1. 集成强度（共享了什么知识？） 从强到弱依次为：
  • 侵入式（Intrusive）：使用非公开接口，例如直接访问另一服务的数据库、通过反射访问私有字段。
  • 功能式（Functional）：共享业务逻辑/规则，例如同一校验逻辑在两处重复、依赖顺序的操作。
  • 模型式（Model）：共享领域模型，例如两个服务使用完全相同的实体定义。
  • 契约式（Contract）：仅使用显式接口，例如设计良好的 API、DTO、协议。

  1. 距离（知识传播了多远？） 从近到远依次为：同一类中的方法、同一文件中的类、同一命名空间/包中的类、不同命名空间中的模块、独立服务/微服务、不同团队拥有的服务、不同系统/组织。

  2. 易变性（变更频率如何？） 使用领域驱动设计（DDD）的子域分类：

  • 核心子域：高易变性（竞争优势，频繁变更）
  • 支撑子域：低易变性（必要但不具差异化）
  • 通用子域：低易变性（已解决的问题，稳定）

决策框架矩阵：

  • 高集成强度 + 高距离 → 复杂性（分布式单体）
  • 低集成强度 + 低距离 → 复杂性（不必要的抽象）
  • 高集成强度 + 低距离 → 模块化（相关事物放在一起）
  • 低集成强度 + 高距离 → 模块化（独立组件分开） 例外：如果易变性低，耦合不匹配是可以接受的。

该技能还使用 Connascence（共变）分析来识别具体耦合类型。静态共变（编译期，较易修复）从弱到强包括：名称（CoN）、类型（CoT）、含义（CoM）、位置（CoP）、算法（CoA）。动态共变（运行期，较难检测）从弱到强包括：执行（CoE）、时机（CoTm）、值（CoV）、身份（CoI）。

共变规则：最小化整体共变；最小化跨模块边界的共变；最大化模块边界内的共变；将较强共变转换为较弱形式；随着距离增加，共变应减弱。

使用方式

该技能以评估工作流的方式使用。当被要求评估代码模块化时，按以下步骤进行：

  1. 映射组件结构：识别模块、服务、类，绘制依赖图。
  2. 评估集成强度：对每个依赖分类为侵入式/功能式/模型式/契约式，标记高强度的跨边界依赖。
  3. 测量距离：记录组件位置（同一文件到不同系统），识别团队/所有权边界。
  4. 评估易变性：对每个组件进行子域分类，记录历史上频繁变更的区域。
  5. 应用公式：检查强度与距离是否匹配，易变性是否可解释不匹配。
  6. 识别共变：扫描具体共变类型，优先处理高强度 + 低局部性 + 高程度的项。
  7. 推荐行动：按影响和成本排序，提供具体重构技术。

输出格式包括：模块化评估摘要、组件图、耦合分析表（组件对、强度、距离、易变性、平衡状态）、共变问题列表、按优先级排列的建议、重构计划。

评估清单包括：

  • 红旗（需立即处理）：直接访问另一服务数据的数据库（侵入式耦合）、通过反射访问私有字段、业务逻辑跨服务重复、微服务需要同步部署、类的 CBO（对象间耦合）> 14、频繁变更模块的不稳定指数在 0.3-0.7、模块间循环依赖。
  • 警告信号（需进一步调查）：组件间共享魔法数字/值（CoM）、API 中依赖位置的参数（CoP）、算法逻辑在多处重复（CoA）、方法必须按特定顺序调用（CoE）、长方法链 a.b().c().d()（违反迪米特法则）、承担过多职责的 Manager/Helper/Utility 类。
  • 健康模式：服务间基于契约的集成、真正抽象内部模型的 DTO、模块内高内聚、每个类单一职责、外部依赖使用依赖注入。

重构策略按问题类型提供：

  • 按集成强度：侵入式→契约式（识别直接依赖、定义显式接口、创建适配层、通过适配层路由访问）；功能式→模型式（提取共享业务逻辑到专用模块、定义清晰所有权、通过显式依赖消费）；模型式→契约式（创建集成专用 DTO、在边界映射内部模型与 DTO、独立于模型版本化契约）。
  • 按共变类型：CoM→CoN（用命名常量/枚举替换魔法值）；CoP→CoN（使用命名参数、建造者模式或参数对象）；CoA→CoN（提取算法到单一位置，按名称引用）；CoT→CoN（使用鸭子类型或接口）；CoE→显式（使用状态机、建造者模式或构造器注入）；CoI→显式（使用依赖注入并显式装配）。
  • 按距离问题：高集成强度 + 高距离（分布式单体）可选方案 A 减少距离（合并服务/模块）或方案 B 降低强度（引入契约、异步消息）；低集成强度 + 低距离（过度抽象）可移除不必要的抽象层、内联过于通用的代码、合并紧密相关的类。

适用场景

适用于代码审查、架构评审、重构规划等场景，尤其适合评估微服务架构中的耦合问题、识别分布式单体、发现过度抽象或循环依赖，以及为团队提供具体的重构路径。

限制

  • 无法在没有执行上下文的情况下评估运行时行为。
  • 易变性评估需要领域知识。
  • 团队/组织距离需要项目上下文。
  • 仅靠静态分析无法获得历史变更频率。