1 软件开发经验分享
我的观点是为了防止一错再错，先做好软件项目管理，再干软件开发工作。因为问题很多，在解决一个问题的过程中或者想同时解决几个问题时，进行频繁地尝试修改和软件释放，没有软件交付管理，软件数据管理和软件问题管理，只会越来越混乱。因此先梳理出现状，以确保好掌握后续的变更。可以从这么几个方面来做:
所有软件项目相关的内容采用Git或SVN等进行管理，确保软件版本能够及时上传，有迹可循，当然包括软件交付记录和软件问题管理等文件。
source: git 版本管理工具 学习笔记
一版软件释放解决一个问题，让客户清晰地了解每版软件的变更点。一次软件交付不做多个问题的修复，这样的好处就是客户很容易了解修复了什么，通过高频释放和高频沟通，也有利于缓和气氛。如果同时解决几个问题，碰到问题没解决，还引起了其他问题，反而给自己带来了更多的坑。
软件问题管理文档。当所有的软件问题都是邮件形式沟通或会议上的口述。但随着邮件越来越多，频率越来越高，一下子就变得无法清晰跟踪问题状态了。因此，整一个文档来管理这些软件问题就十分必要：
通过这样得方式对齐软件问题信息（原因分析，解决方案，软件版本，释放计划），双方清楚进展。所谓的安定军心，接下来关键就是要实打实的解决问题，即ECU软件开发，即需求、设计和验证。
了解需求的实现状态。虽然得不到答案，但可以了解哪些需求不是客户的，而是”屎山“软件祖传的，做到对软件无关的东西心中有个数；再去了解出问题的功能，该功能需求实现的状态。 做开发，最开始重点是是接口，梳理接口的状态及其影响分析。比如你分析数据时，明明条件都满足，但结果却不对，这时需要质疑信号的真实性。当变更一个信号的逻辑时，注意信号被调用的情况，一个信号逻辑的变化可能会影响很多逻辑的变化。然后是逻辑，做最少的逻辑变动去修复问题，从源头去修复问题。
回头再看破解“屎山”项目是一件挺有意思的事情。如何快速构建自己的解决思路和方法，通过详细分析和严谨的设计，能不断带来解决问题的快感。当然“屎山”项目能不接就不接，因为它的形成背后有深层次的原因，这将注定它的结局很难被改变，而最终背锅的就是接锅侠。
ECU应用层软件入门的三部曲之1 广博 (qq.com) ECU应用层软件入门的三部曲之2 基础 (qq.com) ECU应用层软件入门的三部曲之3 专精 (修炼中)
理解需求，精准设计。可以结合从整车功能层面，ECU系统层面，ECU硬件层面和ECU底层软件层面等来理解。 精通产品的控制基础，灵活应对实际问题。我向来觉得如果你对产品理解的很透彻，我所谓的基础，那么在实际应用过程中碰到问题时，解决问题的思路会更精准有效，有句话叫做以不变应万变。 最佳实践，包括工具链配置（代码生成，数据字典和A2L生成等）和模型设计等。
这就是关于软件开发经验的核心内容，当然想全了解ECU应用层软件开发，其实下面的内容也是可以作为补充项。当然这里只是列举几个：
2 软件开发的V流程
记得在2023年其实有研究ASPICE针对软件开发的每个环节，可惜当时手稿遗失，针对架构设计又在重新酝酿中。说实话这东西讲虚的讲方法论，好像没讲一样，但是讲实的，又受限产品，换个产品，可能框架差不多，但精髓不一样。
怎么理解SWE.4 软件单元测试 Part2-动态UT 怎么理解SWE.4 软件单元测试 Part3-落地实施 怎么理解SWE.4软件单元测试 Part4- 制定策略 (qq.com) 怎么理解SWE.5软件集成测试？(qq.com) 一文了解HIL台架测试系统 (qq.com) 一文了解HIL台架测试系统的验收和使用 (qq.com)
3 应用层软件开发
ECU 应用层软件模型与硬件相关的生成代码配置4 (qq.com) ECU 应用层软件模型之数据字典DD5 (qq.com) ECU 应用层软件模型之数据字典存储类6 (qq.com) ECU 应用层软件模型之定点化7 (qq.com) ECU应用软件模型之5种定点化实现方式8 (qq.com) ECU 应用层软件模型之自定义存储类9 (qq.com) ECU应用层软件模型之模型生成代码小结10 (qq.com) ECU 应用层软件模型之CAN接收11 (qq.com) ECU 应用层软件模型之CAN报文接收数据流12 (qq.com)
如何进行代码生成配置 如何进行数据字典配置
4 总结
回顾2024年对ECU应用层软件开发的输出，2025年将是重点发力的方向，一方面对于软件开发管理层面的梳理，另一方面是软件开发的最佳实践，让有兴趣的朋友即使零基础入门也不是难事。欢迎持续关注和支持，多谢。
创作不易，欢迎点赞再看收藏关注！
汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车从业人员。
