企业官网建设流程全解析

第1讲：为什么你的项目越来越难维护？

《嵌入式软件架构设计30讲》系列开篇

大家好，我是一名从业15年的嵌入式软件架构师。

这些年做过消费电子、智能家居、穿戴设备、物联网终端以及工业控制产品，也接手过不少“祖传项目”。

有趣的是，无论行业如何变化，大多数团队最终都会遇到同一个问题：

项目刚开始开发得很快，后面却越来越难维护。

新增一个功能需要改十几个文件。

修复一个Bug可能引入三个新Bug。

新人接手项目看不懂。

老员工离职后没人敢改代码。

那么问题来了：

为什么项目会从“简单易维护”一步步变成“谁都不敢碰”？

今天我们就来聊聊这个话题。

一、项目是如何一步步失控的？

先来看一个典型项目的发展过程。

项目刚开始时：

intmain(void){LED_Init();while(1){LED_Toggle();DelayMs(1000);}}

代码不到100行。

逻辑简单。

结构清晰。

开发效率极高。

产品经理看了以后很满意：

挺好，再加个按键吧。

于是：

while(1){KeyScan();LED_Process();}

项目依旧简单。

然后需求继续增加：

• OLED显示
• 蓝牙通信
• 温湿度采集
• 电池管理

代码慢慢变成：

while(1){KeyScan();Sensor_Read();OLED_Update();BLE_Process();Battery_Check();}

看起来问题也不大。

但半年后。

需求越来越多：

• OTA升级
• 手机APP
• 云平台
• 数据同步
• 日志系统

此时工程规模已经从几百行增长到几万行。

开始出现一些奇怪现象：

修改蓝牙代码。

显示功能异常。

修改显示逻辑。

功耗增加。

增加一个传感器。

OTA升级失败。

整个系统仿佛变成了一个连锁反应机器。

二、问题真的出在代码质量吗？

很多工程师会说：

因为代码写得太烂。

这句话对，但不完全对。

因为代码质量差只是表象。

真正的问题是：

系统复杂度失控了

随着需求增加：

• 模块越来越多
• 数据越来越多
• 依赖关系越来越复杂

如果没有架构设计。

系统会像滚雪球一样不断膨胀。

最终变成一团无法拆开的毛线球。

三、最危险的代码：全局变量

很多项目中都会看到这样的代码：

externuint8_tble_connected;externuint8_tbattery_level;externsensor_data_tsensor_data;

刚开始觉得非常方便。

想用数据？

直接访问。

想修改状态？

直接赋值。

开发速度飞快。

但是随着项目变大：

externxxx;externyyy;externzzz;...

全局变量越来越多。

每个模块都可以访问。

每个模块都可以修改。

最后出现的问题就是：

没人知道变量在哪里被修改。

没人知道哪些模块依赖它。

例如：

battery_level=10;

这句代码执行后：

• 电源模块会响应
• 显示模块会刷新
• 蓝牙模块可能发送通知
• 日志模块可能记录事件

看似修改了一个变量。

实际上影响了整个系统。

四、模块之间为什么越来越耦合？

再来看一个例子。

显示模块中：

if(ble_connected){OLED_ShowString("BLE OK");}

很多人觉得很正常。

但这里已经埋下了隐患。

因为显示模块已经依赖蓝牙模块。

换句话说：

显示模块知道了蓝牙模块的内部状态。

未来如果蓝牙逻辑变化：

ble_connected

改成：

ble_state

显示模块也必须修改。

这就是耦合。

耦合最大的特点是：

修改一个模块，影响多个模块。

项目越大。

问题越明显。

五、为什么很多项目后期开发越来越慢？

很多团队都有这种感受：

项目第一版开发用了3个月。

第二版开发用了6个月。

第三版开发用了1年。

为什么？

因为后期开发时间大部分不是在写代码。

而是在理解代码。

举个例子。

新增一个BLE广播功能。

真正写代码可能只需要：

2小时。

但为了确认影响范围：

• 阅读旧代码
• 查找依赖关系
• 回归测试

可能需要：

2天。

这说明什么？

说明系统复杂度已经超过了团队的掌控能力。

六、优秀项目是如何设计的？

我曾参与过一个智能穿戴产品开发。

软件代码量超过20万行。

开发周期接近5年。

期间经历多次功能升级。

系统依然稳定。

核心原因只有三个。

1. 明确模块边界

例如：

BLE模块 显示模块 传感器模块 电源模块 存储模块

每个模块职责单一。

不做越界的事情。

2. 统一接口设计

模块之间只能通过接口访问。

例如：

boolBLE_IsConnected(void);

显示模块可以询问：

蓝牙是否连接。

但不能直接访问内部变量。

3. 数据统一管理

数据有唯一拥有者。

例如：

电池数据 ↓ 电源模块维护 传感器数据 ↓ 传感器模块维护

其他模块只能读取。

不能随意修改。

七、架构设计的本质是什么？

很多人把架构理解得很复杂。

实际上架构设计只有一个核心目标：

控制复杂度

项目小时候。

谁都能开发。

项目长大以后。

决定系统寿命的不是代码能力。

而是控制复杂度的能力。

优秀架构带来的收益：

✅ 新功能容易扩展

✅ Bug容易定位

✅ 新人容易上手

✅ 模块可以复用

✅ 团队协作效率更高

而糟糕架构带来的结果：

❌ 谁都不敢改代码

❌ 修改一个功能影响全局

❌ Bug越来越多

❌ 开发效率越来越低

❌ 项目逐渐失控

八、写在最后

很多工程师工作多年后会发现：

真正限制自己成长的。

已经不是语法。

也不是驱动开发能力。

而是系统设计能力。

从“写功能”到“设计系统”。

这是嵌入式工程师成长过程中最重要的一次跨越。

在接下来的《嵌入式软件架构设计30讲》中，我们将从实际项目出发，系统讲解：

• 高内聚低耦合
• 模块化设计
• 分层架构
• 状态机设计
• 事件驱动架构
• FreeRTOS架构设计
• BLE产品架构设计

希望帮助大家少踩坑，少走弯路。

本讲总结

项目越来越难维护，通常不是因为代码写得差，而是因为：

1. 模块边界不清晰
2. 全局变量泛滥
3. 模块耦合严重
4. 缺少统一接口
5. 系统复杂度失控

记住一句话：

软件架构的本质，不是炫技，而是控制复杂度。

这是成为高级工程师和架构师的第一课。