C++代码重构实战：从上帝类到智能指针与依赖注入

接盘一个维护了三年多的C++服务端模块时，我的第一反应和大多数人一样：先把能跑的部分看明白，再把明显不合理的地方一点点改掉。那段时间我第一次认真体会到，所谓“C++代码重构”不是一个“收拾屋子”的动作，而是一整套以行为保持不变为前提的、系统性的结构调整工程。代码不会因为多写了注释就变好，也不会因为某个类看起来顺眼就自动变健康。真正发生质变的时刻，是我意识到重构的核心不是“改得更好看”，而是“改得能验证”。

这篇内容是我在重构某个遗留模块（后面都叫它“模拟项目X”）过程中的完整记录。没有停留在“重构很爽”的情绪层面，也不打算讲一堆高大上的理论。我会从一个真实接盘场景出发，拆解我实际动过的三类典型问题：上帝类、裸指针、全局状态，并给出每一步的具体方法和判断依据。不管你是刚接触C++不久，还是已经写了几年但对重构缺少系统抓手，这里面应该都有可以直接拿去用的东西。

1. 接盘三年老代码：为什么我坚持要重构

1.1 我遇到的“模拟项目X”到底烂在哪

“模拟项目X”是一个在公司内部跑了多个版本的C++服务端模块，年限不算特别长，但因为经历过好几拨维护者，代码风格和架构思路早就混成了一锅粥。最典型的特征是一个两千多行的核心类，名字叫Service，但它实际承担了配置解析、网络通信、业务校验、日志输出、缓存管理、状态上报等几乎所有职责。类里三十多个成员变量，十几个公开方法，方法之间互相调用，耦合到了一起。

功能开发慢到什么程度呢？给这个模块加一个新接口，理论上只是加一个入口、写一段业务处理，但实际执行起来要动四五个文件，还要小心翼翼地绕开各种隐式依赖。更让人头疼的是，某些方法的行为依赖一个全局的配置对象，而这个配置对象在测试环境里经常是空的或者乱序初始化的，导致一部分功能时好时坏。

接手前我已经听说过这个模块“不稳定”，但真正让我警觉的是另一件事：我这个模块的单元测试覆盖率接近零。也就是说，过往能跑起来全靠手工验证，改了A之后B挂了，B挂了之后C又跟着崩，整个过程全靠人肉试错。没有人能说清楚这个模块到底是靠什么逻辑稳定运转的——或者说，它根本就没稳定运转过。

1.2 重构带来的直接收益：不是“代码好看”而是“改得动”

我在重构过程中逐步记录了改动前后的对比。同样是增加一个中等规模的新功能，重构前需要投入的排障时间大约要两到三天，重构后通常半天到一天就能完成，而且新功能不会再因为触碰到某个隐藏依赖而间歇性崩掉。这个变化不是玄学，而是结构调整的直接结果。

当模块里的逻辑从“一个类全包”变成“几个类各管一段”之后，每次改动影响的代码范围会显著缩小。拿配置解析来说，原来是Service里一个私有方法读全局配置，现在是ConfigProvider在自己的小类里负责这件事，接口清晰，测试也好写。我不用再把整条调用链在脑子里完整跑一遍，只需要关心自己负责的那一层。

另一个很重要的收益是新人接手成本变低了。重构后的模块，阅读顺序基本就是代码目录顺序，一个新同事从进来开始看代码到能独立改bug，时间从原来的一周以上压缩到三四天。这个感受很直观：代码不是给人看的吗？那它至少得让人能顺畅地看下去。

1.3 什么时候不应该动手重构

说句实在的，重构不是万能药，也不是每个老项目都适合立刻动手。我总结下来，有几种情况我会建议“先等着”：

• 没有任何测试基线：如果改了代码后连“它原来是对是错”都说不清，那重构就是盲人摸象，一定要先补测试。
• 需求正在剧烈变化：一个业务逻辑每两周就换个方向的模块，你重构完下一周又得改，等于白干。
• 正处于发布前的冻结期：这时候动结构风险远大于收益，哪怕代码再难看也得忍住。
• 项目本来就快被替换了：与其大改，不如把力气花在新系统上。

我在给“模拟项目X”动手之前，专门花了一阵子去梳理“哪些部分正在稳定运行、哪些部分已经没人敢碰”。结论是：它既没有测试基线，需求也不算完全稳定，但它属于那种“再不改就真的没人能维护”的模块。这种情况下，与其说是“要不要重构”，不如说是“怎么在可控范围内开始重构”。最好的方式不是一口气推倒重写，而是把重构当成一连串小手术来做，一边做一边保证系统还能跑。

2. 重构前的三道防线：行为基线、静态分析和切入点选择

2.1 先让行为基线跑起来：至少有一个活着的测试

我的习惯是，任何重构开始之前，先建立“行为基线”。说白了，就是让现有代码在重构前后表现一致，并且有办法证明它一致。没有测试基线的重构，就像在黑暗里调一颗螺丝，拧没拧紧全靠手感。

“模拟项目X”最开始时测试覆盖几乎为零，所以我没有上来就逼自己写满全部单元的测试，而是先挑了几个“最重要、最常被改动”的接口，用特征测试的方式把现有行为固化下来。什么是特征测试？就是你不管这个行为是对是错，先把当前输出的结果记录下来，作为后续对比的基准。举个例子，某个方法当前对参数可能是错误处理的，但它就是返回了一个特殊错误码；我先把这个“特殊错误码”作为预期结果写进测试。后续重构时只要行为变了，测试就会明确报警。

记住一个关键原则：重构期间不要顺手修bug。看到疑似错误的逻辑，先记录在案，等重构完成后再单独修。因为一旦你在重构过程中混入行为变更，测试报警时你分不清是结构改错了还是业务修对了，排查成本会成倍上升。我见过太多人重构做着做着就开始修逻辑，最后代码结构没理顺，倒是把行为改出了新问题。

2.2 借助编译器和静态分析工具定位雷区

在动手改代码之前，还有一个容易被忽略的准备：把编译器的警告级别开高，并让静态分析器跑一遍。很多人常年把警告当作“不影响编译的噪声”，但在重构场景里，警告往往是隐藏行为的线索。

我给“模拟项目X”做了一次全面扫描，重点看三类问题：未初始化变量、拷贝构造函数和赋值运算符缺失、潜在的资源泄漏路径。编译器开-Wall -Wextra之后立刻就能发现一批“老代码里只靠经验在兜底”的隐患。静态分析工具我也试过几种，比较常用的是 cppcheck 和 clang-tidy，它们能找到的不止是编译器能发现的错误，还包括一些“看起来合法但很容易写错”的模式，比如虚函数析构、隐式类型转换、不必要的深拷贝等。

这些扫描结果不用一次性全改完，但它们会告诉你一件事：代码里哪些地方是雷区。重构时我会重点绕开或优先处理这些地方，而不是闷头按原计划推进。

2.3 切入点别从最难处开始

很多人一进老代码就盯着最复杂的部分，觉得“最难啃的骨头啃下来，其他都好说”。我的实际经验恰恰相反：切入点要选那个“改动后最容易验证、收益又最明显”的区域。我选择的是“模拟项目X”里最核心的一个业务处理流程，它对应着一个用户在真实业务中几乎每天都会触发到的入口，而且它的行为相对明确，容易做特征测试。

把这块流程重构完成后，我能立即获得一个可对比的行为基线，后续再做其他改动时有了参照物。相比全模块铺开，这种小范围切入还有一个好处：如果出了问题，影响面可控，回滚成本低。我把整个重构计划按模块拆成了多个阶段，每个阶段都是“准备测试→小步重构→验证→提交”，而不是一次性把全部问题都装进一个大版本里。

3. 第一次动手：把两千行的“上帝类”拆成协作组件

3.1 识别上帝类的信号：以“模拟项目X”的核心类为例

“模拟项目X”的核心类当时的状态，用一句C++圈的老话来说就是典型的“上帝类（God Object）”：类里什么都能干，什么都往里塞，最后谁都能用但是谁都不敢改。它的一些特征非常明显：

• 超过两千行，而且还在持续增长；
• 成员变量一大堆，很多字段之间的关联关系只有原作者清楚；
• 公开方法十几个，但方法内部大量重复调用私有方法，逻辑纠缠不清；
• 职责严重混杂：一个函数里既要解析网络包，又要写日志，还要更新内存缓存。

我当时画了一份简单的职责清单，发现这个类至少承担了六种以上完全不同的工作。怎么拆？一个很实用的原则是：从成员变量的使用关系入手。把那些“经常被同一组方法读写”的字段归成一类，看看它们到底在表达什么概念。比如网络连接相关的字段和日志输出的字段，从来不会被同一条业务逻辑同时使用，那它们就不该待在同一个类面里。

3.2 提取方法：最小粒度的重构动作

拆分上帝类的第一步，不是急着新建类，而是先做方法提取。我把自己最开始写代码时那种“一个方法写到底”的习惯反过来，把大函数按自然段落拆成若干小函数。

举一个简化版的例子。重构前大概是这个样子：

void Service::ProcessRequest(const Request& req, Response& resp) { if (!req.IsValid()) { logger_.Log("invalid request"); resp.SetError(ERROR_INVALID_REQ); return; } // 解析请求中的配置更新字段，并应用到当前配置 if (req.HasConfigUpdate()) { auto newConfig = config_.Apply(req.GetConfigPatch()); if (!newConfig) { logger_.Log("config apply failed"); resp.SetError(ERROR_CONFIG); return; } config_ = *newConfig; } // 按新的配置调用业务处理逻辑 ... }

我第一次重构时把它拆成这样：

void Service::ProcessRequest(const Request& req, Response& resp) { if (!ValidateAndReject(req, resp)) { return; } ApplyConfigIfNeeded(req, resp); HandleBusinessLogic(req, resp); }

每一个被提取出来的小函数都有明确的意图命名：ValidateAndReject、ApplyConfigIfNeeded、HandleBusinessLogic。这样做的目的不是单纯让行数变少，而是让每一层逻辑的入口变得可见。后来维护的时候，我只需要根据函数名就能决定进入哪一段去排查问题，不用再把整个流程从头到尾读一遍。

提取方法的时候有一个习惯我一直坚持：每次只提取一个函数，然后立刻编译、跑相关测试。哪怕只是移动几行代码这种看似无风险的改动，也要验证一次，因为在C++里有太多“看起来一样但语义不同”的边界情况，比如引用绑定、迭代器失效、内部缓冲区的生命周期等。

3.3 从成员变量分组中拆出新类

方法提取做到一定阶段，接下来就是“提取类”。我会先从成员变量中找出几个联系最紧密的字段组，把相关的方法和字段一起搬到新的类里头。

在“模拟项目X”里，我第一个拆出来的是“配置应用”这个职责。原始代码里有一组字段专门负责配置的读取、更新和校验，它们被散落在多个方法中，逻辑上非常内聚，物理上却分布在各个角落。于是我把它们搬进一个新的ConfigProvider类：

class ConfigProvider { public: explicit ConfigProvider(std::string initialConfig); bool ApplyPatch(const std::string& patch, std::string* errorMsg); const std::string& Current() const; private: std::string config_; bool ValidatePatch(const std::string& patch); };

拆出ConfigProvider之后，Service内部所有跟配置直接相关的逻辑都替换为对ConfigProvider的调用。这一步做完，原有类立刻瘦了一截，而且配置行为的标准逻辑被集中到一个小类里，后续要加配置校验规则只需要改动ConfigProvider，完全不需要碰业务逻辑。

3.4 用构造函数注入消除“偷偷调用”

拆出类之后，原来的Service内部很多地方还是直接构造、直接访问，导致类与类之间仍然存在硬编码依赖。真正的解耦，是把依赖从内部构造变成外部注入。

我当时做的最有价值的一个改动，就是把日志对象的初始化从Service内部拿到构造函数外面来。原来代码大概是：

class Service { public: Service() : logger_(new Logger()) {} private: std::unique_ptr<Logger> logger_; };

这种写法的问题在于：每次创建Service都会真实创建一个日志对象，测试时也一样。如果日志对象依赖文件系统，测试里就会产生一堆真实日志；如果日志对象状态不对，Service的初始化也会跟着失败，但那是Service不关心的事。改成注入之后就顺了：

class Service { public: explicit Service(std::shared_ptr<Logger> logger) : logger_(std::move(logger)) {} private: std::shared_ptr<Logger> logger_; };

注入带来的直观好处有两层：第一，测试时可以替换成一个假的Logger，不需要真实写文件；第二，Service不再负责Logger的创建过程，创建和使用的责任被分离。对于习惯了“new 一个就在内部用”的写法的人来说，刚开始会觉得构造函数参数变多了，但多出来的参数恰恰是在告诉使用方：这个类运行需要哪些东西。没有隐式依赖，没有“偷偷调用”，所有的协作关系变得可以用眼睛扫出来。

4. 替换裸指针：RAII改造不能只看类型

4.1 先判断裸指针有没有所有权

提到C++代码重构，绕不开的话题就是裸指针。模拟项目X里有大量new和delete散布在各处，最常见的资源泄漏场景是：函数中段出现早返回，但返回前忘了delete；或者对象被异常抛出后，析构函数根本不会执行到delete那一行。我见过实际生产环境里一个内存飙到几个G的服务，排查到最后就是一组裸指针在异常分支里泄漏了。

但我也要说清楚一个容易被混淆的点：不是所有裸指针都该改造成智能指针。指针可以分为“拥有所有权”和“不拥有所有权”的两种。判断的标准很简单：这段代码负责delete吗？如果负责，则是所有权指针；如果只是别人传进来让你用一下、用完就完，那就是非所有权指针。

在很多重构指南里，正确的做法是：所有权指针用std::unique_ptr或std::shared_ptr管理，非所有权指针继续保留裸指针也没问题。我见过有人看到std::unique_ptr就无脑替换所有裸指针，结果把接口参数全部强制改成智能指针的引用，搞得复制、比较、转换全都变复杂了。

4.2 默认选 unique_ptr：大部分指针都能这么换

最常见、也是优先推荐的模式是：默认使用std::unique_ptr。它的语义很明确：一个对象同一时刻只能有一个持有者，移动意味着所有权转移，析构自动释放。我重构“模拟项目X”时，把绝大多数new/delete直接改成了std::unique_ptr，只有少数确实需要多个持有者的地方才用std::shared_ptr。

改造前后对比可以看一个例子：

// 重构前 NetworkClient* client_ = new NetworkClient(); ... delete client_;

// 重构后 std::unique_ptr<NetworkClient> client_ = std::make_unique<NetworkClient>();

不要小看这个替换，它带来的最直接变化就是异常安全。原始代码如果在delete client_之前抛出一个异常，内存就泄漏了；换用std::unique_ptr之后，无论是正常路径还是异常路径，析构函数都会老老实实地释放对象。这就是“资源获取即初始化（RAII）”在C++里最核心的价值：资源不是靠你记住释放，而是靠对象的生命周期管理释放。

4.3 替换过程中最容易被忽略的语义差异

智能指针替换裸指针，很多人以为就是“把*换std::unique_ptr<>”，实际上有几个语义差异非常容易踩坑。

一个是拷贝语义。裸指针可以随便拷贝，但std::unique_ptr不允许拷贝，只能移动。如果一个类原本有拷贝构造函数，并且它内部持有裸指针，那么加上unique_ptr成员之后拷贝构造会编译失败。这时候要问自己一个问题：这个类真的需要拷贝吗？还是说它本来就是一种“不能被复制、只能被移动”的独占资源？我在重构中就碰到过一个Session对象，它本来持有裸指针，我改成unique_ptr之后发现编译不过，排查下来发现之前的裸指针版本其实一直在“浅拷贝”，两个Session对象共享同一个底层资源，析构时还会出现 double free。改用unique_ptr反而是真正暴露了之前设计上的错误，最终这个类被改成了移动语义。

另一个容易踩的坑是循环引用。std::shared_ptr虽然能做自动回收，但它一旦形成循环引用，比如父对象持有子对象的shared_ptr，子对象又持回父对象的shared_ptr，那这两个对象就永远无法释放。这种时候要用std::weak_ptr打破循环。我在重构“模拟项目X”时遇到的典型案例是：一个Manager持有多个Worker的shared_ptr，每个Worker又持有一个Manager的回调对象，结果一批实例永不释放。改为weak_ptr之后才恢复正常。

还有一个非常实用的提醒：替换指针要一个一个来，不要让编译器决定从哪里开始。我最初尝试用脚本批量替换，结果一次编译错误上百个，根本没法定位。后来老老实实地从叶子对象开始，每替换一处就编译一次、跑一次相关测试，虽然慢，但每一步都踏实。

5. 清理全局状态：把隐式依赖变成显式注入

5.1 全局变量在C++里引发的连锁反应

“模拟项目X”里有一批全局配置对象和工具类，它们以各种单例的形式存在。看起来用起来方便，但维护到后期问题就多了：全局对象的初始化顺序不稳定，不同编译单元之间可能相互依赖；测试时没法干净地替换，因为每个测试都在共享同一份全局状态；某个模块改了全局内容，另一个模块也会被悄悄影响。

我遇到过最经典的一次事故是：新增了一个全局日志开关，结果后台任务的日志量瞬间暴涨，因为那个全局对象被十几个模块同时读写，没有一个模块知道是谁把它打开成“全部输出”模式的。排查到最后，只能靠搜索关键字符串来定位修改点——这种成本在重构前几乎无法避免。

5.2 从只读常量开始收敛全局状态

清理全局状态，我建议从“读多写少”的那一类开始，风险最低。比如很多模块都会遇到的全局版本号、全局路径前缀、全局环境标志。如果它们只是被读取，没有运行时写入需求，就能直接转成常量并注入到需要的地方，不用再通过全局对象访问。

这里有个操作技巧：先定义一个新的配置对象，在进入某个类之前把它准备好，再通过构造函数传进需要的地方。用构造注入替换全局访问时，我不要求一步到位，而是允许新旧两种方式短期共存。比如某个方法里原来直接读全局配置，我先改成ConfigProvider::Get()这种静态方法，让调用面集中起来；等调用点都收敛到足够少之后，再把它改成成员变量。这种“两步走”的思路，比一夜之间删除所有全局对象要安全得多。

5.3 单例也是隐式依赖：能注入就注入

单例在C++里是一个非常特殊的争议话题。很多人都知道它带来的全局副作用，但用起来却很难戒掉，因为“哪里都能拿到”实在太方便了。我在重构中给自己的规矩是：单例可以做，但不允许在类内部直接通过Singleton::Instance()去获取依赖。所有单例对象，都应该在更高的组装层被取出来，然后作为参数传入业务类。

一个典型的对比：

// 重构前：业务类内部直接拿单例 void OrderService::Ship() { auto& audit = AuditLogger::Instance(); audit.Log("ship"); ... }

// 重构后：依赖从构造函数进来 OrderService::OrderService(AuditLogger& audit) : audit_(audit) {} void OrderService::Ship() { audit_.Log("ship"); ... }

表面上看只是换了个拿对象的方式，但本质区别是：OrderService不再关心AuditLogger是怎么创建出来的，它只知道“我需要一个日志对象”，至于这个对象是不是单例、是不是模拟实现，都不归它管。运行时加载和测试替换的能力一下就打开了。

清理全局状态不是一日之功。在我重构“模拟项目X”的中期，还保留了不少全局标志，但它们的引用点已经集中到少数几个对象里了，这个“集中化”过程本身就是有价值的。

6. 稳住重构过程：小步提交、格式分离与踩坑复盘

6.1 小步提交：让每一次修改都能编译和通过测试

重构最忌讳的就是“憋大招”。我记得有一次连着写了三天代码，想着等整体都改完再编译提交，结果第四天编译出了一千多个错误，那一天都在和编译器搏斗，根本不知道该从哪个错误开始解。后来我给自己立了一条铁律：每次只做一件事，做完立刻编译、跑测试、提交。

这条铁律听起来简单，执行起来需要配合粒度拆分。比如我要拆一个两百行的函数，会先提交一个“只提取方法、不改任何行为”的改动；再提交一个“把方法挪到新类”的改动；再提交一个“把新类接入调用点”的改动。这样做的好处是：如果哪一步出了回归，回滚范围非常明确。而且每次提交都能通过测试，这个模块在重构过程中的健康度就一直是被保持的，不会出现“重构进行到一半，系统处于不可用状态”的极度难受局面。

6.2 重构和格式化必须分开进行

这里有一个很多人在实际项目里容易忽略的坑：重构过程中顺手做了大范围格式化。比如你不小心把整个文件从4空格缩进换成了2空格，或者用 clang-format 格式化了一个本来没有动过的类，结果代码review时，真正的结构改动和缩进改动混在一起，看diff的人完全分不清哪些是需要重点审查的逻辑变化。

我的做法是：如果确实要格式化，单独提交一次。把“改变行为结构”和“改变代码风格”分开，每次提交只解决一个问题。这样review的人能一眼看出重点，后续追溯历史时也不会被无意义的格式噪音干扰。

6.3 我在这次重构中踩过的坑

写到这里，我复盘了一下这次“模拟项目X”重构里真实出现过的失误，挑几个对你有参考价值的说。

第一个坑是在重构中段忍不住“顺手修了一个bug”。当时我发现一个字段的默认值好像不太对，就顺手修正了逻辑。结果测试立刻报警，我花了一个多小时才意识到，那个字段在旧系统里就是被人为“用错了”，而某个下游模块恰恰依赖这个错误值来做分支判断。我修的“正确行为”反而让下游逻辑进了原本不会进入的分支。后来我花了两天时间说服自己：重构期不改行为，任何疑似bug都要单独记录、单独建任务。

第二个坑是依赖注入改得太彻底，导致某个细节方法的调用链变长，一部分代码为了拿到一个本来全局可用的对象，不得不加了一层参数传递。改完之后，虽然结构更干净，但短期内的可读性反而下降了。这个教训让我学会了一个判断标准：依赖注入确实好，但如果为了注入一个对象，让中间层所有函数都要加参数，那就要考虑是不是有更好的引入方式，比如引入上下文对象或者接口聚合，而不是盲目给每个类都塞构造函数参数。

第三个坑和性能有关。一次我把某个函数从指针传参改成对象的智能指针包装，理论上没问题，结果这个函数处于底层热路径上，改动后分配次数明显变多。虽然现代C++的智能指针分配成本已经很低，但在高频调用下累积效应依然存在。我后来用分析器跑了一下热点，把那层包装改回指针传参才恢复。这件事给我最大的启发是：重构的优先级永远是“先跑对、再跑快”，但跑对之后一定要关注是否引入了不必要的运行时开销，尤其是那些每天被调用成千上万次的路径。

还有一点经验想分享：重构不是一个人的事情。当初如果有更充分的交流和代码评审，在拆分上帝类阶段就能更早发现一些被保留的错误依赖。我后来的很多决策都建立在“先让测试替我们说话”这个前提下，但凡代码里有“感觉不对但没依据”的地方，我都会选择先写一个行为测试把现状钉住，再开始改。回头来看，真正让这次重构没有翻车的，不是某个高明的设计，而是一整套“可验证”的流程：每步都能编译、每步都能测试、每步都小得足以回滚。重构这个动作本身不难，难的是让每一步都稳得住。