"屎山"这一术语在软件开发领域是一个非正式的比喻，用来形容那些结构混乱、难以维护、代码质量低下的大型代码库。这个比喻形象地表达了这样的代码积累就像不断堆积的粪便，既不美观也不易于处理。
它通常形成于以下几个原因：
历史遗留：随着时间的推移，项目初期可能因为时间紧迫或资源有限，代码没有遵循最佳实践编写，之后由于各种原因（如需求变更、人员流动）而未能得到适当的重构。 持续堆砌：面对新需求，开发人员选择在现有代码基础上快速添加功能，而不是彻底重构，因为这样做短期内看似更高效，但长期导致代码复杂度和耦合度增加。 技术债务：为了快速交付，团队可能会积累技术债务，即选择了短期利益而牺牲了代码的长期可维护性，这种累积最终形成难以逾越的“屎山”。 知识传递不足：团队成员变动频繁，新成员对旧代码的理解不足，导致难以做出恰当的修改，只能在不了解整体架构的情况下进行局部调整。 重构成本：全面重构需要大量时间和资源，且存在风险，可能导致新问题出现，影响业务稳定性，因此往往被推迟或避免。
2 ”屎山“项目的特点
成本问题，原来以为一个软件工程师的投入就行，结果发现最少要5个起步；以为不需要开发工具和测试设备的投入，结果发现需要天文数字的投入，光AUTOSAR工具链的投入就是上百个w。 时间问题，人员投入的严重不足，伴随着客户的需求越来越多，交付节点不可能完成；同时因为人员和工具的投入不足，前提开发产生的bug数量巨多，解bug的时间投入惊人。自然地，软件交付的节点一而再再而三要延期。 质量问题，从软件开发来说，需求、开发、验证和项目管理都有问题。 - 未与客户进行需求的沟通，没有需求管理，也没有软件的需求文档； - 软件乱改，在不懂原base的功能逻辑前提下，为了弄出基本功能，在已有base上大量屏蔽现有的逻辑；然后收发的信号传输不一致，将原来用于功能A的信号接口当作功能BCD的信号接口；原来Base的无关功能但又会影响基本功能的逻辑被保留。 - 未进行软件测试，让客户验证和调试软件，一个问题可以发几版软件给客户。 - 项目内容均各自的本地电脑管理，未进行统一的数据管理。
3 如何破解 ”屎山“项目
记住尽可能先做好软件项目管理的工作，然后再去干软件开发工作，越”屎山“的项目越是如此，因为越不容易解决的问题，先要让大家认可你的解决思路，然后细究别人看不到的细节，如果一开始埋头细节，别人不了解，而结果问题没解决反而问题更多，那是哑巴吃黄连有苦说不出，你以为解释清楚了，但是别人客户听不懂，那就会误会了。
1) 关于软件项目管理。
首先，所有软件项目相关的内容采用Git进行管理，确保软件版本能够及时上传，有迹可循，当然包括软件交付记录和软件问题管理等文件。
然后，一次软件交付或释放只不做多个问题的修复，尽量只做一个问题的修复，这样的好处就是客户很容易了解修复了什么，同时解决几个问题，碰到问题没解决，还引起了其他问题，反而给自己带来了更多的坑。因此我们采用的软件交付管理策略就是一版软件只针对一个问题释放给客户，同时让客户清晰地了解每版软件的变更点。 再是软件问题管理，在我接手之前，所有的软件问题都是邮件内容的简单回复或会议上的口述。但随着邮件频率越来越高，一下子就变得无法跟踪问题状态了。因此，整一个文件来管理这些软件问题就十分必要，如下示意：
通过对上述三点的梳理和管理，那么基本可以做到内外部对于软件问题信息（原因分析，解决方案，软件版本，释放计划）的对齐，以及双方清晰了解实时的进展。接下来就是去解决具体的技术问题：
对于ECU软件开发，无非三个点：需求、设计和验证。
需求。了解需求的实现状态，虽然得不到答案。但是可以了解哪些需求不是客户要求的，而是”屎山“软件祖传的，做到对软件无关的东西心中有个数。然后去了解出问题的功能，该功能需求实现的状态。 设计。首先是接口，梳理接口的状态和注重接口的影响分析。当你去分析数据时，明明条件都满足，但是结果却不对，不可能现象就是出现了，这时候必须接收现象的正确性，质疑信号的真实性，梳理接口，确保你所看到的信号都是正确有效的。追本溯源，信号的源头要么来自CAN和传感器，要么逻辑运算生成的。另外当变更一个信号的逻辑时，注意信号被使用的情况，或者说是影响分析，有时一个信号逻辑的变化，很可能影响很多逻辑的变化，此时要慎之又慎。然后是逻辑，做最少的逻辑变动去修复问题，明确为什么要做这样的逻辑变动。总之，当一个模型的接口规模达到一定的数量，要去梳理信号将是及其艰巨而耗时的任务，真的称之为”屎山“真的一点都不为过。
验证。让客户进行调试软件测试是件很奇葩的事情，这个没啥多说的，要资源尽快建立软件测试能力，确保验证OK再释放软件给客户。
4 小结
-end-
分享不易，恳请点个【👍】和【在看】
