重构不是重写，而是在不改变外部行为的前提下，让代码更容易理解和维护。以下是实际工作中验证有效的建议：
8.3.1 何时动手重构
- "三次法则"：第一次写能跑就行，第二次复制粘贴也能接受，第三次遇到类似逻辑，必须提取公共方法
- 修Bug前：如果看代码看了10分钟还没看懂逻辑，先重构再修复
- 代码审查后：把Review意见当场改掉，不要留"下次再改"的债
8.3.2 让代码易读的五分钟改造
// 优化前
if (user.getStatus() == 1 && user.getType() == 2 && user.getLoginTime() > 86400) {
// ...
}
// 优化后：用意图解释代码
boolean isVipExpired = user.isVip() && user.isInactiveFor(Period.ofDays(1));
if (isVipExpired) {
// ...
}- 命名即注释：变量名说明"为什么存在"而非"是什么类型"（用
pendingOrders而非orderList） - 魔法数字变常量：把
if (status == 3)改成if (status == ORDER_SHIPPED) - 早返回：把深嵌套的if-else改成卫语句，减少缩进层级
8.3.3 函数瘦身技巧
- 参数对象化：超过3个参数就封装成对象，避免调用时搞错顺序
- 拆分副作用：把"计算+保存+发通知"的大函数拆成三个纯函数，中间用事件驱动或事务脚本串联
- 一行代码一个抽象层级：高层业务逻辑和低层数据操作不要混在同一个函数里
8.3.4 性能优化务实策略
不要做的事：
- 不要为了"可能"的百万级并发，提前引入复杂的缓存层和消息队列
- 不要用
StringBuilder拼接5个以内的字符串（现代编译器会自动优化）
优先做的事：
- 数据库层面：给WHERE条件字段加索引，解决N+1查询（一次查出关联数据比循环查100次快100倍）
- 算法层面：List查找改用HashMap/Set，时间复杂度从O(n)降到O(1)
- I/O层面：日志打印用异步appender，上传文件走流式处理而非一次性读进内存
8.3.5 安全重构 checklist
- 先补测试：没有单元测试的重构是裸奔，至少保证核心路径有集成测试覆盖
- 小步提交：每改完一个函数就运行测试，通过就commit，别攒一个巨大的PR
- 灰度验证：重构后先让10%流量跑新版本，监控错误率和响应时间
8.3.6 停止过度设计
- 不到20个类不要强行拆分微服务
- 没有重复代码就不要抽象基类
- 简单的CRUD别硬套DDD（领域驱动设计），贫血模型在业务简单时反而是最合适的
核心原则：代码是写给人看的，顺便给机器执行。能让新同事第二天就看懂的代码，就是好代码。