00 阅读提醒

屎山！你写的代码，正在逼疯下一个软件工程师！！！

朋友们，今天聊点有味道的。

不是天气，不是刹车踏板，是——屎山。

对，就是那个你每天打开IDE，连上调试器，看着ECU里那坨跑了好几年的代码，想把手里的CAN盒从车窗扔出去的东西。

每个嵌入式工程师，无论做车身域还是动力域，无论写BMS还是VCU，无论年薪15万还是50万，终其一生，都在干同一件事：

在屎山上，拉新的屎。

01 屎山，是怎么拉出来的？

每个项目，开局都是贞观之治。

架构图干净得像整车线束图，函数命名有盛唐遗风：Bms_GetCellVoltage()，坦荡如砥，一眼见底。

Git提交记录（如果甲方允许用Git的话）读起来像《贞观政要》，每一条都是“纳谏”与“整改”。

那时候没有屎山，因为所有人都住在同一个帐篷里——三个人的项目组，一个写应用层，一个写底层，一个既写应用层又写底层还兼职测试和刷写。

然后，项目SOP了。

人多了，分工细了，代码开始“三省六部制”了。

应用层说底层驱动接口不规范，底层说应用层乱传参，系统说你们都别吵了我只要CAN报文能按时发出去。标定工程师在旁边默默说：这个MAP能不能再加一版？

于是代码里出现了第一行妥协：

/* 先这么写，以后再优化 */      if (u8GearPos == 1U) {         /* P挡 */      } else if (u8GearPos == 2U) {          /* R挡 */     } else if (u8GearPos == 3U) {          /* N挡 */      }/* TODO: 重构 */

那个TODO，就是安禄山。

它不可怕。可怕的是三年后，没人记得这个u8GearPos到底有没有可能是0，也没人敢删那个else if——因为删了万一有车挂不上挡呢？

02 每个屎山背后，都有一个催命的项目节点

系统工程师：这个信号加一下。底层：加个CAN ID。应用层：我不管，我只要数据。测试：这啥啊，怎么实车报故障了？项目经理：明天SOP。

于是你写下了：

if (u8GearPos == 1U) {          /* P挡 */      } else if (u8GearPos == 2U) {         /* R挡 */      } else if (u8GearPos == 3U) {          /* N挡 */      } else {          /* 这里不能删，删了会报DTC */          /* 我也不知道为什么会进来，但实车测过，进来就不报故障 */      }

你品，你细品。

每个else if都是一次妥协，每个/* 这里不能删 */都是一座墓碑。

技术债像藩镇割据，每个模块都有自己的节度使（当初写代码的那个人），每个bsp_driver.c里都藏着一个不交税的飞地。

新人进来像流放岭南——make要半小时，README比《史记》还厚，最后一页写着“如有问题请联系XXX（已离职）”。

你联系一个试试？

03 屎山考古学：你挖的不是代码，是前任的骨灰

每个接手屎山的人，都是考古学家。

你用git blame（如果甲方允许用Git的话）挖掘历史，在注释里寻找古人的箴言：

· “此函数有副作用，慎用。”· “别动，动了会死。”· “我也不知道为什么这么写，但实车跑了一年。”· “TODO: 优化（2026-03-15）”· “此处延时50ms，少1ms总线会丢帧，多1ms客户会投诉。”· “这个全局变量被三个中断和两个任务同时改，别问，问就是能跑。”

联系人已离职。微信头像已灰。钉钉消息已读不回。

你看着三千行的App_MainTask()，MISRA-C看了都想报警。

你打开StdPeriph_Driver，2010年的库。你问为什么不换？因为换了要重新过EMC。

你问为什么不重构？因为旧项目在量产，新项目在开发，底层要复用，标定不能停。

像迁都，说着容易，真迁起来，六朝古都的坟头都得刨一遍。

04 重构？不，那是迁都

总有勇士想重构。

小王，入职三个月，满腔热血，写了一份《关于应用层模块重构的若干意见》。

他像王安石，想变法，想青苗法（统一接口），想募役法（单元测试）。

结果触动保守派（老员工）利益，被御史台（技术总监）弹劾，最后调去维护legacy-platform——一个用8位单片机跑CAN通信的老平台，编译器还是Keil C51。

老张，技术总监，决定渐进式改革。

他像张居正，搞一条鞭法（统一编码规范），考成法（代码评审）。

半年后，他自己被“考成”掉了——因为老板要的是下个月SOP，不是三年后的代码洁癖。

真正的重构，需要皇权（OEM）背书，需要流血（删代码），需要迁都（换芯片平台）。

但大多数公司，只想裱糊，不想革命。

05 屎山生态：数字封建制

最可怕的不是屎山本身，是屎山生态。

· 有专门的人“考古”（维护老平台）· 有专门的人“填坑”（打补丁）· 有专门的人“祭祀”（写文档，但没人看）· 还有一群人，靠屎山吃饭，形成既得利益集团

这时的代码库，已经是一个数字封建王朝。

每个模块是诸侯国，每个C文件是封地，StdPeriph_Driver是蛮族——庞大，混乱，不可名状，且无法删除。

康威定律说：系统架构反映组织沟通结构。

翻译成人话：公司越乱，代码越屎。

朝令夕改的需求 → 补丁式开发频繁的组织架构调整 → 模块边界混乱考核短期KPI → 技术债留给下一任不敢删代码 → 谁删谁背锅

于是代码库变成地层学：寒武纪的寄存器操作，侏罗纪的HAL库，白垩纪的AUTOSAR，第四纪的模型生成代码。

新人进来像考古学家，用git blame挖掘历史，在注释里寻找古人的箴言。

06 如何与屎山和平共处？

既然屎山不可避免，如何与它共存？

第一，承认屎山是常态。代码如文明，没有永垂不朽。Linux内核也逃不过，只是屎得比较优雅。

第二，做渐进式改良，不做激进革命。别想着重构，想着“绞杀者模式”——新功能新代码，老功能慢慢替换。像罗马，不是一天建成的，也别想一天拆完。

第三，写注释，但要写对。别写“此函数实现用户逻辑”，写“这里有个坑，因为2019年某次EMC整改，必须加这个延时”。后人考古时，会给你烧柱香。

第四，接受不完美。屎山之所以是山，因为它承载了业务。没有屎山的公司，要么没业务，要么已经死了。

07 最后说两句

屎山不是耻辱，是勋章。

它证明这个系统活过，迭代过，承载过真实的业务和用户。

干净的代码像博物馆，好看，但没人住。

屎山像老城，脏乱差，但有人在里面生活。

所以，下次你接手一座屎山，别急着骂。

先接上CAN盒，看看报文，读读那些年久失修的注释。

你会发现，每一行烂代码背后，都有一个赶SOP的深夜，一个妥协的系统工程师，一个背锅的底层工程师。

你正在考古一个数字文明的兴衰。

而你，也是下一个屎山的奠基人。

但说真的。

屎山不是某一个人的罪。

是时间的复利，是组织的熵增，是每一个“先这样吧”的总和。

它不优雅，不体面，甚至不堪入目。

但它是真实的——真实的需求，真实的工期，真实的取舍，真实的人，在真实的压力下，做出的真实妥协。

我们嘲笑屎山，是因为我们站在后来者的位置上。

可回到当年那个赶SOP的深夜，面对“明天必须出样车”的通知，你确定自己能写出比前任更干净的代码吗？

所以，别急着推倒它。

先读懂它。

读懂了，你才知道哪些是垃圾，哪些是地基。

真正的工程师，不是从不写烂代码的人，而是愿意在烂代码上，种一朵花的人。

愿你我，都是种花的人。

后记：本文写作过程中，作者的IDE崩了三次，编译一次要八分钟，map文件占了2.7M，#define改了八百行。

但作者依然爱着这个行业——因为屎山之上，总有人在种花。

愿天堂没有屎山，愿人间少点项目节点。

（不是）

我知道你看完本文就退出的了，就算收藏也是吃灰的，不如你点个转发、点赞和在看再走，我是会很感激你的哦！