上帝类使单元测试失效，因其含大量静态方法、硬编码依赖、混杂IO/业务/日志逻辑，导致无法mock，测试变成集成冒烟；违反单一职责原则，变更动因多样却集中一处；应按变更频率而非功能名重构，优先拆高频修改区，并用PMD/pylint自动检测。
上帝类会让单元测试几乎失效
因为 GodClass 通常包含大量静态方法、直接依赖具体实现（如硬编码的 MongoDB 连接）、混杂 IO/业务/日志逻辑，导致无法注入 mock 对象。你写一个 test_compare()，结果发现它实际会去读磁盘、连数据库、打日志——这不是测试，是集成冒烟。
常见错误现象：TypeError: cannot patch '<module>.CommonUtils.loadDcmByPath'</module>，或测试运行时抛出 FileNotFoundError / ConnectionRefusedError。
- 静态方法无法被 patch：Python 的
unittest.mock.patch对模块级函数或类方法有效，但对@staticmethod或未绑定的普通函数 patch 效果差 - 职责混杂导致测试边界模糊：你本想测“比较逻辑”，却被迫处理文件路径合法性、DCM 解析失败、Mongo 写入超时等无关分支
- 修复一个 bug 要改 5 个测试用例：因为所有逻辑耦合在同一个类里，修改一处，多个测试断言连锁失效
上帝类天然违反单一职责原则（SRP）
SRP 不是教条，而是对“变化原因”的诚实判断。当产品提需求说“把日志从控制台改成 Sentry”，或“DCM 加载要支持新压缩格式”，或“订单对比结果要存到 Elasticsearch”——这些是完全不同的变化动因，却都落在同一个 CommonUtils 类上。
典型表现：CommonUtils 文件超过 800 行，同时定义了 getAllFiles、loadDcmByPath、compare、saveToMongo、log_error 等方法，每个方法背后是不同团队、不同发布节奏、不同稳定性要求。
立即学习“Python免费学习笔记（深入）”；
- 修改
compare()时不敢动log_error()的参数签名，怕影响其他 20 个调用点 - 新增一个
exportAsJson()方法，结果发现它和已有saveToMongo()共享了同一套数据转换逻辑，但又不能复用——因为那部分逻辑被写死在 if 分支里 - 新人接手第一周，90% 时间花在理解“这个类到底该不该改”而不是“怎么改”
重构上帝类最有效的切分方式不是按功能名，而是按变更频率
别一上来就建 FileService、DcmLoader、DcmComparer ——先看哪些代码块最近三个月被改过 5 次以上，哪些一次没动过。高频修改区优先拆，低频区可暂缓。
例如，compare() 和 compareReferDcm() 高度相似且每周都在调参，而 deleteFiles() 自上线后从未改动。这时应优先提取出 DcmComparer，把重复逻辑收口；deleteFiles() 可暂时保留，甚至标记为 @deprecated 观察。
- 拆分后接口要窄：比如
DcmComparer.compare(old: DcmModel, new: DcmModel) -> CompareResult，不暴露路径、不碰文件系统、不写日志 - 依赖要显式注入：避免
DcmComparer内部 newMongoClient，而是通过构造函数接收ResultRepository实例 - 门面模式（Facade）只用于对外兼容：旧代码仍可调
CommonUtils.compare(...)，但内部已委托给新模块，为后续彻底下线留余地
用 PMD 或 pylint 检测上帝类比靠经验更可靠
人工 review 容易漏掉“温和型上帝类”——比如只有 400 行、12 个方法，但其中 7 个方法都调用了 os.path、json.load、logging.info 和同一个全局配置字典。这类类不会立刻崩，但半年后你就会发现它像藤蔓一样缠住整个项目。
推荐直接用规则集扫描：pmd -d src/ -R rulesets/java/design.xml -f text，重点关注 GodClass、TooManyFields、CyclomaticComplexity 这三条规则输出。
-
GodClass规则会综合字段数、方法数、圈复杂度、外部依赖数量打分，比单纯看行数靠谱得多 - 注意 false positive：某些工具链生成的 DTO 类（如 Pydantic Model）字段多但无逻辑，可加
// NOPMD注释豁免 - 别等 CI 报警才行动：把
pmd或pylint --enable=too-many-instance-attributes,too-many-public-methods加进 pre-commit hook，让问题卡在本地
Utils 类，其实已经成了系统里最危险的债务。它不报错，但它让每次新增需求都变得更慢、更不确定、更不敢提交。 
