2.9 KiB
2.9 KiB
代码审查报告
文件: data\demo-pmd\src\com\demo\design\extra\LoosePackageCouplingDemo.java
语言: java
耗时: 142.8s
分析工具: pmd
总计: 6 | 错误: 0 | 警告: 5 | 建议: 1
静态分析 · 3 个问题
- 🟡
pmd:AtLeastOneConstructorL12 每个类应至少声明一个构造函数。 建议: 请为 LoosePackageCouplingDemo 类显式添加构造函数，例如添加一个包私有构造函数：LoosePackageCouplingDemo() { /* 显式默认构造 */ }；若类为工具类，可改为 private。 - 🟡
pmd:CommentDefaultAccessModifierL13 方法“bad()”缺少注释默认访问修饰符。 建议: 在方法声明前注释默认访问级别，例如：/* default */ void bad() { ... }；或显式使用 private（仅内部使用）或 public（对外 API），避免隐式包私有。 - 🟡
pmd:LocalVariableCouldBeFinalL14 局部变量“svc”应声明为 final。 建议: 将声明改为 final ApiService svc = new ApiService();，明确该引用初始化后不再发生变化。
AI 审查 · 3 条建议
- 🟡 [AI] [design]
dead-codeL13 bad() 方法在当前包中从未被调用，属于死代码 整个文件中没有其他代码调用 bad()，且 bad() 为包私有方法，当前同包其他类也未使用，说明该方法可能是未完成的演示残留或调用入口缺失。死代码会增加维护面积，并掩盖真实的业务行为。 建议: 若该方法无业务入口，应删除；若需要保留作为演示，可添加一个 main 方法或单元测试入口，并让方法名表达实际用途。 - 🟡 [AI] [design]
package-couplingL14 extra 包直接依赖 api 包的具体实现，导致包间强耦合 LoosePackageCouplingDemo 位于 com.demo.design.extra 包，却直接 import 并 new 了 com.demo.api.ApiService。这样将 extra 包的实现与 api 包的具体类型绑定在一起，未来 ApiService 的构造函数或生命周期变化会波及此处；若存在多个类似调用点，重构成本更高。代码注释也表明这是 LoosePackageCoupling 规则的演示，但规则未被配置执行，因此该耦合在质量门禁中不会暴露。 建议: 为 extra 包引入抽象接口（例如 ApiClient），只依赖接口完成调用，并通过构造函数注入 ApiService（或由工厂提供），避免在业务代码中直接 new 具体类；同时将 LoosePackageCoupling 规则在 PMD ruleset 中配置 packages/classes 后启用，以持续检查包耦合。 - 🔵 [AI] [style]
unclear-method-nameL13 方法名 bad() 无法表达方法职责 bad() 是一个无意义的命名，读者无法从名称中得知该方法执行何种具体操作。良好的方法名应以动词开头体现行为，例如 doWork、sendRequest 等。 建议: 将 bad() 重命名为具有业务含义的动词短语；如果只是示例，建议改为 demoApiCall() 等更贴近用途的名字。