模块化编程思想：模块划分原则、高内聚低耦合、接口设计、头文件规范
说到模块化编程，我脑子里第一个蹦出来的词就是「拆」。
你想想看，一个单片机项目，从几千行到几万行，甚至十几万行。如果所有代码都堆在一个文件里，那调试起来简直是一场噩梦。我早期做项目时就吃过这个亏——一个温控器项目，main.c 写了八千多行，最后改一个参数要全局搜索半天，生怕改漏了哪里。
后来我学乖了。模块化编程，说白了就是「分而治之」。把一个大系统拆成若干个小模块，每个模块各司其职，互不干扰。今天我就把这几年的模块划分心得，掰开了揉碎了讲给你听。
模块划分原则：别拍脑袋，要有章法
模块怎么划？不是你想怎么分就怎么分的。我总结了几条铁律：
- 功能单一原则：一个模块只做一件事。比如 LED 驱动模块，就只管亮灭、闪烁、PWM 调光。别把按键扫描也塞进去。
- 层次清晰原则：硬件抽象层、中间层、应用层，各层之间单向依赖。底层不能调用上层，这是底线。
- 可复用原则：模块要能独立移植。我习惯把模块做成「即插即用」的，换个 MCU 平台，改改底层接口就能跑。
- 接口最小化原则：对外暴露的接口越少越好。能隐藏的细节，坚决不暴露。
核心要点：模块划分的终极目标，是让每个模块都能独立开发、独立测试、独立维护。你改一个模块，其他模块不受影响。
我在项目中遇到过一种情况：有个同事把 ADC 采集、数据滤波、显示刷新全写在一个模块里。后来想换一个滤波算法，结果发现显示逻辑也被牵连了。这就是典型的「耦合过紧」。
高内聚低耦合：听起来玄乎，做起来有套路
这两个词，面试常考，实际开发也绕不开。我用自己的话解释一下：
高内聚：模块内部的东西，彼此关联紧密。比如一个 UART 驱动模块，初始化、发送、接收、中断处理，这些函数都围绕 UART 这个硬件在转。它们之间配合默契，这就是高内聚。
低耦合：模块与模块之间，依赖关系越弱越好。比如你的业务逻辑模块，不应该直接调用 UART 的寄存器操作。它应该通过一个抽象接口来收发数据。
为什么会这样？因为耦合度一高，牵一发而动全身。我曾经维护过一个老项目，里面有个全局变量 g_SystemStatus，被二十几个模块读写。每次改这个变量，我都得把整个工程翻一遍，生怕哪个模块的时序被破坏了。
我的小技巧：写代码前，先画模块依赖图。箭头越少，耦合越低。如果发现某个模块被七八个模块依赖，那就要考虑拆分了。
降低耦合的具体做法：
- 多用回调函数，少用全局变量
- 用消息队列传递数据，而不是直接调用
- 接口参数尽量用结构体，方便扩展
接口设计：好的接口像插座，坏的接口像蜘蛛网
接口是模块对外的「脸面」。设计得好，别人用起来舒服；设计得烂，自己都懒得用。
我总结了几条接口设计原则：
- 命名要自解释：LED_On() 比 led1() 好一百倍。别让人猜。
- 参数要简洁：能传一个结构体，就别传七八个参数。我见过一个函数有 12 个参数，调用的时候自己都数不过来。
- 返回值要明确：成功返回 0，失败返回错误码。别搞什么返回 -1 表示成功，返回 0 表示失败，那会把人逼疯。
- 接口要稳定：一旦发布，尽量不改。实在要改，也要做好版本兼容。
注意：接口设计最忌讳「过度设计」。别为了所谓的「通用性」，搞出一堆抽象层和虚函数表。单片机资源有限，够用就好。
举个例子，一个简单的 LED 模块接口：
/* led.h */
#ifndef __LED_H__
#define __LED_H__
#include <stdint.h>
/* LED 状态枚举 */
typedef enum {
LED_OFF = 0,
LED_ON,
LED_BLINK_SLOW,
LED_BLINK_FAST
} LED_State_t;
/* 初始化 LED 硬件 */
void LED_Init(void);
/* 设置 LED 状态 */
void LED_SetState(LED_State_t state);
/* 获取当前 LED 状态 */
LED_State_t LED_GetState(void);
#endif /* __LED_H__ */你看，这个接口就很简单。使用者不需要知道底层是 GPIO 还是 PWM，也不需要关心寄存器地址。这就是「接口隔离」的好处。
头文件规范：细节决定成败
头文件这东西，看似简单，但坑不少。我见过太多因为头文件乱写导致的编译错误。
我的头文件规范：
| 规范项 | 要求 | 说明 |
|---|---|---|
| 头文件保护 | 必须使用 #ifndef/#define/#endif | 防止重复包含，格式：__模块名_H__ |
| 包含顺序 | 先标准库，再第三方，最后自己 | 避免隐藏依赖 |
| 只放声明 | 不要放函数定义 | 定义放 .c 文件 |
| 最小包含 | 只包含必要的头文件 | 别图省事 #include "all.h" |
| extern 使用 | 全局变量用 extern 声明 | 别在头文件里定义变量 |
避坑指南：我曾经在一个项目里，发现某个头文件被包含了 30 多次，每次编译都要花 5 分钟。后来一查，原来是某个模块的 .h 文件里 #include 了半个工程的头文件。从那以后，我严格执行「最小包含」原则。
另外，头文件里尽量别放宏定义。宏定义容易污染命名空间。能用枚举和 const 变量，就别用宏。嗯，这里要注意，有些场景宏确实方便，比如条件编译，但能少用就少用。
最后说一句：模块化编程不是一蹴而就的。你可以在项目初期就规划好模块划分，也可以在重构时逐步优化。关键是养成习惯——写代码前，先想清楚「这个功能该放哪个模块」。
记住一句话：好的架构，是改出来的，不是设计出来的。先跑起来，再慢慢优化，这才是实战派的作风。