📚 课程目录第1章架构重构总览

1. 架构重构总览：为什么嵌入式项目需要重构？模块化与低耦合的核心价值

1.1 一个让我失眠的凌晨三点

我记得那是2018年的事。一个智能家居网关项目，代码量大概15万行。客户反馈说设备偶尔死机，重启就好。我凌晨三点被电话叫醒，远程连上去一看——一个中断服务程序里调了 printf，还带了个 while 循环等串口发送完成。嗯，典型的“能跑就行”后遗症。

这个bug其实不难修。真正让我睡不着的是：为什么这种低级问题会流到量产阶段？因为整个代码库像一团毛线——全局变量满天飞，模块之间你中有我我中有你，谁都不敢动别人的代码。说白了，架构已经腐烂了。

从那以后，我养成了一个习惯：每接手一个嵌入式项目，先花一周做架构评估。不是看功能对不对，而是看它能不能被安全地修改。

1.2 嵌入式项目为什么需要重构？

很多人觉得嵌入式软件嘛，跑得稳就行。但现实是，产品需求一直在变。今天加个传感器，明天换个通信协议，后天要支持OTA升级。如果代码架构一开始就没想清楚，后面每改一次都是踩雷。

我总结了几种典型的“重构信号”：

信号	典型表现	后果
修改扩散	改一个功能，三个模块都要动	回归测试成本爆炸
全局变量泛滥	超过50个全局变量，不知道谁在写谁在读	竞态条件、死机、数据污染
头文件地狱	一个头文件include了20个其他头文件	编译慢、循环依赖、改一处全量编译
重复代码	同样的I2C读写逻辑出现在5个文件中	修一个漏四个，bug反复出现
测试困难	想单元测试一个函数，需要模拟整个硬件	覆盖率低，质量靠运气

⚠️ 我曾经踩过的坑： 一个智能锁项目，因为全局变量 g_timer_count 被中断和主循环同时读写，导致锁在极端情况下自动弹开。排查了整整两周。从那以后，我规定所有跨模块数据必须通过接口传递，禁止直接访问全局变量。

1.3 模块化设计的核心价值

模块化不是什么新概念。但在嵌入式领域，它经常被误解成“把代码拆成多个文件”。其实不然。真正的模块化，是每个模块有清晰的职责边界，对外暴露最小接口，内部实现可以独立替换。

你想想看，一个典型的嵌入式系统包含哪些东西？传感器驱动、通信协议、业务逻辑、电源管理、诊断日志……如果这些功能都混在一起，改一个传感器驱动，会不会影响到通信协议？当然会——因为它们在同一个文件里共享了同一个全局缓冲区。

模块化设计要解决的就是这个问题。我习惯用三个维度来评估模块化程度：

内聚性：模块内部的东西是不是真的属于一起？比如，一个“温度传感器模块”应该只做温度相关的事，不应该包含WiFi配置代码。
接口粒度：对外暴露的函数是不是最小必要？我见过一个驱动模块暴露了30个函数，其实外部只需要用3个。剩下的都是内部实现细节。
依赖方向：依赖是单向的还是循环的？循环依赖是架构腐烂的早期信号。

  💡 我的经验法则： 如果一个模块的 .h 文件超过200行，或者 .c 文件超过1000行，大概率是职责过重了。考虑拆分成更小的模块。

1.4 低耦合：让模块之间“礼貌地对话”

低耦合是模块化的自然延伸。两个模块之间耦合度高，意味着一个模块的变化会迫使另一个模块也跟着变。这在嵌入式系统里尤其致命——因为硬件更新换代太快了。

举个例子。我曾经参与过一个车载信息终端项目。最初的设计是：UI模块直接调用GPS驱动模块的 gps_get_position() 函数。看起来挺直接的对吧？但后来GPS芯片换了，接口变了。结果UI模块、导航模块、日志模块……所有直接调用过 gps_get_position() 的地方都要改。

如果当时加一层抽象——比如定义一个 position_provider_t 结构体，里面放函数指针——那么换GPS芯片只需要改驱动模块，上层代码一行都不用动。这就是低耦合的价值。

常见的耦合类型和应对策略：

耦合类型	例子	解耦方式
数据耦合	模块A直接读写模块B的全局变量	通过getter/setter或消息队列传递
控制耦合	模块A设置模块B的内部状态标志	用回调函数或事件驱动
内容耦合	模块A直接访问模块B的内部数据结构	封装数据结构，只暴露操作接口
外部耦合	多个模块依赖同一个硬件寄存器	硬件抽象层(HAL)统一管理

1.5 模块化与低耦合的关系图谱

下面这张图是我自己总结的嵌入式架构重构核心逻辑。它展示了从“发现问题”到“实施重构”再到“持续维护”的完整链路。

1.6 重构不是重写

这一点我必须强调。很多团队一听到“重构”，就想着把代码全部推倒重来。这是最危险的想法。我在项目中见过太多“重构三年，产品死掉”的案例。

真正的重构，是在不改变外部行为的前提下，改善内部结构。说白了，就是“边开车边换轮胎”。每次改动一小块，改完测试，确认没问题再改下一块。

我个人习惯用“微重构”的策略：

先给目标模块写接口文档，明确它对外承诺什么
写单元测试，把当前行为固化下来
小步重构：提取函数、拆分文件、消除全局变量
每改完一个点，跑一遍测试，确保没破坏任何东西
提交代码，合并到主线

💡 一个小技巧： 重构前先用 git blame 看看这个文件的历史。如果某个函数被频繁修改，说明它可能是“热点”，优先处理。如果某个文件三年没人动过，那就别碰它——它可能已经稳定了。

1.7 模块化与低耦合的量化指标

说了这么多，怎么衡量你的架构到底好不好？我平时会用几个简单的指标：

指标	计算方法	健康值
扇入/扇出	一个模块被多少模块调用/调用了多少模块	扇入 < 10，扇出 < 7
全局变量数	统计所有文件中的全局变量	不超过20个
循环依赖数	用工具分析头文件包含关系	0个
模块内聚度	模块内部函数之间的调用密度	> 70%
接口稳定性	一个模块的.h文件在过去3个月被修改的次数	< 3次

这些指标不是绝对的，但它们能帮你快速定位问题区域。比如，如果你发现某个模块的扇出是15，那它很可能承担了太多职责，需要拆分。

1.8 写在前面的话

这门课程一共30章，我会从最基础的模块划分讲起，逐步深入到接口设计、依赖管理、测试策略、重构实战。每一章都会结合我实际项目中踩过的坑和总结出的方法。