📚 课程目录第1章架构思维导入

1. 架构思维导入：为什么需要软件架构？从“写代码”到“搭系统”的思维转变

很多刚入行的嵌入式工程师，包括当年的我，都曾有过一个朴素的想法：“代码能跑就行，要什么架构？”

说实话，这个想法在项目只有几百行代码时，确实没什么大问题。但当你面对的是一个包含传感器驱动、通信协议栈、任务调度、电源管理、OTA升级的复杂系统时——没有架构，代码就是一团乱麻。

我见过太多项目，前期“快速出活”，后期“改一个bug引出三个新bug”。原因很简单：你只是在写代码，而不是在搭系统。

  核心观点： 软件架构不是“设计文档”，而是系统的骨架。它决定了代码的可维护性、可扩展性、可测试性，以及——你的周末能不能安心休息。

我个人习惯把嵌入式开发者的成长路径分为三个阶段。你可以对照一下，自己现在处在哪个位置。

阶段	思维模式	典型行为	项目规模上限
阶段一：代码堆积者	“功能优先，能跑就行”	所有逻辑写在一个main.c里，全局变量满天飞	~2000行
阶段二：模块拆分者	“按功能拆文件，减少耦合”	开始分driver、app、hal目录，但接口定义随意	~2万行
阶段三：系统架构师	“关注层次、接口、数据流、扩展性”	先画架构图，再写代码，接口文档先行	10万行以上

你想想看，一个10万行的项目，如果没有清晰的架构，新同事入职后光看懂代码就要两个月。更别提后期维护了——那简直是噩梦。

我的经验： 我曾经接手过一个智能家居网关项目，前任工程师把所有代码塞进3个文件里。我花了整整一周，才理清数据流是从哪到哪的。后来我花了三周重构，拆成12个模块，每个模块都有明确的接口。重构之后，新功能开发速度反而比之前快了。

有人可能会说：“架构是互联网后端的事，嵌入式资源受限，搞那么复杂干嘛？”

嗯，这里要注意。嵌入式系统有几个特点，决定了架构设计比纯软件更重要：

避坑指南： 我曾经在一个工业控制项目中，因为前期没有定义好模块间的接口契约，导致驱动层和应用层互相依赖。后来要换一个传感器型号，结果发现应用层代码里直接调用了传感器的I2C读写函数。改一个传感器，改了6个文件。这就是没有架构的代价。

说白了，架构设计就是两件事：分层和解耦。

分层，是把系统按职责切分成不同的层次。比如经典的嵌入式三层架构：

解耦，是让层与层之间、模块与模块之间，只通过定义好的接口通信。接口就是契约——你承诺输入什么，我保证输出什么。

下面这张图，是我个人习惯使用的嵌入式软件分层架构参考：

你看，每一层只负责自己的事。应用层不需要知道I2C的寄存器地址，HAL层不需要关心业务逻辑。这就是架构的价值。

我总结了一个简单的原则，叫“三个一”，适合刚接触架构设计的工程师：

我的习惯： 我现在每接手一个新项目，第一件事不是看代码，而是先找架构图。如果没有，我就自己画。画完之后，再去看代码，效率高很多。你也不妨试试。

我记得有一个做智能门锁的项目，团队一开始只有两个人，代码量不大，大家觉得“架构太浪费时间”。结果产品迭代到第三版时，代码膨胀到3万行。新来的工程师想加一个“低电量提醒”功能，结果发现：

最后，加一个简单的功能，花了整整两周。测试还发现，因为修改了电量检测的代码，意外影响了门锁的响应时间——因为它们在同一个中断服务函数里。

这就是没有架构的代价。说白了，前期省下的时间，后期要加倍还回去。

避坑指南： 我曾经在一个项目中，因为前期没有定义好模块间的接口，导致后期联调时，驱动层和应用层互相“甩锅”。驱动说“我数据已经发上去了”，应用说“我没收到”。最后发现，是接口的数据格式定义不一致——驱动发的是小端序，应用收的是大端序。如果前期有接口文档，这种问题根本不会出现。

架构思维不是一天练成的。但你可以从今天开始，做三件小事：

记住：写代码是手艺，搭系统是工程。 从“写代码”到“搭系统”，差的不是技术，而是思维。