1. 课程导入

各位工程师朋友，大家好。我是你们这门课的老朋友。

咱们开门见山。嵌入式开发做到一定年头，你一定会遇到一个坎：代码改不动了。

不是功能实现不了，而是每加一个新需求，就得把老代码翻个底朝天。改一个定时器参数，结果串口打印乱码了；调一个 GPIO 电平，结果整个状态机跑飞了。代码像一团煮过头的意大利面，你扯起一根，带出来一大坨。

这种代码，圈内有个形象的称呼——“面条代码”。

1.1 面条代码：我们曾经都吃过这个亏

我刚入行那会儿，接手过一个智能家居网关项目。前任工程师很厉害，一个人写了八千多行 C 代码，全部堆在 main.c 里。全局变量满天飞，函数之间互相调用，没有任何层次感。

我印象最深的一个场景：为了修一个 Wi-Fi 重连的 bug，我顺着一个 extern uint8_t flag_connect 找了整整两天。这个 flag 被 7 个不同模块读写，有中断里改的，有主循环里改的，还有定时器回调里改的。你根本不知道它下一秒是什么值。

这就是典型的耦合过重。模块之间像连体婴儿，谁也离不开谁，谁也说不清谁。

为什么会这样？说白了，很多嵌入式工程师早期都是从“点亮一个 LED”开始的。功能简单，代码少，怎么写都行。但项目一旦膨胀到几万行、几十万行，这种“野蛮生长”的写法就会彻底失控。

1.2 乐高积木：模块化分层架构的核心理念

那怎么破局？

我个人的答案是：把代码当成乐高积木来搭。

你想想看，乐高积木为什么好玩？因为每一块积木都有标准的接口，可以独立生产，可以自由组合。你想搭一个城堡，不需要自己烧砖头；你想换一个屋顶，不需要把整个地基拆了。

模块化分层架构，本质上就是给嵌入式软件定义一套“积木规则”：

• 模块化：每个功能单元独立成块，高内聚、低耦合
• 分层：按职责划分层级，上层依赖下层，下层不依赖上层
• 接口隔离：模块之间只通过定义好的接口通信，不直接访问内部数据

这样做的好处，我在一个车载 OBD 项目中体会特别深。当时我们需要同时支持 CAN、K-Line、J1939 三种协议。如果按面条代码的写法，那得写三套几乎重复的业务逻辑。

但我们做了分层：底层抽象成统一的 bus_read() / bus_write() 接口，中间层做协议解析，上层做业务处理。后来客户要求新增一个 DoIP 协议，我们只花了三天就搞定了——底层加一个驱动，上层业务代码一行没改。

1.3 从“面条”到“积木”的思维转变

这个转变，说起来容易，做起来难。难的不是技术，是思维习惯。

我见过很多工程师，明明知道模块化好，但一写代码就回到老路。为什么？因为“先跑起来再说”的惯性太强了。

这里我分享三个关键的思维转变：

面条代码思维	乐高积木思维
“先实现功能，后面再重构”	“先定义接口，再填充实现”
“这个变量就几个地方用，直接全局吧”	“数据属于模块内部，通过接口传递”
“这个函数顺便做一下日志输出”	“一个函数只做一件事”
“底层驱动直接调用上层回调”	“依赖倒置，上层定义接口，底层实现”

我曾经带过一个团队，接手一个遗留的智能电表项目。代码里有一个 system_process() 函数，足足 1200 行。里面包含了按键扫描、LCD 刷新、计量数据处理、通信协议解析……你能想到的它都有。

我们花了两个星期，把它拆成了 12 个独立模块。每个模块不超过 150 行。拆完之后，原来一个 bug 要修三天，现在半天就能定位并修复。团队士气一下子就上来了。

1.4 本章知识体系总览

为了让你对这门课的整体脉络有个直观印象，我画了一张图。它展示了从“面条代码”到“乐高积木”的完整转变路径，以及我们后续要讲的核心知识点。

1.5 这门课能给你什么

这门课不是讲理论。我会带着你，从实际项目出发，一步步搭建一个完整的模块化分层架构。

我们会从最基础的分层原则讲起，然后深入到接口隔离设计、依赖注入、状态机封装、驱动抽象、单元测试等实战内容。每一章都有代码示例，每一章都有我在项目中踩过的坑。

嗯，说了这么多，其实就是一句话：别让代码成为你的负担。从今天开始，我们一起把“面条”变成“积木”。