1. 架构思维破冰：为什么需要软件架构？从混乱到有序的演进之路

说实话，我见过太多嵌入式项目死在「能跑就行」这四个字上。

刚入行那几年，我也觉得架构是虚的。功能写出来、烧进去、能跑，不就完了吗？直到有一次，一个智能家居网关项目，三个人写了三个月，最后联调时谁都不敢动别人的代码——一动就崩。嗯，那时候我才真正明白：没有架构的代码，就是一堆会走路的定时炸弹。

1.1 混乱的起点：没有架构的嵌入式项目长什么样？

先别急着谈理论。我们来看看一个典型的「无架构」项目长什么样。

假设你要做一个温湿度采集器，功能很简单：

• 每 5 秒读一次传感器
• 数据通过串口打印
• LED 指示工作状态

新手通常会这么写：

// main.c — 典型的"面条式"代码
int main(void) {
    init_sensor();
    init_uart();
    init_led();
    
    while(1) {
        // 读传感器
        uint16_t raw = read_sensor();
        float temp = raw * 0.01f;
        
        // 串口打印
        char buf[32];
        sprintf(buf, "Temp: %.2f\n", temp);
        uart_send(buf);
        
        // LED 闪烁
        led_toggle();
        
        // 延时
        delay_ms(5000);
    }
}

这段代码有什么问题？我列几个你品品：

问题	具体表现	后果
耦合过紧	传感器读取、串口输出、LED 控制全揉在 main 里	改一个功能，可能影响所有逻辑
不可测试	想单独测传感器？得跑整个循环	调试靠 printf，效率极低
不可复用	换个传感器型号，main 函数得重写	每个项目从零开始，积累为零
不可扩展	想加个 WiFi 模块？代码结构得大改	功能越多，代码越乱

1.2 架构的本质：把「怎么做」和「做什么」分开

说白了，软件架构就是分而治之。

你想想看，一个嵌入式系统里，无非就这几件事：

• 硬件驱动：怎么读写寄存器、怎么配置外设
• 业务逻辑：什么时候该采集、什么时候该上报
• 通信协议：数据怎么打包、怎么解析
• 任务调度：多个任务怎么轮流执行

好的架构，就是把这些东西拆开，让它们各司其职，互不干扰。

我个人习惯用分层架构来组织代码。还是那个温湿度采集器，重构后大概长这样：

// 分层架构示意
// ========== 硬件抽象层 ==========
// sensor_hw.c — 只负责读写传感器寄存器
uint16_t sensor_read_raw(void) {
    // I2C 或 SPI 读写
    return i2c_read(0x44, 0x00);
}

// ========== 业务逻辑层 ==========
// app_temp.c — 只关心数据处理
float temp_get_value(void) {
    uint16_t raw = sensor_read_raw();
    return raw * 0.01f;  // 转换公式
}

// ========== 通信层 ==========
// comm_uart.c — 只负责数据收发
void comm_send_temp(float temp) {
    char buf[32];
    snprintf(buf, sizeof(buf), "T:%.2f", temp);
    uart_tx(buf);
}

// ========== 主控层 ==========
// main.c — 只做调度
int main(void) {
    while(1) {
        float t = temp_get_value();
        comm_send_temp(t);
        led_heartbeat();
        delay_ms(5000);
    }
}

1.3 从混乱到有序：架构演进的四个阶段

我观察过很多团队，嵌入式软件的架构演进通常经历这四个阶段：

1. 混沌期：所有代码写在一个文件里，全局变量满天飞。项目规模 < 2000 行时还能凑合，超过就崩。
2. 分层期：开始按功能拆文件，驱动、业务、应用分开。但层与层之间还是直接调用，耦合依然存在。
3. 接口期：引入接口概念，层与层之间通过抽象接口通信。换硬件不用改业务代码——这就是接口隔离的雏形。
4. 组件期：每个模块都是独立的组件，有自己的接口、配置、生命周期。组件可以独立测试、独立替换、独立复用。

这个演进过程，说白了就是从「能跑就行」到「好改、好测、好复用」的转变。

1.4 架构的价值：不只是代码，更是团队协作的基石

你可能觉得，小项目不需要架构。我承认，一个人写 1000 行代码，确实不需要什么架构。但现实是：

• 项目会变大
• 人会换
• 需求会变
• bug 会来

好的架构，能让你在以上所有场景里从容应对。

场景	无架构	有架构
换 MCU	重写全部代码	只改硬件抽象层
加新功能	到处打补丁	新增一个模块
新人接手	看代码看到崩溃	看接口文档就懂
定位 bug	全局搜索变量	定位到具体模块
单元测试	几乎不可能	Mock 接口即可

1.5 本章核心：架构思维导图

下面这张图，是我自己总结的嵌入式软件架构思维框架。你可以把它当作后续课程的「地图」：

1.6 本章小结

• 没有架构的代码：耦合高、难测试、难复用、难扩展
• 架构的本质：把「怎么做」和「做什么」分开
• 架构演进四阶段：混沌 → 分层 → 接口 → 组件
• 架构的价值：不只是代码质量，更是团队协作的保障