Java 代码重构

要解决什么问题

业务代码往往「能跑但难改」：重复的空判断、深层 if/else、与项目里已有工具类不一致的写法，以及注释和日志各写各的。若在重构时顺手改行为或换依赖，很容易在调用链上埋回归。本技能面向的是在契约不变的前提下做结构化整理，而不是重写业务。

技能如何工作

执行顺序是固定的四步，每一步都有完成标准：

1. 先读懂再动手：阅读目标代码、调用方、测试和同模块实现，弄清输入输出、边界条件，并确认 StringUtils、Objects、MapUtils、CollectionUtils、fastjson 等在当前仓库里的实际用法。
2. 审慎引入设计模式：只在能明确消除重复、分支膨胀或职责混杂时引入，并沿用代码库已有模式；简单逻辑直接重构。
3. 最小范围改动：在原有结构内依次处理工具类复用、空值规范、卫语句、简单 Lambda/Stream、方法数量、代码布局、中文 JavaDoc/// 注释和日志格式。
4. 验证：运行与改动范围匹配的编译、静态检查和测试；无法执行时明确说明未验证项。

项目工具约定以表格形式约束常见场景（如 StringUtils.isBlank、CollectionUtils.isEmpty 等），要求先搜已有工具方法，通用逻辑才考虑补到已有工具类并补测试。

适用边界与注意点

• 不变量：对外方法签名、返回约定、事务边界、异常类型、执行顺序和可观察副作用默认不改，除非用户明确要求。
• Stream：仅用于简单映射/过滤/分组；复杂控制流、异常或有副作用的逻辑保留普通循环。
• 日志：消息格式为 {类名简版}-{方法名}-{中文备注}，且不记录敏感信息。
• 交付前有一份逐项检查清单（设计模式依据、工具类覆盖、注释与日志规范、验证结果等），避免「改完说不清验了什么」。