1. 课程导入
做了十几年嵌入式，我见过太多项目从意气风发走向寸步难行。刚开始大家都觉得「先跑起来再说」，结果半年后连加个LED闪烁都得提心吊胆。为什么会这样？
说白了，就是耦合在作祟。
1.1 耦合的根源：谁在制造混乱？
耦合不是一天形成的。我习惯把它的根源归结为三个层面：
| 层面 | 典型表现 | 我见过的真实案例 |
|---|---|---|
| 代码层面 | 全局变量满天飞、函数直接操作硬件寄存器 | 一个全局结构体被20个模块读写，改一个字段崩一片 |
| 模块层面 | 驱动层直接调用业务逻辑、中断服务程序里做协议解析 | 换个传感器型号，要改三个驱动文件加两个业务文件 |
| 架构层面 | 没有分层、没有接口、没有依赖方向 | 硬件工程师改个引脚映射，软件组加班两周 |
核心观点：耦合的本质是「不该知道的事知道了」。驱动层不需要知道业务层的状态机，业务层也不该直接操作GPIO寄存器。
1.2 紧耦合的典型症状：你的项目「病」了吗？
我总结了一套自检清单，你可以对照看看：
- 改一处，崩一片 —— 修改一个.c文件，导致五个模块重新编译
- 单元测试写不了 —— 想测一个函数，得先模拟整个硬件环境
- 新人上手慢 —— 代码像一团乱麻，理不清依赖关系
- 移植成本高 —— 换个MCU平台，几乎要重写所有代码
- 调试靠猜 —— 出了问题不知道是驱动层还是业务层导致的
避坑指南：我曾经接手过一个智能家居项目，代码里有个全局变量叫g_system_flag，被32个函数读写。为了加一个「低电量提示」功能，我花了三天才理清这个变量在哪些地方被修改了。嗯，从那以后我再也不允许项目里出现「万能全局变量」。
1.3 从单体到模块化：演进之路
嵌入式架构的演进，其实就是一部「解耦史」。我把它分成四个阶段：
- 单体阶段 —— 所有代码堆在一个main.c里，变量随意定义，函数随意调用。好处是快，坏处是「写完就跑路」。
- 函数拆分阶段 —— 开始按功能拆函数，但全局变量还是共享的。说白了就是「换汤不换药」。
- 模块化阶段 —— 按驱动层、中间层、应用层分层，模块间通过接口通信。这是目前大多数成熟项目的做法。
- 组件化阶段 —— 每个模块都是独立的组件，可以单独编译、测试、替换。依赖注入和接口隔离是核心手段。
我的建议：如果你的项目还在阶段1或阶段2，别急着上高大上的设计模式。先把全局变量收进结构体，把硬件操作封装成接口，这一步做好了，后面的事就顺了。
1.4 一张图看懂：耦合的演进与解耦路径
下面这张图展示了从单体到组件化的演进过程，以及每个阶段的耦合特征：
1.5 一个真实案例：从「跑起来」到「跑不动」
我记得2018年参与过一个车载T-Box项目。刚开始团队只有三个人，大家觉得「先跑起来再说」。结果呢？
- 第三个月：代码量突破2万行，全局变量超过50个
- 第六个月：加一个CAN报文解析功能，需要改6个文件
- 第九个月：客户要求换4G模组，评估工期——三个月
- 第十二个月：核心开发人员离职，新人完全看不懂代码
教训：「先跑起来」没错，但跑起来之后一定要及时重构。我现在的习惯是：每完成一个功能点，花10分钟检查有没有引入不必要的耦合。这10分钟，能省下后面10小时的调试时间。
1.6 本章小结
耦合是嵌入式项目「越做越烂」的根源。它从代码层面的全局变量开始，蔓延到模块间的强依赖，最终导致整个架构僵化。从单体到模块化，再到组件化，每一步都是在和耦合做斗争。
接下来的章节，我会带你一步步拆解这些耦合，用接口隔离和依赖注入的手段，让代码重新变得清爽、可测试、可维护。准备好了吗？