在 如何破解”屎山“项目（上）介绍了”屎山“项目的整体情况以及如何破解这个”屎山“项目的一些思路，本文再分享在深入细节后的一些发现。首先，这个”屎山“项目软件开发的实际状态是这样的：- 无软件变更文档，模型和代码中都没有变更记录的注释；
- 软件变更分配采用拼凑大法，屏蔽大法和写成定值大法；
- 模型生成的代码被手动修改，有为了编译通过，也有是图省事，直接修改生成代码的逻辑。
1 接口信号
第一个我踩的坑是CAN通讯的接口信号，原来以为只是CAN报文ID有过手动修改，在这样的认知下，我以为的正常情况应该像下图左侧这样子。因此我以为CAN信号3_温度1和CAN信号4_温度2是没有被使用。
当我使用了CAN信号3_温度1和CAN信号4_温度2接收温度1和温度2信号后，问题出现了。后来查了好久才发现：信号1_电压和信号2_电流的输入源是CAN信号3_温度1和CAN信号4_温度2，因此当我使用了正确的用法后，把原来的信号1_电压和信号2_电流的输入源干没了。![]()
后面彻底梳理之后，发现为什么会这样做，主要问题点在于：修改者对于功能不了解，未考虑温度1和温度2对后续功能的重要影响，以及对接口的处理逻辑了解不够深入，即如果新增这两个信号，都需要做哪些软件变更，从而使用了拼凑大法去解决当时面临的眼前问题，把问题风险留给了后来的接锅侠。![]()
这里用一个例子来说明问题，假设有这样一个逻辑判断，如下所示：
![]()
当修改者发现这个逻辑表现不及预期，一番查看下来发现这个条件1确实重要，无论都要考虑，这个条件234的逻辑实在太复杂，使用屏蔽大法倒腾倒腾起来，最后发现屏蔽了条件2和条件4，这个逻辑的结果就很好控制了，那效果就达成了。那这样的话：这个条件4逻辑实在太复杂，没法分析，看起来好像也没啥用，直接屏蔽干掉得了。然后这个条件2看起来确实很重要，直接屏蔽可能太不合理，那暂时写成定值，带日后好好查清楚了再恢复原先的使用方式。也许这样处理解决了眼前的问题，但是埋下了很多风险，一个是该功能原本考虑的点没有考虑，如果是一个高压功能或行驶功能，可能会造成人车的潜在伤害风险。因此正确的做法应该是重要的必须保留，而无关直接删除，也别屏蔽了，免得造成干扰。![]()
据我观察，如果这个”屎山“项目把无用的代码逻辑删除，直接瘦身一大半，那将会让接锅侠好受很多。但实际上很多项目都是如此，存在一大堆无用的代码逻辑，越到后期越没人敢动，因而能够贯穿整个软件生命周期。
3 模型生成的代码手动更改
当模型生成的代码还需要手动修改，这是一个无法接收的事实，不管是出于何种原因。尤其是直接去修改生成代码的逻辑，且没有任何软件变更记录，这绝不能被允许的行为，但是这却发生了。如何规避这样的行为？我确实碰到过因为编译原因，每次模型生成代码后需要去屏蔽某些接口的操作，才能使得编译通过。因为工具链还不够成熟，某些原因下允许了这种操作，除非自己动手去解决，不然还得接受，这就是事实。然后手动修改模型生成的代码，这个实实在在的雷，踏了才知道。为什么会这样？看起来是个人原因，本质上是软件项目管理的问题，一没软件开发流程和工具，二没软件仓库和版本管理，造成了这样的乱象。因此，一些投入是必须的，包括软件开发要求、软件开发工具和软件版本管理等。通过这样一个”屎山“项目，突然让我用起来多年积累的一些东西，有感而发。长路漫漫，有时候真不能只看眼前，还是得更系统更全局一点的视角去解决问题，这样才能做出更好的设计。借着这个”屎山“项目的一些思考和实践，打算趁热打铁，下篇文章分享一下如何从零开始做ECU软件项目开发。
![]()
创作不易，欢迎点赞再看收藏关注！
汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车从业人员。
