第2章 遗留系统诊断：如何识别代码坏味道
说实话，接手一个遗留系统，最让人头疼的不是功能有多复杂，而是代码本身就像一团乱麻。我见过太多团队，花了几周时间想改一个小功能，结果发现牵一发动全身。为什么？因为代码里藏着各种坏味道——意大利面条式代码、上帝类、循环依赖。这些东西不揪出来，重构就是纸上谈兵。
这一章，我们就来聊聊怎么用静态代码分析工具，快速定位这些坏味道。我会结合我自己的踩坑经历，给你一套可落地的诊断方法。
2.1 三种核心坏味道：症状与危害
先看个表格，把三种坏味道的特征说清楚。你对照一下，看看自己的项目里有没有类似情况。
| 坏味道类型 | 典型症状 | 危害 |
|---|---|---|
| 意大利面条式代码 | 函数超长（>200行）、goto满天飞、全局变量滥用、控制流混乱 | 无法单步调试、修改一个地方炸一片、新人看不懂 |
| 上帝类 | 单个类/模块包含数百个方法、依赖大量外部模块、承担多种职责 | 编译慢、测试难写、任何改动都要回归整个模块 |
| 循环依赖 | A模块调用B模块，B模块又调用A模块；编译时出现循环头文件包含 | 链接失败、初始化顺序不可控、模块无法独立测试 |
2.2 静态代码分析工具实战
手动翻代码找坏味道？效率太低了。我习惯用工具先扫一遍，再针对性地看关键文件。下面是我常用的三款工具，各有侧重。
2.2.1 Cppcheck：轻量级静态分析
Cppcheck 适合快速扫描，能发现明显的逻辑缺陷和风格问题。用法很简单：
cppcheck --enable=all --suppress=missingIncludeSystem \
--xml --xml-version=2 ./src/ 2> report.xml它会报告函数复杂度、未初始化变量、内存泄漏等。我一般先跑这个，把明显的问题修掉，再上更重的工具。
2.2.2 SonarQube：持续监控代码质量
SonarQube 能生成可视化报告，支持自定义规则。对于遗留系统，我重点关注这几个指标：
- 圈复杂度：单个函数超过15，就要考虑拆分。
- 重复代码率：超过5%的重复，说明抽象不够。
- 依赖关系图：直观展示模块间的循环依赖。
我曾经在一个项目里，用 SonarQube 扫出一个 3000 行的函数。你想想看，一个函数里塞了中断处理、协议解析、状态机、日志输出……这谁受得了？
2.2.3 Understand：深度依赖分析
Understand 是收费工具，但它的依赖图非常强大。它能生成调用图、包含图、类继承图。对于识别循环依赖，它几乎是神器。
用法：导入项目后，直接看「Dependency Graph」视图。如果出现环形箭头，那就是循环依赖。
2.3 识别坏味道的实战步骤
光有工具还不够，你得知道怎么看结果。我总结了一套四步法：
- 跑全量扫描：用 Cppcheck 或 SonarQube 对整个项目做一次扫描，生成报告。
- 定位热点文件：按圈复杂度排序，从最高的文件开始看。通常前10%的文件占了80%的问题。
- 分析依赖关系：用 Understand 或 SonarQube 的依赖图，找出循环依赖的模块。
- 人工确认：工具报的不一定都是问题。比如一个中断处理函数复杂度高，但那是硬件要求，不能硬拆。需要你结合业务逻辑判断。
下面这张图，展示了整个诊断流程：
2.4 避坑指南：我曾经踩过的坑
工具用多了，你就会发现有些坑是共通的。我分享几个亲身经历：
- 别迷信工具的阈值：SonarQube 默认圈复杂度阈值是10，但嵌入式里中断处理函数经常超过20。我建议根据项目实际情况调整阈值，别一刀切。
- 循环依赖不一定是代码问题：有时候是头文件包含顺序导致的。先检查 include guard 和前置声明，别急着改架构。
- 上帝类拆分要谨慎：我曾经把一个上帝类拆成10个小类，结果接口调用次数暴增，性能反而下降了。拆之前先画好依赖图，确保拆分后调用路径不增加。
2.5 小结
识别代码坏味道，说白了就是给系统做体检。工具是听诊器，但最终诊断还得靠你的经验。我建议你从今天开始，每周跑一次静态分析，把报告里的问题列出来，挑三个最严重的修掉。坚持一个月，你会发现代码质量有明显提升。
嗯，这一章就到这里。记住，坏味道不可怕，可怕的是你习惯了它的味道。