1、课程导论与架构思维：什么是嵌入式软件架构？为什么需要文档？架构设计的核心原则。

各位同学，欢迎来到《嵌入式软件架构文档编写与模板架构设计实战》的第一章。

我做了十几年嵌入式开发，带过不少团队，也看过太多项目从意气风发走向一地鸡毛。说实话，大部分问题都不是代码写错了，而是从一开始就没想清楚架构。今天咱们就来聊聊这个根本问题。

1.1 什么是嵌入式软件架构？

先问大家一个问题：你理解的嵌入式软件架构是什么？

很多人觉得，架构就是画几张框图，把模块分一分，然后就开始写代码。我以前也这么干过。结果呢？项目中期发现模块之间耦合得死死的，改一个功能要动三个模块，测试用例全废了。

嵌入式软件架构，说白了就是一套决策体系。它决定了你的代码怎么组织、模块之间怎么通信、资源怎么分配、错误怎么处理。它不是一张静态的图，而是一系列设计约束的集合。

举个例子。一个简单的温控器，你可以把所有代码写在一个 while 循环里。这叫“裸奔架构”。但如果你要做的是工业级温控器，需要支持远程配置、故障诊断、OTA 升级，那你就得考虑分层架构、状态机、消息队列。同样的硬件，不同的架构，决定了产品的天花板。

1.2 为什么需要文档？

这个问题我经常被问到。尤其是年轻工程师，总觉得写文档是浪费时间。“代码就是文档”这句话害了不少人。

我经历过一个真实的教训。几年前做一个车载项目，团队 6 个人，干了 8 个月。架构是我画的，但当时项目紧，没写文档，只在白板上讲了一遍。三个月后我出差，现场出了问题，新来的同事看着代码完全不知道当初为什么这么设计。他不敢改，只能往上堆补丁。等我回来，代码已经成了一团乱麻。

文档不是写给领导看的，是写给未来的自己看的。

文档类型	解决什么问题	我踩过的坑
架构设计文档	让团队理解整体方案	没写文档，新人接手直接重写
接口规范文档	避免模块间联调冲突	接口改了没通知，联调三天三夜
决策记录	记录为什么这么选	半年后自己都忘了当初的权衡
测试策略文档	保证质量可追溯	测试用例和设计脱节，漏测严重

你想想看，一个嵌入式项目动辄几十万行代码，涉及多个 MCU、传感器、通信协议。没有文档，你怎么保证团队里每个人对架构的理解是一致的？

1.3 架构设计的核心原则

这部分我结合自己的项目经验，给大家总结几条最实用的原则。不是教科书上的空话，都是实战中摔出来的。

原则一：分层清晰，职责单一

这是嵌入式架构的基石。我习惯把系统分成三层：硬件抽象层（HAL）、中间件层、应用层。每一层只做自己的事，不越界。

• HAL 层：封装寄存器操作，提供统一接口。换 MCU 时只改这一层。
• 中间件层：协议栈、文件系统、任务调度。不依赖具体硬件。
• 应用层：业务逻辑。调用中间件接口，不直接操作硬件。

我曾经在一个项目中看到有人在应用层直接操作 GPIO 寄存器。嗯，后来换芯片的时候，那部分代码几乎重写了一遍。

原则二：模块间解耦，接口契约化

模块之间不要直接调用，要通过接口。接口就是你们的合同。合同定了，各干各的，互不干扰。

我常用的做法是：每个模块定义一个头文件，里面只暴露函数声明和数据结构，不暴露实现细节。这样即使内部重构，只要接口不变，其他模块不受影响。

原则三：关注点分离，把变化封装起来

嵌入式系统里，变化最多的是什么？硬件、通信协议、业务需求。把这些变化点找出来，用抽象层隔离开。

举个例子。一个数据采集系统，传感器可能从 I2C 换成 SPI，或者从模拟量换成数字量。如果你在业务代码里直接调用 I2C 读写函数，那每次换传感器都得改业务代码。正确的做法是定义一个 sensor_read() 接口，底层实现可以随时换。

原则四：可测试性优先

这个原则很多人忽略。嵌入式代码难测，但架构设计可以降低测试成本。

• 模块间通过接口交互，方便 mock
• 业务逻辑和硬件操作分离，可以在 PC 上跑单元测试
• 状态机显式化，测试用例可以覆盖所有状态转换

我现在的习惯是：写代码之前先想好怎么测。如果某个模块很难测，那它的设计大概率有问题。

原则五：简单比“优雅”更重要

这一点我特别想强调。很多工程师喜欢炫技，设计模式一套一套的。但在嵌入式领域，资源有限，复杂度是最大的敌人。

能用数组解决的问题，别用链表。能用状态机解决的问题，别上 RTOS。能用轮询解决的问题，别用中断。当然，这不是绝对的，但你要问自己：这个复杂度带来了什么好处？值不值得？

1.4 架构思维：从“写代码”到“设计系统”

最后我想聊聊思维方式的转变。很多嵌入式工程师刚入行时，关注的是“这个功能怎么实现”。但架构师关注的是“这个系统怎么组织”。

我个人的体会是，架构思维需要刻意练习。每次开始一个新项目，别急着写代码。先问自己几个问题：

• 这个系统最核心的 3 个功能是什么？
• 哪些部分是可能变化的？
• 如果硬件换掉，要改多少代码？
• 测试怎么覆盖？

想清楚了再动手。磨刀不误砍柴工，这句话在嵌入式开发里尤其适用。