拆解一下汽车电子软件开发工具链_电控工具链开发(1)，从不一样的角度描述Golang事件传递

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

早些年的一段时间，我对工具的态度大约是属于嗤之以鼻，总觉得用工具的人缺少思考和业务能力，纯粹是熟练，工具本身难以构成突出的竞争力，工具人甚至被认为是能力差的代名词，特别是对于早期制造业中较多接触到的CAD、CAE、SAP、ERP、PLM及一些实验排期或库存管理的系统等。

随着在汽车电子软件领域经验的积累和对数字化及敏捷开发等的理解的深入，越来越深刻地体会到充分使用工具的必要性。多说一句，制造业多会叫软件或系统，不习惯叫工具，从称呼上其实也能体会到一点定位上的差异。

细究原因，产品与行业的需求是一部分原因，另一部分原因也来源于自己职场或社会经验的叠加，工具类似于一种资源、一种手段、一个杠杆，个人加徒手能够完成的工作是极其有限的，借力才能大力。没有工具的话，我们所依托的其实只剩下“语言“，思考需要基于语言，沟通更离不开语言，而语言是局限的。

举个最简单的例子，当你用图表这种基础工具去描述一件事物时，你做的不是简单的语言同态映射，而是不同逻辑和模式下的表达与展示，看这个图表和对应的描述文字时，你获取的信息、感受、思考与灵感均是完全不同的，这就是”图表“这个工具能给你带来的额外价值。

这个道理并非新颖，但在汽车电子软件这个领域，对于多数人来说，并未迈入工具及工具链的门槛，当别人都还习惯于excel码字、打电话和开会时，你用到这个杠杆，可能会帮你更容易撬起来一些你想要的东西。

**
**

按照汽车软件的来龙去脉，基本会有这7个环节：需求、架构、开发、集成、验证、项目管理、配置管理，对应的有相应的工具。

当然，不是每一个环节都是一个单独的工具，很多工具开发者都希望尽可能涵盖更广，所以，理论上，一个工具可以支持很多环节，甚至是全生命周期的。但是，基于惯例或者各自优势，每一个环节又会用到比较流行的工具或某个模块，一个工具也会交叉使用在不同环节上。

下面做一些整理，应该基本可以反映出当下汽车行业惯用的一些工具。

**需求：**Doors、DNG、JAMA、Polarion、TRM、Clear Quest、Reqtify……

**架构：**OpenAmeos、Rhapsody、Systemweaver、PREEvision、Pure:Variant、Visio、EA、Simulink、AUTOSAR Blockset……

**开发：**Eclipse、VS Code、Jenkins、Wind River、Perl、Green Hills、Vector、Source Insight……

**集成：**Jekins、RTC、Harness、MAKEFILE……

**验证：**Coverity、Polyspace、Tessy、QAC、Gerrit、Parasoft、VectorCast、dSpace、CANOE、CarMaker、Reactis、RQM、ECU-Test、JIRA、Gtest、PC-lint、Findbugs、Junit……

**项目管理：**JIRA、Polarion、RTC、Clear Quest、Git、Asana、飞书、Project、DTS、RDM、Redmine、禅道、PTC Integrity……

**配置管理：**RTC、SVN、Sharepoint、MS Teams、MKS、Gitlab、Confluence、PlasticSCM、ClearCase、Synergy、Preforce……

我一直比较排斥造词、造概念等故弄玄虚和简单问题复杂化的行为，说起来天花乱坠且清新脱俗，做起来还是老一套。

对于工具链的“链“，我们也不要把它想得多么高深。

简单理解，”链“就是建立链接和数据同步。再扩展一点，就是建立不同但相关数据的链接和相同但不同区域数据的同步，前者侧重静态关系，后者侧重动态流转。

当然，链条里不能忽略人，但人脑子里没有天线，无法直接建立连接和传输数据，把人加进链条更多是把与人交互密切的载体加入链条，比如，手机和邮箱。

而且，人在里面的作用越小越好，人作用越小，说明自动化和智能化的程度越高。

ASPICE要求我们做追溯，追溯就是典型的建立不同但相关数据的链接，用文字描述、excel贴链接、变更履历里加编号，甚至测试发微信给需求，这都是建立链接，方式有多种多样，只不过都上系统后，工具里直接建立链接会有更多的好处，比如，稳固、清晰、透明、历史追溯性好等。

除了工程里的追溯，不同系统间可以自由跳转访问也是一种很实用的链接。

数据同步和我之前多次提到的数据同源有一定的关系，数据同源是提升透明度、效率、准确性的良好手段，良好的数据同步又是实现数据同源的支撑。

无论是面对频繁变化的项目计划、不断迭代的软件，还是处理成千上万的Bug，或者完成整合数据的配置管理，或者进行不同区域和组织间文件的传递。通过工具的打通，让数据流转起来，让数据自动同步，这都是工具“链“的重要需求。

此外，建立连接和传输数据不一定就是简单的原始连接和源数据传递，可能更需要特殊的匹配、统计、计算等处理工作，比如，需求和测试系统经过比对识别符来完成链接，并在此基础上自动计算出覆盖率。

基于多种客观原因和主观考量，“链“的建立并不容易，数据孤岛和部门墙依然风行。然而，这种现实的弊端正是工具链存在的价值及大家对它的期许。

我们多数不是专门的工具链公司从业者或者说本文多数受众不是，**我们不需要深入到工具开发逻辑层面，更多是在工具的应用和功能挖掘组合上。**其实，当前流行的工具内嵌了很多强大的功能，实际被挖掘使用的部分却又是非常少的。

首先呢，我认为是尽可能用出花样来，要全面，要结构化，要美观，要自动化，不要去依赖于传统的excel、ppt，尽管Office非常强大，但非常基础和普遍，经典的不等于未来的。

玩工具链也并非目的，而是手段，是显示出你的独特性的手段。业务能力有高低，经验积累有厚薄，你使用工具展示、汇报、分析的水平也是一种资源。在全面数字化和智能化到来之前，工具化是一个必经之路。

其次，或许没必要系统学习，有那么多工作在等着，我们无法投入太多精力在工具上，但应该时刻思考并寻找工具的支持，如何将自己的一些工作数字化、工具化。

未必需要自己亲力亲为，大一点的公司都会有工具组，要充分利用好他们。在不断的过程中，学会用工具加速自己的工作，理解工具的运行逻辑，将自己更多的时间投放在创造性的思考上。

既然智能化时代终将来临，不妨主动迈过去。

写到这里，我同时还在反思自己行文的基准——工具是否有那么重要？我们惯常讲的一句话是“这只是一个工具”。言下之意是，这没那么重要。而这不由得让我想起，也有很多人说过“语言只是工具”，可在我多年外企的经历中，深知一口流利的英语给人职业发展带来的助力是多么大。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
-liTRIGXL-1713554290792)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！