工程化基础：从“能跑就行”到“可持续交付”

说实话，我见过太多Qt项目了。早期都是一个人闷头写，代码堆在一起，编译靠qmake一把梭。等团队扩大到三五个人，问题就全冒出来了——编译慢、冲突多、版本乱、没人敢重构。嗯，这就是典型的“工程化缺失”。

我个人习惯把工程化理解为：让项目在多人、多版本、多平台下，还能稳定、高效地迭代。它不是某个工具，而是一套方法论。

工程化的定义与目标

说白了，工程化就是给项目“上规矩”。目标很明确：

• 可复现：换台机器、换个环境，一键就能编译通过
• 可追溯：谁改了哪行代码，为什么改，都能查清楚
• 可测试：改完代码，能自动验证没引入新bug
• 可交付：打包、发布流程标准化，不依赖某个人

我在项目中遇到过最典型的反例：一个同事把编译好的.so直接提交到Git里，理由是“别人编译不过”。这就是工程化缺失的典型症状。

Qt工程化的核心要素

一个成熟的Qt工程化体系，至少包含以下四个要素：

1. 构建系统：决定怎么编译、链接、部署
2. 版本控制：管理代码变更历史
3. 代码规范：统一风格，降低阅读成本
4. 持续集成：自动化构建、测试、发布

你想想看，这四个要素缺一个会怎样？没有构建系统，每个人手动敲g++；没有版本控制，改坏了只能重写；没有规范，代码像天书；没有CI，每次发布都像赌博。

构建系统选择：qmake vs CMake

这是每个Qt开发者都会面临的选择。我直接说结论：新项目建议用CMake，老项目可以继续用qmake。

为什么会这样？我列个对比表你就明白了：

对比项	qmake	CMake
学习曲线	低，Qt专用	中等，通用
跨平台能力	一般，依赖Qt	强，原生支持
第三方库集成	麻烦，需手动配置	简单，find_package
IDE支持	Qt Creator原生	VS、CLion、Qt Creator都支持
Qt6支持	已弃用	官方推荐

我曾经在一个老项目里用qmake，想集成一个OpenCV库，折腾了两天没搞定。换成CMake后，三行代码就解决了：

find_package(OpenCV REQUIRED)
target_link_libraries(myapp PRIVATE ${OpenCV_LIBS})
include_directories(${OpenCV_INCLUDE_DIRS})

嗯，这就是差距。

这里我给出一个CMake的最小示例，适合新项目起步：

cmake_minimum_required(VERSION 3.16)
project(MyQtApp VERSION 1.0.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_AUTOUIC ON)

find_package(Qt6 REQUIRED COMPONENTS Widgets Core Gui)

add_executable(${PROJECT_NAME}
    main.cpp
    mainwindow.cpp
    mainwindow.h
    resources.qrc
)

target_link_libraries(${PROJECT_NAME} PRIVATE
    Qt6::Widgets
    Qt6::Core
    Qt6::Gui
)

这段代码里，AUTOMOC、AUTORCC、AUTOUIC这三个开关一定要打开。我见过有人忘了开AUTOMOC，结果信号槽死活连不上，排查了半天。

版本控制与分支策略

版本控制这块，Git已经是事实标准了。但光会用Git不够，还得有分支策略。

我个人比较推荐Git Flow的简化版，适合中小团队：

• main：稳定版本，只合入经过测试的代码
• develop：日常开发主分支
• feature/xxx：新功能分支，从develop拉出
• fix/xxx：bug修复分支
• release/x.x.x：发布准备分支

我曾经在一个项目里吃过亏：所有人都在main上直接提交，结果某天有人push了一个编译不过的代码，整个团队都拉不下来新代码。从那以后，我强制要求：main分支必须保护，不允许直接push。

这里我画了一张分支策略的流程图，帮你直观理解：

这张图里，main和develop是两条常驻分支。feature从develop拉出，开发完合并回去。release从develop拉出，测试稳定后合并到main并打tag。fix从main拉出，修完同时合并回main和develop。

嗯，这套策略我用了好几年，团队从3人扩展到15人，基本没出过大乱子。当然，如果你团队只有一两个人，可以更简化——只用main和feature就够了。