1. 项目重构概述
大家好，我是老张。做Qt开发十几年了，今天咱们聊聊项目重构这个话题。
说实话，我见过太多Qt项目从最初的清爽整洁，慢慢变成了一团乱麻。嗯，我自己也踩过不少坑。所以这一章，我想把关于重构的那些事儿，掰开了揉碎了讲给你听。
什么是项目重构
项目重构，说白了就是在不改变外部行为的前提下，对内部结构进行优化。
你想想看，代码能跑、功能正常，但就是看着别扭——变量命名乱七八糟、一个类干了八百件事、信号槽连得跟蜘蛛网似的。这时候，你就该考虑重构了。
重构的核心原则：
- 外部行为不变——用户看到的功能一模一样
- 内部结构优化——代码更清晰、更易维护
- 小步迭代——每次改动一点点，随时能跑起来
我记得刚入行那会儿，接手一个Qt项目，光是一个MainWindow就写了8000行。我当时想，这玩意儿谁敢动？后来学了重构，才明白——不是不敢动，是方法不对。
重构的动机与收益
为什么要重构？我总结了几点：
| 动机 | 具体表现 | 收益 |
|---|---|---|
| 代码腐化 | 类越来越大、函数越来越长 | 可读性提升，新人上手快 |
| 重复代码 | 同样的逻辑写了三五遍 | 维护成本降低，改一处就行 |
| 耦合严重 | 改A模块，B模块跟着崩 | 模块独立，风险可控 |
| 测试困难 | 一个函数干太多事，没法测 | 可测试性增强，质量有保障 |
收益这东西，短期看不出来。但坚持半年后，你会发现：bug少了、改需求快了、加班也少了。我在一个车载项目中深有体会——重构前加个按钮要半天，重构后十分钟搞定。
我的经验：重构最好的时机是「你觉得代码恶心但又说不出哪里恶心」的时候。别犹豫，动手吧。
重构 vs 重写
这个问题我经常被问到。很多人觉得：代码烂成这样，不如推倒重来？
我的建议是——除非万不得已，别选重写。
为什么会这样？
- 重构：小步快跑，每次改一点，随时能上线。风险可控，成本低。
- 重写：从零开始，周期长。旧系统的坑你未必全知道，新系统可能踩更多雷。
我曾经参与过一个项目，团队决定重写一个Qt桌面应用。结果呢？写了半年，功能还没赶上旧系统。老板急了，最后又回去改旧代码。你说折腾不折腾？
注意：以下情况可以考虑重写：
- 技术栈彻底过时（比如Qt 3迁移到Qt 6）
- 架构完全不可救药（改一处崩十处）
- 业务逻辑需要大改（重构成本反而更高）
Qt项目重构的常见场景
做Qt这么多年，我总结了几个高频重构场景：
1. 界面与逻辑耦合
这是最常见的。很多人习惯在QWidget里直接写业务逻辑。结果呢？换个UI框架，代码全废了。
// 反面教材：界面里写数据库操作
void MainWindow::onSaveClicked() {
QSqlQuery query;
query.exec("INSERT INTO ..."); // 业务逻辑混在UI里
}2. 信号槽滥用
信号槽是Qt的利器，但用不好就是灾难。我曾经见过一个项目，信号槽连接图比蜘蛛网还密。调试的时候，一个信号发出去，根本不知道谁会响应。
3. 类职责过重
一个类干了十件事——界面显示、数据处理、网络通信、文件读写……这种类我称之为「上帝类」。重构的目标就是把它拆开。
4. 硬编码与魔法数字
代码里到处都是数字、字符串常量。改个样式？你得翻遍整个项目。
// 重构前
button->setFixedSize(120, 35); // 120和35是什么意思？
// 重构后
const int kButtonWidth = 120;
const int kButtonHeight = 35;
button->setFixedSize(kButtonWidth, kButtonHeight);避坑指南：我曾经在一个项目中，把所有硬编码的尺寸都提取成了常量。后来UI改版，改起来那叫一个爽。嗯，这个习惯我一直保留到现在。
知识体系总览
下面这张图，是我对本章内容的一个梳理。你可以把它当作整个重构课程的导航图。
这张图把重构的核心要素都串起来了。从定义到动机，从收益到场景，再到和重写的对比。你可以在后续的学习中，随时回来看看这张图，心里就有谱了。
好了，这一章就到这里。重构这件事，说起来简单做起来难。但只要你迈出第一步，后面就会越来越顺。
一句话总结：重构不是炫技，而是为了让代码更「好」——好读、好改、好维护。别怕动手，从今天开始，改掉一个坏味道，你就赢了。
可可精品资料库