接到一个老模块的维护任务时我翻到一个叫parseAndUpdate的函数600 行、八层 if 嵌套、try/catch 丢在末尾吞异常读文件、查数据库、拼报文全在这一个函数里。那一刻我脑子里飘过四个字代码重构。但第一反应其实是“能跑就别动”。后来这个念头让我花了一周去查一个数据漏更新的 bug——逻辑藏得太深肉眼根本找不到。从此我的顺序变了先重构再改需求。这篇内容适合两类人一类是刚把 C 语法摸熟、写出的代码自己都觉得难看的入门者另一类是天天维护存量 C 项目、面对长函数和全局单例下不去手的老兵。下面说的这些技巧都是我实际在项目里反复用过的不是教科书上的“最佳实践”是可以直接照着改的。1. 重构的前提判断先分清哪些代码值得动、哪些绝对别碰很多人一上来就讨论具体技巧但重构最大的坑其实发生在动手之前。判断错误轻则浪费时间重则把稳定模块改出一堆新 bug。我见过太多“重构完代码变好看了、功能却悄悄变了”的事故所以在聊手法之前先把判断标准聊透。1.1 坏味道不是审美问题是成本问题代码坏味道看着像审美问题实际上全是维护成本问题。只有当坏味道开始拖慢你改需求的速度、让你每次修改都心惊胆战的时候它才值得处理。我在项目里最常遇到也最优先处理的坏味道基本是下面这几类坏味道典型表现为什么危险过长函数一个函数超过 100 行干了好几件事定位问题靠滚动逻辑分支组合爆炸深嵌套if/else 超过三层循环套循环任何一个分支都可能漏处理裸指针满天飞new 出来的对象到处传靠约定决定谁 delete任何提前 return 都可能泄漏全局单例耦合函数里到处都是XXX::instance()测试没法隔离依赖方向不可见重复代码同一段解析逻辑被复制到五处改一处漏一处数据不一致IO 与逻辑混合网络、文件、数据库调用散落在业务逻辑里没法 mock没法单测这些坏味道不是“看着不舒服”而是每一处都在增加下一次改动的出错概率。判断要不要重构看的是它有没有开始向你收“利息”。1.2 三个问题判断重构值不值遇到一个不顺眼的模块我会先问自己三个问题第一这个模块接下来还会不会改如果它是三年前写死、明年可能整体替换掉的边缘功能重构就是纯成本。重构的价值不体现在当下而体现在未来的每一次改动上没有后续需求的代码不值得动。第二有没有测试能兜底没有测试的模块重构等于在没有安全网的情况下走钢丝。你要么先补测试要么接受“重构成功能变更”的风险。第三改动范围能控制在一天以内吗重构最怕时间长、范围大。一个模块改到第三天你已经分不清哪些是重构、哪些是修 bug、哪些是新需求。这三个问题里只要有一个回答不乐观我就倾向于再等等。1.3 这些场景请把手从键盘上拿开有些代码天生不适合重构属于“看着难受但别动”的类型。比如算法练习代码。像冒泡排序、快速幂、单调栈、前缀和这类短小算法核心价值在逻辑本身不在结构。你硬要拆成三个类反而把简单问题复杂化。再比如一次性脚本。写出来为了跑完拉倒跑完就扔进垃圾桶的代码重构就是给垃圾做美容。还有即将重写的模块。如果你已经知道下个季度要用新架构整体替换现在花时间重构旧代码是双重浪费。我知道有人会说“旧代码还要撑到下个季度”但这时候更该做的是给关键路径补测试而不是重构结构。判断清楚了再往下谈手法才有意义。2. 函数级重构拆嵌套、提函数用 STL 替换手写循环函数是 C 重构最直接的单元。改动小、见效快、风险相对可控也是普通团队最应该先练手的地方。这里我挑三个高频场景展开。2.1 提取函数与卫语句一次击穿三层嵌套先看一段典型代码这种函数我在无数项目里见过bool parseAndUpdate(const std::string path) { std::ifstream in(path); std::string line; while (std::getline(in, line)) { if (line.size() 2) { auto tokens split(line); if (tokens.size() 3) { double value std::stod(tokens[2]); if (value 0) { if (!updateDb(tokens[0], tokens[1], value)) { return false; } } } } } return true; }问题不在“能不能跑”而在“修改时能不能看明白”。外面加一层需求检查你得数半天括号才知道它套在哪个 if 里。重构思路分两层第一层把不需要继续处理的路径提前 return第二层把每一件独立的事提成函数并让函数名说清楚它干什么bool parseAndUpdate(const std::string path) { std::ifstream in(path); if (!in) { return false; } for (std::string line; std::getline(in, line);) { if (!processLine(line)) { return false; } } return true; } bool processLine(const std::string line) { if (line.size() 2) { return true; } auto tokens split(line); if (tokens.size() ! 3) { return true; } double value std::stod(tokens[2]); if (value 0) { return true; } return updateDb(tokens[0], tokens[1], value); }改动后的行为保持一致但每一层都变平了。processLine只看一行数据parseAndUpdate只管打开文件和逐行迭代未来加字段校验只需要往processLine里加一个判断。这里有个我踩过的坑重构时顺手“修复”了原代码里的所有问题比如std::stod没有异常处理、没有检查文件是否成功打开。这是一个非常危险的冲动。重构的第一原则是行为不变你要修 bug 或加异常处理请放到另一个提交里否则你根本不知道行为变化是重构引入的还是修 bug 引入的。2.2 STL 算法替换手写循环让意图而不是下标说话C 的 STL 不只是容器算法库同样是重构利器。很多时候手写 for 循环在“做什么”这件事上是模糊的得把循环体读完才能猜出来。一个很常见的场景从一批订单里筛出状态有效且金额超过阈值的记录。std::vectorOrder result; for (size_t i 0; i orders.size(); i) { if (orders[i].status OrderStatus::kValid orders[i].amount limit) { result.push_back(orders[i]); } }用std::copy_if重写之后意图一目了然std::vectorOrder result; std::copy_if(orders.begin(), orders.end(), std::back_inserter(result), [limit](const Order order) { return order.status OrderStatus::kValid order.amount limit; });焦点从“遍历过程”转移到了“筛选条件”上这远比少写几行循环更有价值。类似的还有std::transform逐元素映射、std::accumulate求累计结果、std::find_if按条件查位置都很适合替换手写循环。但我要泼一盆冷水STL 算法不是万能钥匙。当循环体内有依赖前一次迭代结果的复杂状态时——比如实现多次递推、维护窗口时——硬套算法会让代码更难读。这种时候保留传统的 for 循环是合理选择甚至循环内就算嵌套了条件只要逻辑能直线读下来就不该为了“用算法”而用算法。2.3 字符串和容器初始化的几个顺手改法字符串处理是 C 项目里最大的重复代码来源。我见过大量接口把const std::string传来传去其实内部只读不写。改成std::string_view能避免临时拷贝尤其是在解析场景bool startsWithSlash(const std::string name) { return !name.empty() name.front() /; } // 改为 bool startsWithSlash(std::string_view name) { return !name.empty() name.front() /; }调用方如果传的是字符串字面量、const char*、std::string都能隐式构造std::string_view不用拷贝。这个改动收益取决于实际调用频率字符串越大、调用越频繁收益越明显。容器初始化也有两个细节值得改。第一能预知大小时用reservestd::vectorstd::string names; names.reserve(input.size()); for (const auto item : input) { names.emplace_back(item.name); }第二向容器里放字符串时用emplace_back而不是push_back。push_back(abc)会先构造一个临时std::string再移动进去emplace_back(abc)直接在容器内构造少一次临时对象。不要小看这种微操在高频路径上积少成多。3. 所有权与生命周期重构把内存账本交给规则而不是靠人肉记住C 和别的语言最大的不同在于资源所有权得靠人维护。裸指针时代所有人都在祈祷“记得 delete”而重构的核心就是把这个祈祷变成编译期规则。3.1 先把裸指针改成 unique_ptr所有权清晰是第一优先级看一段很典型的失败代码auto obj new Product(); if (!init(obj)) { return false; // 泄漏 obj } if (!check(obj)) { delete obj; return false; } use(obj); delete obj;每个return都要想着释放资源少写一个就泄漏。这种代码我在实际项目里改过太多做法就一步——换成std::unique_ptrauto obj std::make_uniqueProduct(); if (!init(obj)) { return false; // 自动释放 } if (!check(obj)) { return false; // 自动释放 } use(obj); // 正常路径自动释放unique_ptr在栈展开时会自动析构不管从哪条路径退出资源都会被回收。这里我想强调一个常被忽略的点不要第一个想到shared_ptr。shared_ptr的引用计数是有原子操作成本的更重要的是它会掩盖所有权归属问题让代码变成一团浆糊。绝大多数场景下独占所有权unique_ptr就够用了。3.2 值、引用、指针、移动参数传递的身位选择C 里参数传递方式的选择本身就是重构的重要内容。同一个函数参数从裸指针改成引用调用方的代码和职责都会发生明显变化。我习惯按这个表格来判断传递方式适用场景按值传递小对象int、Point、std::pair或函数确实需要本地副本const T只读访问大对象如std::string、std::vectorT接收临时对象并转移资源T*裸指针允许为空、表示借用关系且不转移所有权std::unique_ptrT转移独占所有权std::shared_ptrT多个持有者共同决定生命周期实际项目里最常见的错误是把只读大对象用裸指针或按值传递。后者会产生不必要的拷贝前者让“谁拥有”变得模糊。改成const std::string或std::string_view之后大部分场景都能在不动调用方的情况下完成。移动语义也顺便说一句std::move不是万灵丹。现代编译器普遍有返回值优化RVO函数返回局部对象时直接按值返回通常就是最优解不需要到处move。有时候我看到同事把代码写成了return std::move(obj)反而关掉了返回值优化这是反优化。3.3 RAII从锁和文件句柄到数据库 stmt 封装RAII资源获取即初始化是 C 最值钱的思想。锁和文件用std::lock_guard、std::fstream已经很自然了但很多项目里的第三方资源还在靠人肉释放。举个例子。用 TDengine 的 C 接口做绑定写入时taos_stmt_prepare返回的语句句柄需要在所有路径上调用taos_stmt_close。有人会选择在每个函数末尾写 close然后漏掉一个提前 return 的位置。我会用一个极小的 RAII 包装把句柄包起来struct StmtGuard { TAOS_STMT *stmt nullptr; explicit StmtGuard(TAOS_STMT *s) : stmt(s) {} ~StmtGuard() { if (stmt) { taos_stmt_close(stmt); } } StmtGuard(const StmtGuard ) delete; StmtGuard operator(const StmtGuard ) delete; };函数里TAOS_STMT *stmt taos_stmt_prepare(taos, sql); if (!stmt) { return -1; } StmtGuard guard(stmt); // 后面随便提前 return析构会负责 close if (taos_stmt_bind_param(stmt, bind, num) ! 0) { return -1; } taos_stmt_execute(stmt);这个模式不只适用于数据库句柄自定义 buffer、socket、句柄、临时文件凡是需要成对 release/close/free 的资源都值得用 RAII 包一层。这也是重构里性价比最高的一类改动——每次改动都是在消灭一整类泄漏可能。3.4 并发场景别顺手引入共享所有权并发代码里重构最容易引入隐性 bug 的地方就是所有权。我不建议为了“线程安全”而把所有对象都改成shared_ptr跨线程传递。如果两个线程要共享同一个资源先明确边界是数据不变所以可以只读共享还是需要加锁还是干脆每个线程持有自己的副本shared_ptr本身只是解决了“析构时机”的问题它不解决数据竞争。shared_ptr的引用计数是原子的但它指向的对象仍然需要同步保护。跨线程传裸指针当然危险跨线程传shared_ptr同样需要配套的锁或原子操作。我在重构并发代码时优先做的是缩小共享范围而不是换一个更高级的指针。4. 类型与接口重构拆掉上帝类让依赖方向好懂可测函数级重构解决“一个函数太臃肿”的问题类级别重构解决“一个类什么都干”的问题。后者改动更大但收益也更持久。4.1 上帝类拆解从一个 DataManager 开始我以前维护过一个叫DataManager的类构造函数里读配置、读文件、初始化连接成员函数里既做数据校验、又做格式化、还负责上报十几个公有方法彼此纠缠。重构时我先画了一张职责清单发现它实际承担了四件事加载数据、校验数据、格式化输出、上报结果。拆分后的结果是四个独立的类每个类只做一件事class DataLoader { std::vectorRecord load(const std::string path) const; }; class DataValidator { bool validate(const Record record) const; }; class DataFormatter { std::string format(const std::vectorRecord records) const; }; class DataReporter { void report(const std::string formatted) const; };原来的DataManager变成一个编排者负责把它们按顺序串起来。这个改动的意义在于任何一环发生变化只需要去对应类里修改想测试校验逻辑也不需要先构造一个完整的文件环境。拆分上帝类有一个经验不要按“感觉”拆要按“变化频率”拆。变化方向和节奏相同的代码应该待在一起变化方向和节奏不同的代码才应该被拆开。比如校验规则经常变、格式模板偶尔变、上报通道基本不变那么把它们拆开是非常正确的决定。4.2 全局单例是耦合放大器构造注入更直白项目里几乎都有几个全局单例最常见的是配置类const auto cfg GlobalConfig::instance();问题不在单例模式本身而在依赖方向。所有调用方都直接耦合到一个具体的全局对象上测试时想换一套临时配置根本无从下手。重构方法很简单——把配置作为参数传进去void saveResult(const std::string path, const Config cfg);调用方从“自己去找全局配置”变成“调用方把配置给我”。这个过程叫构造注入不一定需要引入 IoC 容器C 里构造函数传参就是最简单直接的方式。我实际改过一个模块把GlobalConfig::instance()从十几个函数里清掉统一改成构造注入。改完之后测试代码写起来轻松太多需要什么配置就构造什么配置不用再小心翼翼改全局态。全局单例的另一个隐患是初始化顺序静态变量初始化顺序在 C 里是出了名的坑能少一个全局单例就少一个定时炸弹。4.3 把不变性写进类型与访问控制重构不只是改函数也是把约束写进类型里让编译器帮你检查。举一个很常见的例子一个配置结构体struct Config { std::string name; int timeout; };所有人都能读、所有人都能改项目大了以后你根本不知道谁在哪个角落里改了timeout。重构时我一般先把字段私有化只提供const读取接口class Config { public: const std::string name() const { return name_; } int timeout() const { return timeout_; } private: std::string name_; int timeout_; };这个改动看起来简单但它做了一个关键的事情把“配置是不变的”这一假设变成了代码层面的约束。任何想改配置行为的地方都得通过接口review 时就能看到。类似的小改动还包括成员函数能加const就加const能返回const T就别返回T能用私有的就别公有。这些改动单独看都是“微创”但它们叠加起来的效果是让代码变成一个有围墙的结构而不是一个任何人都能随便进出的广场。4.4 让核心逻辑不依赖 IO 和时间可测试性是重构的高级收益而最容易破坏可测试性的就是函数直接依赖 IO 和当前时间。拿超时判断为例bool isExpired(const Record record) { const auto now std::chrono::system_clock::now(); return record.expire_at now; }测试时now是老变的很难构造边界情况。重构时把“当前时间”变成参数bool isExpired(const Record record, std::chrono::system_clock::time_point now) { return record.expire_at now; }调用方传std::chrono::system_clock::now()测试方传一个固定的时间点。这样“现在为零点过一秒”“现在是截止时间之前”都能稳定复现。逻辑与 IO 分离是这类重构的共同思路核心逻辑只处理数据外部世界通过参数或可注入的接口进入。5. 质量防线测试、编译期约束和性能验证怎么配合重构重构最大的恐惧是“行为变了但没人知道”。这一章聊聊我怎么给重构上保险让每一次改动都可验证、可回退。5.1 重构前先给当前行为拍照Golden Test 锁定重构之前我通常先给目标函数的当前行为“拍一组照片”也就是 golden test——喂一组典型输入把输出记录下来重构后对比输出是否一致。对于processLine这种解析函数一套简单的 gtest 就能锁住行为TEST(ProcessLine, GoldenLine) { EXPECT_TRUE(processLine(1,USD,200)); EXPECT_FALSE(processLine(bad)); EXPECT_TRUE(processLine(x)); // 原来怎么处理现在还怎么处理 }拍照的意义是让你敢于动手。没有这些用例你会陷入“改一行就全手发抖”的状态有测试之后重构就可以放心按步骤走每走一步跑一次全量测试红了一个用例立刻能定位到是哪个细节变了。5.2 用编译警告和 static_assert 把约束前置C 编译器比很多人想象中严格只要给足参数它能告诉你大量潜在问题。我在重构后的代码里一定会打开这些开关-Wall -Wextra -Werror-Werror把警告变成错误直接从源头堵住“先忽略以后再说”的态度。很多时候团队成员不看警告输出但如果编译直接 fail他就必须处理。除了编译器警告static_assert也是重构的强力辅助。想在代码里锁定“这个容器大小必须保持固定”“这个类型必须是平凡可拷贝的”一行static_assert就够。重构最怕的是假设散落在注释里static_assert可以把假设变成代码让编译器帮你检查。5.3 性能对比重构不是性能优化的反向操作重构之后被质疑“变慢”是很常见的。很多人认为重构只是让代码结构变好性能一定会或多或少受到影响——但实际上很多重构动作反而会减少不必要的拷贝和分配。不过嘴上说没用得拿数据说话。我的做法很简单重构前先跑一次微基准记录关键路径的一次典型处理耗时重构后跑同样的数据和同样的次数对比差异。用std::chrono就能做一个粗粒度版本auto t0 std::chrono::steady_clock::now(); for (int i 0; i 1000; i) { result process(input); } auto t1 std::chrono::steady_clock::now(); auto elapsed std::chrono::duration_caststd::chrono::microseconds(t1 - t0).count(); std::cout elapsed us\n;注意要在 Release 模式下关掉调试符号跑。这个微基准不够精确但足够发现数量级上的性能回退。如果要做正式的回归对比就要上 Google Benchmark 这类工具记录每次重构前后的数据。但至少用上面的粗粒度方法已经能挡住 90% 的“感觉变慢了”的争议。5.4 VSCode 下的编译参数配置本地就把警告当错误看如果你用 VSCode 写 C这里有一个很实用的配置技巧。在.vscode/tasks.json的编译任务里加上警告参数本地编译就能启动质量防线{ type: cppbuild, command: /usr/bin/g, args: [ -fdiagnostics-coloralways, -Wall, -Wextra, -Werror, -stdc17, -g, ${workspaceFolder}/*.cpp, -o, ${workspaceFolder}/a.out ] }不需要复杂的扩展只要把-Wall -Wextra -Werror写进编译参数每次编译都是一次基础的静态检查。很多团队只依赖 CI 来跑警告检查其实本地挡住才是最省时间的。值得注意的是-Werror在本地可能因为第三方头文件的警告导致编译失败这时可以不开全项目级-Werror只对需要重点保障的目录开启这个度要自己掌控。6. 落地节奏与翻车清单小步提交把重构控制在安全区内如果你已经准备动手了最后一章是我最想分享的落地经验。技巧学了再多节奏没把握住照样会把代码改成一锅粥。6.1 小步提交重构与功能改动分开走我第一次做大型重构时就踩过一个大坑把“抽函数”“改命名”“加新特性”“修 bug”全混在一个提交里。结果 review 时对方根本分不清哪些改动是行为变化、哪些是纯结构调整出了问题也不知道该回滚到哪里。现在的铁律是一个提交只做一种变换。提交 A从旧函数里抽出一个新函数行为完全不变。提交 B把调用方切到新函数然后删除旧函数。提交 C顺手调整命名或格式独立提交。这样做的好处有三个review 容易通过因为每个提交只解决一个问题回滚安全纯结构重构的提交随时可以单独回滚git blame清晰几个月后能搞清楚“这行代码是哪次重构引入的”。6.2 最常翻车的几个点与我的对策翻车点为什么危险我的对策过度设计为了“未来可能有扩展”提前抽象没有真实需求驱动的抽象全部砍掉接口与实现同时改所有调用方瞬间爆炸diff 巨大先加新接口调用方全部切换后再删旧接口逻辑改动与格式改动混在一个提交review 时责任不清格式调整单独一个提交不要顺手改重构途中发现测试红了不追根因就开始打补丁先回滚最近一步找到行为差异再继续原函数本身有 bug 却在重构里“顺便修了”行为变化与重构混在一起回归问题无法定位bug 修复单独提交重构保持原行为这五个翻车点里出问题最多的其实是“顺便修了 bug”。重构最大的诱惑就是“反正都要改把这段逻辑也理顺一点”。我栽过一次之后现在会刻意压制这种冲动。原函数有 bug应该先提交一个 bug fix再进入重构步骤。否则 bug 修复被淹没在重构 diff 里review 人员无法有效验证风险成倍放大。6.3 一张可以直接抄的启动清单如果你想动手但不知道从哪开始下面这张清单是我自己实际用的流程。选一个接下来一个月内真实会改动的模块而不是最难看但最没人碰的模块。给关键路径补 golden test把当前行为锁住。打开-Wall -Wextra -Werror把可见警告清零。按优先级处理先函数级拆分和去除深嵌套再梳理所有权和裸指针最后做类接口级重构。每一步编译并跑测试绿灯后再走下一步。每次提交只做一种变换逻辑改动与结构改动严格分开。重构前后各跑一次微基准记录耗时差异。按这个流程做下来我几乎没再把重构做成升级事故。它不刺激但稳。如果你按这个节奏做完一个小模块最明显的感受应该是下次改需求的时候你是在读一个维护者理解过的代码而不是靠久远记忆和grep猜结构。重构的真正价值不是代码变漂亮而是“敢改”和“改得快”。至于要不要把所有代码都重构成教科书的样子我个人是不建议的——那就是另一场灾难了。 
长河君 · 2026/10/10 19:23:30 · 阅读 1.2k C++代码重构实战：从坏味道到可维护工程
接到一个老模块的维护任务时我翻到一个叫parseAndUpdate的函数600 行、八层 if 嵌套、try/catch 丢在末尾吞异常读文件、查数据库、拼报文全在这一个函数里。那一刻我脑子里飘过四个字代码重构。但第一反应其实是“能跑就别动”。后来这个念头让我花了一周去查一个数据漏更新的 bug——逻辑藏得太深肉眼根本找不到。从此我的顺序变了先重构再改需求。这篇内容适合两类人一类是刚把 C 语法摸熟、写出的代码自己都觉得难看的入门者另一类是天天维护存量 C 项目、面对长函数和全局单例下不去手的老兵。下面说的这些技巧都是我实际在项目里反复用过的不是教科书上的“最佳实践”是可以直接照着改的。1. 重构的前提判断先分清哪些代码值得动、哪些绝对别碰很多人一上来就讨论具体技巧但重构最大的坑其实发生在动手之前。判断错误轻则浪费时间重则把稳定模块改出一堆新 bug。我见过太多“重构完代码变好看了、功能却悄悄变了”的事故所以在聊手法之前先把判断标准聊透。1.1 坏味道不是审美问题是成本问题代码坏味道看着像审美问题实际上全是维护成本问题。只有当坏味道开始拖慢你改需求的速度、让你每次修改都心惊胆战的时候它才值得处理。我在项目里最常遇到也最优先处理的坏味道基本是下面这几类坏味道典型表现为什么危险过长函数一个函数超过 100 行干了好几件事定位问题靠滚动逻辑分支组合爆炸深嵌套if/else 超过三层循环套循环任何一个分支都可能漏处理裸指针满天飞new 出来的对象到处传靠约定决定谁 delete任何提前 return 都可能泄漏全局单例耦合函数里到处都是XXX::instance()测试没法隔离依赖方向不可见重复代码同一段解析逻辑被复制到五处改一处漏一处数据不一致IO 与逻辑混合网络、文件、数据库调用散落在业务逻辑里没法 mock没法单测这些坏味道不是“看着不舒服”而是每一处都在增加下一次改动的出错概率。判断要不要重构看的是它有没有开始向你收“利息”。1.2 三个问题判断重构值不值遇到一个不顺眼的模块我会先问自己三个问题第一这个模块接下来还会不会改如果它是三年前写死、明年可能整体替换掉的边缘功能重构就是纯成本。重构的价值不体现在当下而体现在未来的每一次改动上没有后续需求的代码不值得动。第二有没有测试能兜底没有测试的模块重构等于在没有安全网的情况下走钢丝。你要么先补测试要么接受“重构成功能变更”的风险。第三改动范围能控制在一天以内吗重构最怕时间长、范围大。一个模块改到第三天你已经分不清哪些是重构、哪些是修 bug、哪些是新需求。这三个问题里只要有一个回答不乐观我就倾向于再等等。1.3 这些场景请把手从键盘上拿开有些代码天生不适合重构属于“看着难受但别动”的类型。比如算法练习代码。像冒泡排序、快速幂、单调栈、前缀和这类短小算法核心价值在逻辑本身不在结构。你硬要拆成三个类反而把简单问题复杂化。再比如一次性脚本。写出来为了跑完拉倒跑完就扔进垃圾桶的代码重构就是给垃圾做美容。还有即将重写的模块。如果你已经知道下个季度要用新架构整体替换现在花时间重构旧代码是双重浪费。我知道有人会说“旧代码还要撑到下个季度”但这时候更该做的是给关键路径补测试而不是重构结构。判断清楚了再往下谈手法才有意义。2. 函数级重构拆嵌套、提函数用 STL 替换手写循环函数是 C 重构最直接的单元。改动小、见效快、风险相对可控也是普通团队最应该先练手的地方。这里我挑三个高频场景展开。2.1 提取函数与卫语句一次击穿三层嵌套先看一段典型代码这种函数我在无数项目里见过bool parseAndUpdate(const std::string path) { std::ifstream in(path); std::string line; while (std::getline(in, line)) { if (line.size() 2) { auto tokens split(line); if (tokens.size() 3) { double value std::stod(tokens[2]); if (value 0) { if (!updateDb(tokens[0], tokens[1], value)) { return false; } } } } } return true; }问题不在“能不能跑”而在“修改时能不能看明白”。外面加一层需求检查你得数半天括号才知道它套在哪个 if 里。重构思路分两层第一层把不需要继续处理的路径提前 return第二层把每一件独立的事提成函数并让函数名说清楚它干什么bool parseAndUpdate(const std::string path) { std::ifstream in(path); if (!in) { return false; } for (std::string line; std::getline(in, line);) { if (!processLine(line)) { return false; } } return true; } bool processLine(const std::string line) { if (line.size() 2) { return true; } auto tokens split(line); if (tokens.size() ! 3) { return true; } double value std::stod(tokens[2]); if (value 0) { return true; } return updateDb(tokens[0], tokens[1], value); }改动后的行为保持一致但每一层都变平了。processLine只看一行数据parseAndUpdate只管打开文件和逐行迭代未来加字段校验只需要往processLine里加一个判断。这里有个我踩过的坑重构时顺手“修复”了原代码里的所有问题比如std::stod没有异常处理、没有检查文件是否成功打开。这是一个非常危险的冲动。重构的第一原则是行为不变你要修 bug 或加异常处理请放到另一个提交里否则你根本不知道行为变化是重构引入的还是修 bug 引入的。2.2 STL 算法替换手写循环让意图而不是下标说话C 的 STL 不只是容器算法库同样是重构利器。很多时候手写 for 循环在“做什么”这件事上是模糊的得把循环体读完才能猜出来。一个很常见的场景从一批订单里筛出状态有效且金额超过阈值的记录。std::vectorOrder result; for (size_t i 0; i orders.size(); i) { if (orders[i].status OrderStatus::kValid orders[i].amount limit) { result.push_back(orders[i]); } }用std::copy_if重写之后意图一目了然std::vectorOrder result; std::copy_if(orders.begin(), orders.end(), std::back_inserter(result), [limit](const Order order) { return order.status OrderStatus::kValid order.amount limit; });焦点从“遍历过程”转移到了“筛选条件”上这远比少写几行循环更有价值。类似的还有std::transform逐元素映射、std::accumulate求累计结果、std::find_if按条件查位置都很适合替换手写循环。但我要泼一盆冷水STL 算法不是万能钥匙。当循环体内有依赖前一次迭代结果的复杂状态时——比如实现多次递推、维护窗口时——硬套算法会让代码更难读。这种时候保留传统的 for 循环是合理选择甚至循环内就算嵌套了条件只要逻辑能直线读下来就不该为了“用算法”而用算法。2.3 字符串和容器初始化的几个顺手改法字符串处理是 C 项目里最大的重复代码来源。我见过大量接口把const std::string传来传去其实内部只读不写。改成std::string_view能避免临时拷贝尤其是在解析场景bool startsWithSlash(const std::string name) { return !name.empty() name.front() /; } // 改为 bool startsWithSlash(std::string_view name) { return !name.empty() name.front() /; }调用方如果传的是字符串字面量、const char*、std::string都能隐式构造std::string_view不用拷贝。这个改动收益取决于实际调用频率字符串越大、调用越频繁收益越明显。容器初始化也有两个细节值得改。第一能预知大小时用reservestd::vectorstd::string names; names.reserve(input.size()); for (const auto item : input) { names.emplace_back(item.name); }第二向容器里放字符串时用emplace_back而不是push_back。push_back(abc)会先构造一个临时std::string再移动进去emplace_back(abc)直接在容器内构造少一次临时对象。不要小看这种微操在高频路径上积少成多。3. 所有权与生命周期重构把内存账本交给规则而不是靠人肉记住C 和别的语言最大的不同在于资源所有权得靠人维护。裸指针时代所有人都在祈祷“记得 delete”而重构的核心就是把这个祈祷变成编译期规则。3.1 先把裸指针改成 unique_ptr所有权清晰是第一优先级看一段很典型的失败代码auto obj new Product(); if (!init(obj)) { return false; // 泄漏 obj } if (!check(obj)) { delete obj; return false; } use(obj); delete obj;每个return都要想着释放资源少写一个就泄漏。这种代码我在实际项目里改过太多做法就一步——换成std::unique_ptrauto obj std::make_uniqueProduct(); if (!init(obj)) { return false; // 自动释放 } if (!check(obj)) { return false; // 自动释放 } use(obj); // 正常路径自动释放unique_ptr在栈展开时会自动析构不管从哪条路径退出资源都会被回收。这里我想强调一个常被忽略的点不要第一个想到shared_ptr。shared_ptr的引用计数是有原子操作成本的更重要的是它会掩盖所有权归属问题让代码变成一团浆糊。绝大多数场景下独占所有权unique_ptr就够用了。3.2 值、引用、指针、移动参数传递的身位选择C 里参数传递方式的选择本身就是重构的重要内容。同一个函数参数从裸指针改成引用调用方的代码和职责都会发生明显变化。我习惯按这个表格来判断传递方式适用场景按值传递小对象int、Point、std::pair或函数确实需要本地副本const T只读访问大对象如std::string、std::vectorT接收临时对象并转移资源T*裸指针允许为空、表示借用关系且不转移所有权std::unique_ptrT转移独占所有权std::shared_ptrT多个持有者共同决定生命周期实际项目里最常见的错误是把只读大对象用裸指针或按值传递。后者会产生不必要的拷贝前者让“谁拥有”变得模糊。改成const std::string或std::string_view之后大部分场景都能在不动调用方的情况下完成。移动语义也顺便说一句std::move不是万灵丹。现代编译器普遍有返回值优化RVO函数返回局部对象时直接按值返回通常就是最优解不需要到处move。有时候我看到同事把代码写成了return std::move(obj)反而关掉了返回值优化这是反优化。3.3 RAII从锁和文件句柄到数据库 stmt 封装RAII资源获取即初始化是 C 最值钱的思想。锁和文件用std::lock_guard、std::fstream已经很自然了但很多项目里的第三方资源还在靠人肉释放。举个例子。用 TDengine 的 C 接口做绑定写入时taos_stmt_prepare返回的语句句柄需要在所有路径上调用taos_stmt_close。有人会选择在每个函数末尾写 close然后漏掉一个提前 return 的位置。我会用一个极小的 RAII 包装把句柄包起来struct StmtGuard { TAOS_STMT *stmt nullptr; explicit StmtGuard(TAOS_STMT *s) : stmt(s) {} ~StmtGuard() { if (stmt) { taos_stmt_close(stmt); } } StmtGuard(const StmtGuard ) delete; StmtGuard operator(const StmtGuard ) delete; };函数里TAOS_STMT *stmt taos_stmt_prepare(taos, sql); if (!stmt) { return -1; } StmtGuard guard(stmt); // 后面随便提前 return析构会负责 close if (taos_stmt_bind_param(stmt, bind, num) ! 0) { return -1; } taos_stmt_execute(stmt);这个模式不只适用于数据库句柄自定义 buffer、socket、句柄、临时文件凡是需要成对 release/close/free 的资源都值得用 RAII 包一层。这也是重构里性价比最高的一类改动——每次改动都是在消灭一整类泄漏可能。3.4 并发场景别顺手引入共享所有权并发代码里重构最容易引入隐性 bug 的地方就是所有权。我不建议为了“线程安全”而把所有对象都改成shared_ptr跨线程传递。如果两个线程要共享同一个资源先明确边界是数据不变所以可以只读共享还是需要加锁还是干脆每个线程持有自己的副本shared_ptr本身只是解决了“析构时机”的问题它不解决数据竞争。shared_ptr的引用计数是原子的但它指向的对象仍然需要同步保护。跨线程传裸指针当然危险跨线程传shared_ptr同样需要配套的锁或原子操作。我在重构并发代码时优先做的是缩小共享范围而不是换一个更高级的指针。4. 类型与接口重构拆掉上帝类让依赖方向好懂可测函数级重构解决“一个函数太臃肿”的问题类级别重构解决“一个类什么都干”的问题。后者改动更大但收益也更持久。4.1 上帝类拆解从一个 DataManager 开始我以前维护过一个叫DataManager的类构造函数里读配置、读文件、初始化连接成员函数里既做数据校验、又做格式化、还负责上报十几个公有方法彼此纠缠。重构时我先画了一张职责清单发现它实际承担了四件事加载数据、校验数据、格式化输出、上报结果。拆分后的结果是四个独立的类每个类只做一件事class DataLoader { std::vectorRecord load(const std::string path) const; }; class DataValidator { bool validate(const Record record) const; }; class DataFormatter { std::string format(const std::vectorRecord records) const; }; class DataReporter { void report(const std::string formatted) const; };原来的DataManager变成一个编排者负责把它们按顺序串起来。这个改动的意义在于任何一环发生变化只需要去对应类里修改想测试校验逻辑也不需要先构造一个完整的文件环境。拆分上帝类有一个经验不要按“感觉”拆要按“变化频率”拆。变化方向和节奏相同的代码应该待在一起变化方向和节奏不同的代码才应该被拆开。比如校验规则经常变、格式模板偶尔变、上报通道基本不变那么把它们拆开是非常正确的决定。4.2 全局单例是耦合放大器构造注入更直白项目里几乎都有几个全局单例最常见的是配置类const auto cfg GlobalConfig::instance();问题不在单例模式本身而在依赖方向。所有调用方都直接耦合到一个具体的全局对象上测试时想换一套临时配置根本无从下手。重构方法很简单——把配置作为参数传进去void saveResult(const std::string path, const Config cfg);调用方从“自己去找全局配置”变成“调用方把配置给我”。这个过程叫构造注入不一定需要引入 IoC 容器C 里构造函数传参就是最简单直接的方式。我实际改过一个模块把GlobalConfig::instance()从十几个函数里清掉统一改成构造注入。改完之后测试代码写起来轻松太多需要什么配置就构造什么配置不用再小心翼翼改全局态。全局单例的另一个隐患是初始化顺序静态变量初始化顺序在 C 里是出了名的坑能少一个全局单例就少一个定时炸弹。4.3 把不变性写进类型与访问控制重构不只是改函数也是把约束写进类型里让编译器帮你检查。举一个很常见的例子一个配置结构体struct Config { std::string name; int timeout; };所有人都能读、所有人都能改项目大了以后你根本不知道谁在哪个角落里改了timeout。重构时我一般先把字段私有化只提供const读取接口class Config { public: const std::string name() const { return name_; } int timeout() const { return timeout_; } private: std::string name_; int timeout_; };这个改动看起来简单但它做了一个关键的事情把“配置是不变的”这一假设变成了代码层面的约束。任何想改配置行为的地方都得通过接口review 时就能看到。类似的小改动还包括成员函数能加const就加const能返回const T就别返回T能用私有的就别公有。这些改动单独看都是“微创”但它们叠加起来的效果是让代码变成一个有围墙的结构而不是一个任何人都能随便进出的广场。4.4 让核心逻辑不依赖 IO 和时间可测试性是重构的高级收益而最容易破坏可测试性的就是函数直接依赖 IO 和当前时间。拿超时判断为例bool isExpired(const Record record) { const auto now std::chrono::system_clock::now(); return record.expire_at now; }测试时now是老变的很难构造边界情况。重构时把“当前时间”变成参数bool isExpired(const Record record, std::chrono::system_clock::time_point now) { return record.expire_at now; }调用方传std::chrono::system_clock::now()测试方传一个固定的时间点。这样“现在为零点过一秒”“现在是截止时间之前”都能稳定复现。逻辑与 IO 分离是这类重构的共同思路核心逻辑只处理数据外部世界通过参数或可注入的接口进入。5. 质量防线测试、编译期约束和性能验证怎么配合重构重构最大的恐惧是“行为变了但没人知道”。这一章聊聊我怎么给重构上保险让每一次改动都可验证、可回退。5.1 重构前先给当前行为拍照Golden Test 锁定重构之前我通常先给目标函数的当前行为“拍一组照片”也就是 golden test——喂一组典型输入把输出记录下来重构后对比输出是否一致。对于processLine这种解析函数一套简单的 gtest 就能锁住行为TEST(ProcessLine, GoldenLine) { EXPECT_TRUE(processLine(1,USD,200)); EXPECT_FALSE(processLine(bad)); EXPECT_TRUE(processLine(x)); // 原来怎么处理现在还怎么处理 }拍照的意义是让你敢于动手。没有这些用例你会陷入“改一行就全手发抖”的状态有测试之后重构就可以放心按步骤走每走一步跑一次全量测试红了一个用例立刻能定位到是哪个细节变了。5.2 用编译警告和 static_assert 把约束前置C 编译器比很多人想象中严格只要给足参数它能告诉你大量潜在问题。我在重构后的代码里一定会打开这些开关-Wall -Wextra -Werror-Werror把警告变成错误直接从源头堵住“先忽略以后再说”的态度。很多时候团队成员不看警告输出但如果编译直接 fail他就必须处理。除了编译器警告static_assert也是重构的强力辅助。想在代码里锁定“这个容器大小必须保持固定”“这个类型必须是平凡可拷贝的”一行static_assert就够。重构最怕的是假设散落在注释里static_assert可以把假设变成代码让编译器帮你检查。5.3 性能对比重构不是性能优化的反向操作重构之后被质疑“变慢”是很常见的。很多人认为重构只是让代码结构变好性能一定会或多或少受到影响——但实际上很多重构动作反而会减少不必要的拷贝和分配。不过嘴上说没用得拿数据说话。我的做法很简单重构前先跑一次微基准记录关键路径的一次典型处理耗时重构后跑同样的数据和同样的次数对比差异。用std::chrono就能做一个粗粒度版本auto t0 std::chrono::steady_clock::now(); for (int i 0; i 1000; i) { result process(input); } auto t1 std::chrono::steady_clock::now(); auto elapsed std::chrono::duration_caststd::chrono::microseconds(t1 - t0).count(); std::cout elapsed us\n;注意要在 Release 模式下关掉调试符号跑。这个微基准不够精确但足够发现数量级上的性能回退。如果要做正式的回归对比就要上 Google Benchmark 这类工具记录每次重构前后的数据。但至少用上面的粗粒度方法已经能挡住 90% 的“感觉变慢了”的争议。5.4 VSCode 下的编译参数配置本地就把警告当错误看如果你用 VSCode 写 C这里有一个很实用的配置技巧。在.vscode/tasks.json的编译任务里加上警告参数本地编译就能启动质量防线{ type: cppbuild, command: /usr/bin/g, args: [ -fdiagnostics-coloralways, -Wall, -Wextra, -Werror, -stdc17, -g, ${workspaceFolder}/*.cpp, -o, ${workspaceFolder}/a.out ] }不需要复杂的扩展只要把-Wall -Wextra -Werror写进编译参数每次编译都是一次基础的静态检查。很多团队只依赖 CI 来跑警告检查其实本地挡住才是最省时间的。值得注意的是-Werror在本地可能因为第三方头文件的警告导致编译失败这时可以不开全项目级-Werror只对需要重点保障的目录开启这个度要自己掌控。6. 落地节奏与翻车清单小步提交把重构控制在安全区内如果你已经准备动手了最后一章是我最想分享的落地经验。技巧学了再多节奏没把握住照样会把代码改成一锅粥。6.1 小步提交重构与功能改动分开走我第一次做大型重构时就踩过一个大坑把“抽函数”“改命名”“加新特性”“修 bug”全混在一个提交里。结果 review 时对方根本分不清哪些改动是行为变化、哪些是纯结构调整出了问题也不知道该回滚到哪里。现在的铁律是一个提交只做一种变换。提交 A从旧函数里抽出一个新函数行为完全不变。提交 B把调用方切到新函数然后删除旧函数。提交 C顺手调整命名或格式独立提交。这样做的好处有三个review 容易通过因为每个提交只解决一个问题回滚安全纯结构重构的提交随时可以单独回滚git blame清晰几个月后能搞清楚“这行代码是哪次重构引入的”。6.2 最常翻车的几个点与我的对策翻车点为什么危险我的对策过度设计为了“未来可能有扩展”提前抽象没有真实需求驱动的抽象全部砍掉接口与实现同时改所有调用方瞬间爆炸diff 巨大先加新接口调用方全部切换后再删旧接口逻辑改动与格式改动混在一个提交review 时责任不清格式调整单独一个提交不要顺手改重构途中发现测试红了不追根因就开始打补丁先回滚最近一步找到行为差异再继续原函数本身有 bug 却在重构里“顺便修了”行为变化与重构混在一起回归问题无法定位bug 修复单独提交重构保持原行为这五个翻车点里出问题最多的其实是“顺便修了 bug”。重构最大的诱惑就是“反正都要改把这段逻辑也理顺一点”。我栽过一次之后现在会刻意压制这种冲动。原函数有 bug应该先提交一个 bug fix再进入重构步骤。否则 bug 修复被淹没在重构 diff 里review 人员无法有效验证风险成倍放大。6.3 一张可以直接抄的启动清单如果你想动手但不知道从哪开始下面这张清单是我自己实际用的流程。选一个接下来一个月内真实会改动的模块而不是最难看但最没人碰的模块。给关键路径补 golden test把当前行为锁住。打开-Wall -Wextra -Werror把可见警告清零。按优先级处理先函数级拆分和去除深嵌套再梳理所有权和裸指针最后做类接口级重构。每一步编译并跑测试绿灯后再走下一步。每次提交只做一种变换逻辑改动与结构改动严格分开。重构前后各跑一次微基准记录耗时差异。按这个流程做下来我几乎没再把重构做成升级事故。它不刺激但稳。如果你按这个节奏做完一个小模块最明显的感受应该是下次改需求的时候你是在读一个维护者理解过的代码而不是靠久远记忆和grep猜结构。重构的真正价值不是代码变漂亮而是“敢改”和“改得快”。至于要不要把所有代码都重构成教科书的样子我个人是不建议的——那就是另一场灾难了。