企业官网建设流程全解析

078、代码重构工程：大规模重命名的精确策略、回滚保障与风险控制

上周五晚上十一点，我盯着终端里那一串红色的“Module not found”报错，后背发凉。起因很简单——我想把项目里所有UserService重命名为MemberService，用了IDE的全局重命名，结果CI流水线炸了三个小时。不是IDE不好，是我低估了跨模块、跨语言、跨仓库的命名依赖有多深。那次事故之后，我花了整整两周重构了整个重命名流程，今天把这些血泪教训写下来。

重命名不是“查找替换”那么简单

很多人觉得重命名就是sed -i 's/old/new/g'，然后跑一遍测试。天真了。真实项目里，一个类名可能出现在：

• 反射调用的字符串常量里（Class.forName("com.xxx.UserService")）
• 配置文件中的bean名称（<bean/>）
• 数据库迁移脚本里的存储过程名
• 前端接口文档里的字段映射
• 甚至日志采集系统的正则表达式

我见过最离谱的：一个同事把OrderService重命名为TradeService，结果没改logback.xml里的日志文件名配置，日志采集系统三天没收到该服务的日志，线上问