告别祖传代码：后端重构的正确姿势

职场有句名言："这不是bug，这是feature。"代码也有句名言："这套代码跑了好几年，谁敢动？"祖传代码之所以成为祖传，往往不是因为它写得好，而是因为没人敢碰。碰了就是雷，炸了就得背锅。于是代码越来越烂，业务越来越难改，程序员越来越累。

今天不聊玄学，聊点实际的：怎么科学地重构后端代码，让它从"谁碰谁死"变成"可持续维护"。

重构的第一件事：不是改代码

很多人重构的第一步是打开IDE开干。千万别。你激动地改了两天，发现这个函数被那个模块调用，那个模块又被另一个系统引用，改一个小地方炸出一堆问题，然后心态崩了。

重构的第一步是画地图。你需要搞清楚几件事：

• 这段代码的核心业务流程是什么
• 有哪些入口点，哪些出口点
• 依赖关系是什么样的（别笑，很多人真不清楚自己负责的模块依赖谁）
• 有哪些测试，能覆盖多少场景

画地图的工具很多：时序图、流程图、依赖分析。不要觉得这是在浪费时间，这是给自己买保险。你以为重构省下的时间，最后都会还给bug。

识别技术债：不是所有问题都值得马上修

代码烂，不代表所有地方都要立刻重构。你得先识别哪些是真正的技术债，哪些只是"看起来不顺眼但其实能用"。

我见过最极端的案例：一个处理订单的类，里面几千行代码，各种嵌套if-else。团队决定重写，结果重写完之后发现业务逻辑变了，原来的代码反而是对的。新代码用了一个月发现bug，根源就是重构的时候理解错了业务逻辑。

重构前先问自己三个问题：

• 这段代码最近会不会改？如果三年都不会动，重构它就是浪费时间
• 这段代码出过生产bug吗？没出过问题的烂代码，可以先苟着
• 重构的风险和收益比是多少？如果收益不大，何必冒险

技术债是要还的，但不是现在马上就还。要有策略，有优先级。

小步前进：不要试图一口吃成胖子

正确的重构姿势是：每次只改一个小功能，跑通测试，确保没问题，再改下一个。听起来很简单对吧？但实际执行的时候，大部分人会想："既然都打开这个文件了，顺便把旁边那个也改了吧。"然后一步小心，改出三个bug。

有个概念叫"童子军规则"：每次离开的时候，让代码比来的时候更干净。这话听起来很美好，但实际操作中很容易变成"既然我都重构这个函数了，顺便把旁边那个也重构了"。然后你的重构范围从一个小函数变成整个模块，从"半小时能搞定"变成"需要测试一整天"。

我的经验是：一次重构只做一件事。如果是要重构异常处理，就只重构异常处理，不要顺手把变量命名也改了。那是两次重构。

测试先行：没有测试的重构是在走钢丝

这是最重要的一条，但也是被违反最多的一条。很多人说："这段代码没有测试，我不敢重构，怕改坏。"然后呢？不改了？代码继续烂下去？

正确做法是：先写测试，再重构。如果没有测试，那就先补测试。不用担心测试写得不完美，先有个基础覆盖，然后重构的过程中不断完善。

有人会说："这个模块逻辑太复杂，测试根本没法写。"恰恰相反，这正是需要重构的理由。难以测试的代码通常就是难以维护的代码。

测试的另一个价值是：给你信心。没有测试的重构，改完心里没底，不知道哪里会爆雷。有测试的重构，改完跑一遍，全绿，心里踏实。

// 重构前：不知道测哪里
function processOrder(order) {
  // 300行的订单处理逻辑
}

// 重构后：职责单一，可测试
function validateOrder(order) { /* 验证逻辑 */ }
function calculateDiscount(order) { /* 折扣计算 */ }
function createOrderRecord(order) { /* 记录创建 */ }

// 现在你可以针对性地写测试
describe("calculateDiscount", () => {
  it("should apply member discount correctly", () => { ... })
})

善用设计模式，但别被模式绑架

说到重构，很多人第一反应是："我要用设计模式！"然后把一个简单的订单处理类改成工厂模式+策略模式+装饰器模式，原本100行能解决的问题，现在需要1000行，五个类。

这就是另一个极端：过度设计。设计模式是手段，不是目的。它的存在是为了让代码更好维护，不是为了证明你学过设计模式。

什么时候该用模式？当你遇到重复的场景，发现现有代码在硬凑解决方案的时候，再考虑引入合适的模式。如果一个简单的if-else能解决问题，就别上策略模式。

有个简单的判断标准：你引入一个模式，增加的复杂度能不能被它带来的好处抵消？如果不能，就别用。

数据库重构：最危险的部分

后端重构最难的部分是什么？不是代码，是数据库。代码改错了可以回滚，数据库迁移做砸了，数据丢了，哭都来不及。

数据库重构的正确姿势：

• 永远不要删除列：先停止使用，等两个版本周期确认没有引用，再删除。列可以标记为deprecated，物理删除留到最后
• 索引变更要谨慎：添加索引相对安全，删除索引先在测试环境验证性能影响
• 大表DDL要使用pt-online-schema-change或类似工具：直接ALTER TABLE会锁表，生产环境可能直接炸
• 迁移脚本要双向兼容：新代码能读旧数据，旧代码也能读新数据，灰度发布的时候不翻车

有个团队曾经在凌晨两点执行了一条ALTER TABLE，结果那个表有5000万数据，MySQL直接卡死，监控告警瞬间爆了。值班的兄弟差点连夜买机票跑路。

让重构可持续：技术债务管理

重构最怕什么？最怕的是"这次重构完了，下次什么时候再来一轮？"。很多团队的重构是一阵一阵的：憋不住了，重构一次，然后继续烂，憋不住了再来一次。

健康的模式是：把技术债务管理纳入日常工作。

具体做法：每个季度做一次技术债务盘点，列出top 10的技术债，分配owner，设定deadline。把技术债务当作和产品需求一样重要的工作，而不是"有空再做"的事情。

另一个有效做法：在写新功能的时候，顺便把相关的历史债务还了。比如你负责的模块有个烂函数，本来三年没人动，现在产品要加个新需求，你就借着这个机会把函数重构了。成本低，效果好。

重构的心态：不是为了炫技

最后说点心态上的东西。

重构不是为了向团队证明"看我多厉害，能写出这么优雅的代码"。重构是为了让未来的自己和其他同事少踩坑，更高效地工作。

所以重构有一个很重要的原则：不要追求完美，追求可维护。代码只要满足：逻辑清晰、没有明显的性能问题、能被正确测试，就可以了。别为了"这个变量名是不是应该更优雅"纠结三天。

另外，重构的时候尽量让其他人知道你在做什么。如果你偷偷重构了一个模块，结果产品验收的时候发现行为变了，会非常麻烦。提前沟通，重构完了做code review，透明的流程能减少很多不必要的麻烦。

总结

重构这事儿，说白了就是"让代码持续保持健康"的能力。但很多人把它当成一次性的大工程，结果要么烂尾，要么翻车。

记住几个关键点：

• 重构前先画地图，不要冲动动手
• 识别真正的技术债，不是什么都要立刻改
• 小步前进，一次只做一件事
• 测试先行，没有测试的重构是走钢丝
• 设计模式是工具，不是炫技的手段
• 数据库重构要格外谨慎，那是炸弹
• 技术债务要常态化治理，不是一阵风

祖传代码不是不能碰，是要碰得聪明。学会科学地重构，让代码从"谁碰谁死"变成"谁都能改"，这是后端工程师成长的必经之路。

毕竟，代码是写给人看的，顺眼的代码才能让人安心改，安心改才能持续迭代。你的代码值得被好好对待，从今天开始，别再让祖传代码继续烂下去了。