前言
最近实习中，经常需要基于某个开发板增加或者更新一些功能。
真实项目中的开发逻辑，和自己写个人项目时其实有很大的不同。
个人项目一般比较随心所欲，项目规模也不会特别大。想改一个功能时，很多时候觉得哪里不顺手就直接改了，甚至顺手把周围的代码一起重构掉。
但真实项目一般规模更大，涉及的模块更多，很多代码之间也存在依赖关系，往往牵一发而动全身。
不能为了实现自己的某个需求，就大面积修改原有代码。
很多时候为了兼容之前已经存在的功能，反而需要做出一些取舍，保留原来的逻辑，再额外增加一些兼容处理。
项目增加功能的逻辑
修改少便是美
首先，对于已经存在并且稳定运行的功能，除非你明确知道其中存在某个 Bug，或者当前任务本身就是修复这一部分，否则不要随便修改原有逻辑。
至少在不了解代码背景的情况下，应该先默认：
当前这段代码是有原因才这样写的 。改了就会出 Bug !
不要看到一个判断觉得“这里好像可以简化”，就直接删掉或者重写。
因为有些看起来多余的判断，可能正是为了兼容某个旧版本、特殊硬件或者历史需求而存在的。
如果确实需要修改，最好先确认这段代码的用途，必要时询问原来的提交者或者熟悉这一模块的人。
新增功能时，也应该尽量复用现有代码，在原有逻辑的基础上做最小范围的修改。
能增加一个判断解决，就不要重写整个函数。
能复用已有接口，就不要重新造一套类似的逻辑。
修改范围越大，需要重新测试的内容就越多，也越容易引入新的 Bug。
之前就是把公司项目当个人项目写了，让我修个 Bug，我一口气改了六百多行。
最后喜提加班重写。
当然，“修改少”也不是说永远不能重构。
如果原有设计本身确实存在严重问题，或者已经影响后续开发，那么该改还是要改。
只是这种大范围修改最好作为一个明确的重构任务来做，而不是在增加一个小功能的时候顺手把半个模块都改了。
占用资源要少
新增功能时，还需要特别注意资源消耗。
对于 MCU 来说，比较常见的资源主要包括：
PSRAMSRAMFLASH- 线程栈
- 堆内存
- 硬件外设和其他有限资源
如果增加一个功能后，资源占用出现了比较明显的变化，就应该及时记录并说明。
因为 MCU 和 PC 上运行的软件不一样。
PC 上多占几十 MB 内存，很多时候可能并没有什么明显影响。
但 MCU 的资源通常比较有限，而且这些资源不是你一个功能独占的，而是整个系统、整个团队共同使用的。
如果为了实现自己的一个功能，一下子占用了大量内存或者 FLASH，可能会导致其他模块没有足够的资源可用，甚至让后续功能根本加不进去。
所以不能只关注：
“这个功能能不能跑起来。”
还要关注：
“为了让它跑起来，我到底付出了多少资源成本。”
如果资源增长明显，最好及时和其他人沟通，确认这个成本是否可以接受，有没有更节省资源的实现方案。
有一次就是加了一个厂家的第三方库，FLASH 直接大了 1 MB，差点出问题。
尤其是在嵌入式项目里，一个第三方库、一个新的缓存区，甚至几个尺寸比较大的静态数组，都可能带来非常明显的资源变化。
所以增加功能之后，最好顺手看一下编译结果、Map 文件或者项目提供的资源统计信息。
及时记录
每次增加一个功能或者修复一个 Bug，都应该及时做好版本记录。
最基本的就是使用 Git 提交代码。
不要连续改很多天，最后所有内容堆在一个提交里面。
比较合理的方式是按照功能或者修改目的拆分提交，让每个提交尽量表达清楚：
这一次到底改了什么，为什么要改。
这样以后出现问题时，也更方便使用 git diff、git log、git bisect 等工具追踪问题来源。
除了 Git 提交之外，比较重要的修改最好还要留下相应的说明文档或者更新记录。
例如记录：
- 为什么要增加这个功能。
- 原来的实现有什么问题。
- 具体采用了什么解决方案。
- 修改了哪些模块。
- 是否会影响原有功能。
- 增加了多少
PSRAM、SRAM、FLASH等资源占用。 - 有没有需要特别注意的兼容问题。
Git 主要记录的是：
“代码改了什么。”
而文档更适合记录：
“为什么要这样改。”
这两种信息其实都很重要。
因为过一段时间之后，很多时候你重新看到自己写的代码，连自己都不一定记得当初为什么这么写。
更别说其他接手这部分代码的人了。
总结
在真实项目中增加功能，和自己写个人项目最大的区别之一，就是不能只考虑：
“我这个功能能不能实现。”
还要考虑它对整个项目造成的影响。
每次更新最好尽量兼容原有功能，减少不必要的修改范围。
能小改就不要大改，尤其不要为了增加一个小功能，顺手重构一大片原本正常工作的代码。
同时还要注意资源占用的变化。
如果 PSRAM、SRAM、FLASH 等资源出现明显增长，要及时记录，并和其他人沟通这个成本是否可以接受。
最后，每次修改都应该及时使用 Git 提交，并留下必要的更新记录。
简单来说就是：
少改、少占、留记录。
先保证原来的东西不会坏，再考虑怎么把新的东西加进去。
个人项目可以随心所欲一点。
但在真实项目里，很多时候“能改”并不代表“应该改”。
文章作者：成元
上次更新：2026-07-22