一、架构总览：什么是嵌入式软件架构？为什么内聚和耦合如此重要？
说实话，我见过太多嵌入式项目死在「能跑就行」这句话上。
刚入行那几年，我也觉得架构是虚的。代码能跑、功能正常，不就够了？直到有一次，一个智能家居项目，前期开发只用了两个月，后期维护却花了整整一年。改一个传感器驱动，要牵连五个模块重新编译。加一个新功能，整个团队要开会三天讨论会不会把老功能搞崩。
嗯，从那以后，我再也不敢轻视架构设计了。
1.1 嵌入式软件架构到底是什么？
说白了，架构就是代码的组织方式。它决定了你的程序里，谁该做什么，谁可以调用谁，数据怎么流动。
我个人的理解更直白一些：架构是你在写第一行代码之前，对系统做的「分工」和「约定」。
嵌入式软件架构的核心三要素：
- 模块划分 —— 把功能拆成独立的单元（驱动层、中间件、应用层）
- 接口定义 —— 模块之间怎么通信（函数指针、消息队列、共享变量）
- 依赖管理 —— 谁依赖谁，谁不能依赖谁（分层、倒置、解耦）
你想想看，一个没有架构的嵌入式项目，就像一堆积木随便堆在一起。今天能站稳，明天加一块可能就塌了。而好的架构，是给每块积木一个固定的位置和连接方式。
1.2 为什么内聚和耦合如此重要？
这两个词，我几乎每次评审代码都会提。它们不是学术概念，而是实实在在影响你加班时间的东西。
| 概念 | 定义 | 好与坏 | 我见过的真实案例 |
|---|---|---|---|
| 高内聚 | 一个模块只做一件事，且把所有相关的东西放在一起 | ✅ 好：UART驱动只管收发，不掺和协议解析 | 有人把LED闪烁逻辑写在定时器中断里，结果改闪烁频率要动中断服务函数 |
| 低耦合 | 模块之间依赖少，改一个不影响另一个 | ✅ 好：应用层通过接口调用驱动，不直接操作寄存器 | 一个项目里，业务逻辑直接调用HAL库的全局变量，换芯片时全盘重写 |
| 低内聚 | 一个模块塞了太多不相干的功能 | ❌ 坏：一个.c文件里既有WiFi驱动，又有温度换算，还有日志打印 | 维护这种代码，你改一行要担心另外两处会不会炸 |
| 高耦合 | 模块之间紧密绑定，牵一发而动全身 | ❌ 坏：模块A直接访问模块B的内部结构体成员 | 有一次我改了一个结构体字段顺序，结果三个模块编译报错 |
我曾经踩过的坑：
一个车载诊断项目，我把CAN报文解析和故障码处理写在了同一个模块里。后来诊断协议升级，报文格式变了。我本以为只改解析部分就行，结果故障码处理逻辑也跟着崩了。因为两者共用了一个全局状态机，牵一发动全身。那次加班到凌晨三点，我就发誓：以后模块之间，能通过接口就别共享变量，能分层就别混在一起。
1.3 课程目标与学习路径
这门课不是讲理论，是讲实战。我会带着你，从实际项目出发，一步步把内聚和耦合这两个概念落地到代码里。
学完这门课，你能做到什么？
- 拿到一个需求，能快速画出模块划分图
- 写代码时，能判断「这个函数该放这里还是那里」
- 评审别人的代码，能一眼看出耦合过紧的地方
- 面对芯片换型、协议升级，能做到「改一处，不影响全局」
学习路径是这样的：
- 前5章：打好基础，搞懂内聚和耦合的本质，学会用耦合度矩阵量化分析
- 第6-15章：分层架构实战，从驱动层到应用层，每一层怎么设计接口、怎么控制依赖
- 第16-25章：进阶模式，事件驱动、状态机、组件化、微架构，应对复杂系统
- 第26-30章：工程落地，代码评审清单、重构策略、自动化检查工具
我的建议：
别跳着看。每一章的代码示例，最好自己动手敲一遍。嵌入式架构这东西，光看是学不会的。你亲手拆过一个耦合过紧的模块，下次写代码时自然就会避开。
1.4 本章知识体系总览
下面这张图，是我自己画的知识结构。它把本章的核心概念串在了一起。你可以把它当作整个课程的地图。
这张图里，我把内聚和耦合分别展开。左边是内聚的层级，从最好的功能内聚到最差的偶然内聚。右边是耦合的层级，从最好的数据耦合到最差的内容耦合。底部是课程目标。你每次觉得代码「乱」的时候，回来看看这张图，基本能找到问题出在哪。
记住一句话：
内聚是「把自己的事做好」，耦合是「别管别人的事」。这两点做到了，架构不会差到哪里去。