一、重构入门：什么是重构、为什么需要重构、重构与重写的区别、重构的时机与原则

1.1 什么是重构？—— 不是改bug，是改代码的“内功”

先问大家一个问题：你改过那种“看一眼就想吐”的代码吗？

函数上千行，变量名全是 a、b、c，一个 if 嵌套七八层。你只是想加个小功能，结果改了三天，还引入三个新 bug。

嗯，这种代码，就需要重构。

重构的定义很简单：在不改变代码外部行为的前提下，改善其内部结构。

说白了，就是功能不变，但代码变得更好读、更好改、更好测。我个人的理解是——重构是给代码“做体检”，不是“做手术”。

我在项目中遇到过最典型的例子：一个处理网络报文的函数，足足 800 行。里面混杂了解包、校验、业务逻辑、日志打印。我花了三天，把它拆成 12 个小函数。结果呢？后来加新协议类型，只改了 2 个函数，测试覆盖率从 30% 升到 85%。这就是重构的力量。

1.2 为什么需要重构？—— 代码的“技术债务”会利滚利

你想想看，一个项目刚开始的时候，代码多清爽。但三个月后呢？需求变更、紧急修复、临时方案……代码就像一间没人收拾的房间，越来越乱。

这就是“技术债务”。

重构，就是还债。不还债的后果是什么？

不重构的后果	具体表现
开发效率暴跌	改一行代码，要读十行上下文
bug 率飙升	没人能说清楚这段代码到底在干嘛
新人上手困难	“这代码谁写的？”——“去年离职的那个”
架构腐化	模块间耦合越来越紧，牵一发动全身

我个人习惯是：每次改代码时，顺手做一点重构。比如改一个函数，顺便把它的变量名改清楚；加一个功能，顺便把相关的 if-else 改成多态。这叫“童子军规则”——离开时比来时更干净。

1.3 重构 vs 重写 —— 一字之差，天壤之别

很多新手分不清重构和重写。我见过一个团队，把“重构”挂在嘴边，结果干的是“重写”的活——推倒重来，全部重写。

这两者的区别，我用一个表格说清楚：

维度	重构	重写
改动范围	局部、小步	全局、推倒
风险等级	低（可随时回退）	高（可能长期不可用）
业务影响	无（功能不变）	有（需要重新验证）
时间成本	几天到几周	几周到几个月
适用场景	代码混乱但逻辑正确	架构彻底失效、技术栈过时

为什么我强调这个区别？因为重写是“核武器”，不能随便用。我见过一个创业公司，CTO 一拍脑袋说“代码太烂了，重写吧”。结果重写了半年，市场机会全丢了，公司也黄了。

记住：重构是手术刀，重写是截肢。能用手术刀解决的问题，别动刀。

1.4 重构的时机 —— 什么时候该动手？

这个问题，我经常被问到。答案是：不要等“专门的时间”去重构，重构应该融入日常开发。

具体来说，以下几个信号出现时，就是重构的好时机：

• 添加新功能时：如果现有代码让你很难下手，先重构再开发
• 修复 bug 时：如果 bug 的根源是代码结构混乱，顺手重构
• 代码审查时：发现坏味道（如过长函数、重复代码），立即重构
• 理解代码时：读不懂的地方，改清楚变量名、拆函数，边读边重构

1.5 重构的原则 —— 三条铁律

我做了十几年 C++ 重构，总结出三条铁律，分享给大家：

1. 小步提交，频繁测试：每次改动后，编译 + 跑测试。改一行，测一次。别攒一堆再测，那叫“赌博”。
2. 保持行为不变：重构不改变接口、不改变功能、不改变性能特征。如果改了，那就不是重构，是“重写”。
3. 先有测试，再重构：没有测试覆盖的代码，重构就是盲人摸象。先写测试，把行为“锁定”住，再动手。

举个例子，我重构一个 C++ 类时，会这样做：

// 重构前：一个函数干了三件事
void process(Data& d) {
    // 1. 校验
    if (d.isValid()) { /* ... */ }
    // 2. 转换
    d.transform();
    // 3. 存储
    save(d);
}

// 重构后：拆成三个函数，各司其职
bool validate(const Data& d);
Data transform(const Data& d);
void save(const Data& d);

void process(Data& d) {
    if (!validate(d)) return;
    auto transformed = transform(d);
    save(transformed);
}

你看，功能完全一样，但代码清晰多了。每个函数都可以单独测试，单独修改。

1.6 本章知识体系图

下面这张图，帮你理清本章的核心脉络：

这张图把本章的核心内容串起来了。从“什么是重构”出发，到“为什么需要”，再到“和重写的区别”，最后落到“时机与原则”。你每次看这张图，都应该能回忆起本章的要点。