我是老温，一名热爱学习的嵌入式工程师
关注我，一起变得更加优秀！

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

近期有萌生换个行业方向的想法，想做做后台服务器相关的开发，由于之前工作中并没有这方面的实际需求，只是自己平时关注，了解了些知识，比如：NIO，epoll，ngnix，zeromq，libevent，libuv，高并发，分布式，redis，python，tornado，django，涉猎比较杂，都了解个皮毛，不精。意外的是屡屡被互联网行业鄙视，面试机会都寥寥无几。

此时我想到底是什么问题呢，难道嵌入式出身的已经这么不受待见了吗？想当初，嵌入式，驱动开发，可是趋之若鹜的行业（有点夸张，不过8，9年前嵌入式可是听着比做java web的要牛逼些哦）。

问题总是有原因的，我说下自己的理解：

为什么没有嵌入式软件架构师？

打开各种招聘网站，搜索架构师，会出现各种系统架构师，web架构师，后台服务端架构师等等，但是唯独很难看到嵌入式软件架构师。嵌入式软件不需要架构吗，驱动不需要架构吗？答案是当然需要，不过为什么没有这方面的职位？

我的看法：目前国内的嵌入式开发主要分为嵌入式底层开发和嵌入式应用开发，嵌入式的底层开发一般叫做驱动开发，或者bsp开发，有时也有称之为linux内核开发，名字听着都很高大上的感觉。

这么高大上的名字为什么没有架构师呢：linux kernel的架构师是linus等一众linux kernel开发维护者，因为本身linux kernel或者操作系统就是一个通用的平台，解决通用的问题，linux开源届的大牛都已经制定好了架构规则，留给可发挥的地方并不多，大部分工作只需要按照规则框架填充就可以了。

而且以目前国内大部分公司的业务需求，只是在做外围设备的集成，嵌入式平台的porting，搭建裁剪，业务需求完全不会超过kernel里提供的功能范围。
导致没有什么新的架构需要开发人员去设计，实现。

那嵌入式bsp开发人员都在做什么：除了调试多种多样的外设，替硬件擦屁股，就是解些稳定性的bug了（这里对具体工作不详细描述了，调试外设只会增加一些经验，增加广度，对提高深度贡献不大，只是按不会调试->会调试->调试的快这个路线发展，而解稳定性问题确实是需要一些积累经验）。

而嵌入式上的应用开发，一般业务逻辑比较简单，被很多人忽略，所以招聘方也会感觉没有什么必要找架构师级别的了。

至此感觉嵌入式行业的确不需要架构师，被互联网行业的鄙视也没什么大惊小怪的。

但的确是这样子的吗？对于嵌入式底层的开发，有能力对kernel，驱动架构提出架构层优化的，国内的开发人员应该不多，所以对于大部分普通人，还是不要“妄想”做Linux kernel的架构师了（当然我相信国人中一定存在有这个能力的大牛），发现，解决一些bug，到更靠谱些。

我们真的不需要架构吗？

以自己的实际经历讲述下曾经对一个嵌入式设备应用软件的架构设计和优化：

我曾经接手过一个项目，项目采用单进程多线程的模型，项目中包括几个模块，以abcde代表。这个项目的业务逻辑决定这几个模块有不少关联。

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

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

2、在a模块中调用该接口。至此，新需求已经“完美”的解决了。

前面提到需求总是千变万化的，新的需求又来了，客户提出定制需求，需要加入另一个g模块，同样处理a模块监测的状态，但是该定制需求不需要刚刚加入的f模块，此时最简单粗暴的方式是，定义一个宏，区分该定制需求和之前的通用需求，build两个程序版本。

这样的做法看似简单，但后面如果定制需求逐渐增多，维护这么多定制版本程序就是个噩梦，代码管理和通用性也会是很大的问题，同时代码中充斥着对不同宏定义的差异化处理，

#ifdef xxx
do_something;
#endif

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

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