同样是软件开发，为什么没有嵌入式软件架构师，2024年最新那些年Golang面试官常问的知识点

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

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

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

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

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

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

正文

已剪辑自: https://mp.weixin.qq.com/s/mKQ_d8mfau-JB04v-_coWg

大家好，今天分享一篇关于嵌入式软件架构师的文章，文中的 “我” 为作者本人。希望对从事嵌入软件开发的你有所启发。

我从事嵌入式软件开发有6、7个年头，bsp，驱动，应用软件，android hall，framework 等都有涉猎。平时除了关注嵌入式行业的发展，也多少对 Web，后台服务端，分布式等方向的技术有一些关注。

近期有萌生换个行业方向的想法，想做做后台服务器相关的开发，由于之前工作中并没有这方面的实际需求，只是自己平时关注，了解了些知识，比如：NIO，epoll，ngnix，zeromq，libevent，libuv，高并发，分布式，redis，python，tornado，django，涉猎比较杂，都了解个皮毛，不精。意外的是屡屡被互联网行业鄙视，面试机会都寥寥无几。此时我想到底是什么问题呢，难道嵌入式出身的已经这么不受待见了吗?想当初，嵌入式，驱动开发，可是趋之若鹜的行业(有点夸张，不过8，9年前嵌入式可是听着比做java web的要牛逼些哦)问题总是有原因的，我说下自己的理解：

1. 为什么没有嵌入式软件架构师?

打开各种招聘网站，搜索架构师，会出现各种系统架构师，web架构师，后台服务端架构师等等，但是唯独很难看到嵌入式软件架构师。嵌入式软件不需要架构吗，驱动不需要架构吗？答案是当然需要，不过为什么没有这方面的职位?我的看法：目前国内的嵌入式开发主要分为嵌入式底层开发和嵌入式应用开发，嵌入式的底层开发一般叫做驱动开发，或者bsp开发，有时也有称之为linux内核开发，名字听着都很高大上的感觉。这么高大上的名字为什么没有架构师呢：linux kernel的架构师是linus等一众linux kernel开发维护者，因为本身linux kernel或者操作系统就是一个通用的平台，解决通用的问题，linux开源届的大牛都已经制定好了架构规则，留给可发挥的地方并不多，大部分工作只需要按照规则框架填充就可以了。而且以目前国内大部分公司的业务需求，只是在做外围设备的集成，嵌入式平台的porting，搭建裁剪，业务需求完全不会超过kernel里提供的功能范围。导致没有什么新的架构需要开发人员去设计，实现。那嵌入式bsp开发人员都在做什么：除了调试多种多样的外设，替硬件擦屁股，就是解些稳定性的bug了(这里对具体工作不详细描述了，调试外设只会增加一些经验，增加广度，对提高深度贡献不大，只是按不会调试->会调试->调试的快这个路线发展，而解稳定性问题确实是需要一些积累经验)而嵌入式上的应用开发，一般业务逻辑比较简单，被很多人忽略，所以招聘方也会感觉没有什么必要找架构师级别的了。至此感觉嵌入式行业的确不需要架构师，被互联网行业的鄙视也没什么大惊小怪的。但的确是这样子的吗?对于嵌入式底层的开发，有能力对kernel，驱动架构提出架构层优化的，国内的开发人员应该不多，所以对于大部分普通人，还是不要“妄想”做Linux kernel的架构师了(当然我相信国人中一定存在有这个能力的大牛)，发现、解决一些bug，倒更靠谱些。

2. 我们真的不需要架构吗?

以自己的实际经历讲述下曾经对一个嵌入式设备应用软件的架构设计和优化。我曾经接手过一个项目，项目采用单进程多线程的模型，项目中包括几个模块，以 a, b, c, d,e 代表。这个项目的业务逻辑决定这几个模块有不少关联。

例如：最初的设计中 a 模块是一个状态监测模块，它会基于监测到的状态调用 b，c模块的接口实现一些功能(多线程的好处就是直接调用很方便，所以开发人员大多这么干，简单粗暴)，但是需求总是千变万化，加入一个 f 模块，f 模块也需要对 a 模块监测的状态进行一个处理，按照之前的套路，完成这个功能分两步：

1，在f模块提供个接口；

2，在a模块中调用该接口。至此新需求已经“完美”地解决了。前面提到需求总是千变万化的，新的需求又来了，客户提出定制需求，需要加入另一个g模块，同样处理a模块监测的状态，但是该定制需求不需要刚刚加入的f模块，此时最简单粗暴的方式是，定义一个宏，区分该定制需求和之前的通用需求，build两个程序版本。这样的做法看似简单，但后面如果定制需求逐渐增多，维护这么多定制版本程序就是个噩梦，代码管理和通用性也会是很大的问题，同时代码中充斥着对不同宏定义的差异化处理，

#ifdef xxx
do_something;
#endif

比较好的做法是加入设备型号版本的动态监测，用一个build程序版本动态支持所有的定制需求，这样减少了对不同 build 程序的维护。

但是这种做法只解决了 build 程序的版本维护工作，没有解决宏定义差异化处理的问题，只是会将之前的宏判断，改为动态设备版本号判断，如果这些差异化的判断只集中在一处进行，也不会引起大的复杂化的问题，但显然这个是不好保证的，有可能这些差异化的处理会蔓延到整个项目的各个角落，这样项目维护起来就会变成一场噩梦。

不需要什么高深的软件思想，大部分人都会想到把差异化的部分提取出来，放在一个统一的地方集中管理，对差异化的修改只集中在这个统一管理的地方。

通用做法就是采用 callback 设置钩子，然后在 callback 中定制差异化的需求，对callback 的处理做差异化的配置。对应到上面例子，就是在 a 模块添加一个钩子，然后在系统初始化时，根据设备版本号的不同，差异化定制 callback 处理函数，同时要将这些定制 callback 处理函数放在同一地方处理，否则仍然分散在各个角落里就没有意义(前一种方式不放置钩子是无法将这些差异化配置放在一起的)。这样处理带来的另外一个好处是，我们对功能性需求的改变，不会影响到 a 模块的处理，也就是我们添加功能，不需要修改 a 模块的代码了(前一种方式要修改a模块的调用流程)，这样也就实现了一个模块的分离。至此第二种的方案的架构(其实也谈不上架构了)相比第一种方案已经有了不少提升，至少让开发人员稍微轻松了些，对于其他定制需求，开发人员只需要修改这个callback处理，关注差异化部分就可以了。**软件是需要不断进化的，第二种方案是最优解吗，当然不是，还有优化空间吗?**下面先跑个题，谈谈多线程/多进程模型的优缺点，主要谈多进程的优点了：教科书上的解释就不提了，首先我对大的项目是推崇多进程模型，无关性能，主要原因有：

模块的解耦

很多开发人员维护开发的多线程模型项目应该都多少会存在下面的问题：跨模块间的直接调用，如果不相信，好，你的项目一定是分模块的吧，现在随机的删掉一个模块，build下看能build通过吗(只需要build不需要运行)，我相信大部分情况下一定会遇到某个函数调用，某个全局变量找不到的情况，这种情况说明你的模块间存在强耦合了。由于多线程天然的优势，地址空间的相互可见，导致直接调用十分容易，很多经验尚浅的工程师，很容易就写出直接调用的简单粗暴的接口，如果遇到个 static 接口的函数，图方便也会把 static 去掉，直接拿过来用了。这样整个工程随着功能不断的添加，模块间的交叉越来越多，耦合越高。而我之所以推崇多进程的原因就是，多进程能从物理上隔绝了这种“方便”的通讯方式，导致在想实现一个模块交互时，会多思考下这个交互是必要的吗，如果是必要的，则会进一步思考接口定义是否简单明了(因为进程间的通讯相对会麻烦些，开发人员会本着能减少交互，明确接口的想法去仔细考虑接口，协议的定义，否则折腾的是自己了)，这如同人生，如果一直顺风顺水，人们可能不会想太多，思考太多，而如果道路上有些坎坷，则会有另一种感悟吧。所以我的想法是多进程的模型会逼迫你去更多的思考想程序的设计，物理上减少模块的耦合。抽象通用组件，分离通用功能和业务逻辑功能：当把一个多线程模型修改为多进程模型的过程中，经常会发现有些接口代码重复的出现在多个进程模块中，因为之前接口函数是在一个进程空间，大家都可以直接调用的，比如接口A被模块a、b调用，模块a、b分离为两个独立的进程后，接口A需要在a，b中分别实现了，无需解释，重复代码这个在软件工程中是大忌，必须消除。做法也很简单，将这些被多个模块调用的接口分离处理做成lib，供其他模块调用，当你完成这部分工作后，你发现了什么，是不是剥离的接口，可以作为整个项目的通用组件存在了，完美的情况下，lib下的代码是通用基础组件，各个模块中是独立的业务处理模块。

方便定位问题

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

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

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