内聚性基础：从偶然到功能，你的代码到底有多“粘”
聊到内聚，我得先坦白一件事。刚入行那几年，我根本不在乎这个概念。那时候觉得，只要功能能跑，管它代码怎么组织。结果呢？有一次维护一个老项目，一个.c文件三千多行，里面既有LED闪烁，又有PID计算，还夹杂着几个全局变量做状态同步。改一个bug，修好这里，炸了那里。那个月我加了整整两周的班，就为了理清那一团乱麻。
从那以后，我彻底明白了——内聚性不是学院派的纸上谈兵，它是决定你代码能不能被测试、能不能被维护的命门。
什么是内聚？说白了就是“模块内部的团结程度”
内聚（Cohesion），衡量的是一个模块内部各元素之间结合的紧密程度。你想想看，一个模块里的函数、变量、数据结构，它们是不是都在齐心协力干同一件事？如果是，内聚就高；如果各干各的，内聚就低。
高内聚的模块，职责单一，接口清晰。低内聚的模块，像个杂货铺，什么都有，但什么都不精。
核心观点：内聚性越高，模块的可理解性、可维护性和可测试性就越强。这是嵌入式架构设计的黄金法则之一。
内聚的7个层次：你的代码在第几层？
内聚性从低到高分为7个层次。我习惯把它们分成三档：别用（偶然/逻辑/时间）、凑合用（过程/通信）、推荐用（顺序/功能）。下面这张图可以帮你快速建立整体认知。
逐层拆解：每个层次长什么样？
1. 偶然内聚（Coincidental Cohesion）
这是最差的情况。模块里的几个函数，彼此八竿子打不着。为什么放在一起？因为“刚好都在这个文件里”。
我曾经接手过一个项目，一个叫“utils.c”的文件里，放了CRC校验、延时函数、字符串格式化、还有一段GPIO初始化代码。问原作者为什么放一起？他说“反正都是工具函数”。结果每次改CRC，都要重新编译整个模块，而且根本没法单独测试。
2. 逻辑内聚（Logical Cohesion）
元素在逻辑上属于同一类别，但做的事情完全不同。典型的例子：一个“IO操作”模块，里面同时处理I2C、SPI、UART的读写。
// 逻辑内聚的典型反面教材
int io_operation(int type, int cmd, void *data) {
switch(type) {
case IO_I2C: return i2c_read_write(cmd, data);
case IO_SPI: return spi_transfer(cmd, data);
case IO_UART: return uart_send_receive(cmd, data);
default: return -1;
}
}这种代码的问题在于：每次新增一种接口类型，都要修改这个函数。而且测试时，你没法单独测I2C部分，因为所有逻辑都耦合在一起。
3. 时间内聚（Temporal Cohesion）
元素因为“在同一时间被执行”而组合在一起。最典型的就是初始化函数。
我个人习惯把初始化拆成多个小函数：clock_init()、gpio_init()、uart_init()。而不是写一个巨大的system_init()把所有事情塞进去。这样每个初始化步骤都可以单独测试，也方便在特定场景下跳过某些初始化。
4. 过程内聚（Procedural Cohesion）
元素按特定的执行顺序组合。比如一个状态机处理函数，里面依次处理状态A、状态B、状态C。
过程内聚比时间内聚好一点，因为它体现了流程。但问题在于：这些步骤可能操作不同的数据，职责仍然不够单一。
5. 通信内聚（Communication Cohesion）
所有元素操作同一份数据或同一个硬件设备。这是嵌入式开发中非常常见的层次。
// 通信内聚示例：一个传感器驱动模块
// 所有函数都操作同一个I2C传感器设备
int sensor_init(void);
int sensor_read_temperature(float *temp);
int sensor_read_humidity(float *hum);
int sensor_set_mode(uint8_t mode);这个模块里的所有函数都围绕“同一个传感器”工作。它们共享I2C总线、寄存器地址等数据。测试时，你可以mock掉I2C层，单独测试这个模块的逻辑。
6. 顺序内聚（Sequential Cohesion）
一个元素的输出直接作为另一个元素的输入。数据在模块内部流动，形成一条清晰的链。
// 顺序内聚：数据采集→处理→输出
int data_acquisition(uint8_t *raw);
int data_filter(uint8_t *raw, float *filtered);
int data_format(float *filtered, char *output);这种结构的好处是：每个步骤都可以独立测试。你可以单独测试滤波函数，给它一组已知的输入，验证输出是否正确。
7. 功能内聚（Functional Cohesion）
这是最高层次。模块内的所有元素共同完成一个单一、明确的功能。不多不少，刚刚好。
功能内聚的标志：你能用一句话说清楚这个模块是干什么的。比如“这个模块负责计算CRC32校验值”。如果一句话说不清楚，或者需要加“和”、“或”之类的连接词，那很可能内聚不够。
// 功能内聚：一个纯粹的CRC32计算模块
// 所有元素只做一件事：计算CRC32
uint32_t crc32_init(void);
uint32_t crc32_update(uint32_t crc, const uint8_t *data, size_t len);
uint32_t crc32_final(uint32_t crc);各层次对比速查表
| 层次 | 名称 | 组合依据 | 可测试性 | 推荐度 |
|---|---|---|---|---|
| 1 | 偶然内聚 | 随机放置 | 极差 | ❌ 避免 |
| 2 | 逻辑内聚 | 逻辑类别 | 差 | ❌ 避免 |
| 3 | 时间内聚 | 执行时间 | 较低 | ⚠️ 谨慎 |
| 4 | 过程内聚 | 执行顺序 | 中等 | ⚠️ 谨慎 |
| 5 | 通信内聚 | 共享数据/设备 | 较高 | ✅ 可接受 |
| 6 | 顺序内聚 | 数据流 | 高 | ✅ 推荐 |
| 7 | 功能内聚 | 单一功能 | 极高 | ✅ 强烈推荐 |
避坑指南：我踩过的三个坑
坑一：过度追求功能内聚，导致模块爆炸。我曾经把每个小函数都做成一个模块，结果项目里多了几十个文件，每个文件就两三行代码。内聚是高了，但模块间的耦合反而因为频繁调用而增加了。记住：内聚和耦合要平衡。
坑二：把“通信内聚”当成“功能内聚”。一个传感器驱动模块，如果里面既有温度读取，又有湿度读取，还有模式设置，那它其实是通信内聚，不是功能内聚。真正的功能内聚，应该是一个模块只做“温度读取”，另一个模块只做“湿度读取”。但在嵌入式场景下，考虑到硬件资源限制，通信内聚往往是可接受的折中方案。
坑三：重构时只关注内聚，忽略了接口设计。内聚再高的模块，如果接口设计得乱七八糟，照样没法用。我见过一个功能内聚的CRC模块，接口参数有7个，调用者根本搞不清哪个参数是干嘛的。高内聚 + 清晰接口，才是王道。
小结：内聚性不是目的，可测试性才是
说了这么多，其实我想表达的核心就一句话：提高内聚性，最终是为了让代码更好测、更好改、更好懂。你不需要每个模块都做到功能内聚——在嵌入式开发中，通信内聚和顺序内聚已经能覆盖90%的场景。关键是，你要有意识地避免偶然内聚和逻辑内聚，那才是真正的代码毒瘤。