关于初级嵌入式软件工程师应有的思考

引言

转眼间已经在CSDN平台断断续续更新了几十篇文章，基本都是在分享技术，很少对个人经验进行总结，一是觉得自己工作年限不够，说不出有价值的东西，二是平时思考都比较碎片化，鲜有时间总结。前段时间偶尔翻到了自己发的第一条博文，这让我开始回顾转行这些年，碰到过很多人和事：有觉得程序员轻松，敲键盘就能拿工资的行外人；有培训两个月，拥有三年工作经验并成功找到工作的程序员；也有为了赶项目进度，让应届新员工接手核心业务的公司；还有没有任何文档，项目全凭口口相传的公司，这些行业的小缩影，都让我开始反思：在这样糟糕的大环境下，要如何保持刚入行时的初心，要如何保持对技术最原始的热诚。于是有了这篇文章

嵌入式行业的变化

暂不看嵌入式，谈谈近年来一直很火热的互联网。过去很长一段时间各种资本纷纷涌入互联网行业，吸引了大批人才流向互联网，直到近一两年开始出现裁员热潮。大批资本和人才的流入，让互联网行业积累了足够的行业经验，成熟的工具，套路化的开发模式。无论是大小公司，目前互联网开发者的工作已经趋于螺丝钉化，有的甚至已经可以被AI取代。反观嵌入式行业，相关的领域都处于发展阶段，行业整体呈现出以下的变化趋势：

• 业务规模扩大，代码规模/复杂度激增
• 和云、AI智能化等新技术结合，业务变化更多样
• 结合互联网和嵌入式的物联网，让万物数据化
• 国外技术封锁，行业从依附现成架构走向自研架构

初级嵌入式软件工程师的思考

以上的行业大背景变化，带来了很多机遇，也带来了很多思考：

• 面对大型复杂项目，如何系统、结构化组织巨量代码？
• 面对复杂业务逻辑，如何更快输出产品并降低维护成本？
• 如何从行业搬运者，转变成行业构建者？
  以上诸多思考，总的来说都是要求嵌入式软件工程师提高自身的软件设计能力

很多嵌入式软件工程师，都是自动化、电子等背景出身，更习惯从硬件角度去了解嵌入式系统，很少从软件角度去审视嵌入式系统。他们虽然能很好地完成驱动配置、外设使用等硬件相关的工作，但一旦遇到复杂的业务逻辑、深层次的算法等任务，缺乏软件设计的指导最终就会导致产品开发周期变长，维护成本变高。在初级嵌入式软件工程师中，这样的情况更常见，他 们往往只能做成产品，但不能做好产品

所以我觉得对于寻求进步和上升的初级嵌入式软件工程师，除了不断学习巩固基础知识以外，更应该跳脱出自身知识背景和认知限制，通过提高软件设计能力去突破自身的职业天花板：

软件架构思维

软件架构是什么？这是一个老生常谈的问题，我认为软件本身是一种系统，而软件架构就是该系统的草图，是系统的抽象存在，它描述了系统构件的职能、构件之间的关系，还给出了系统实现的方向、准则。大型软件项目中都会用到软件架构，便于软件设计工作的进行

软件架构往往会和软件框架混淆。软件架构和系统是强相关的，例如医院软件系统和食堂软件系统，软件架构肯定不一样的。框架和系统是弱相关的，例如MVC，MVVM之类的框架，不同的系统是可以复用和借鉴参考的

软件架构思维的对于大型项目的作用在于：

• 宏观上能界定出软件系统的形态和功能，给开发团队一致的开发方向
• 微观上能通过分层、结构化等手段，将大型项目拆分为小的构件，有效降低项目复杂
• 实现软件的功能时，能从系统、全局的角度出发，更好更快的完成目标
• 让多人协作，有了统一的标准和平台，减少了不对称沟通，从而减少内耗提高效率

抽象能力

在面对复杂业务时，很难从表面去捋清业务的逻辑关系，这时候就要抽象能力的辅助。所谓抽象能力，我觉得就是过滤无用因素，获取本质内容的能力，透过现象看本质的能力。例如从麻雀、游隼、喜鹊这几个关键词中我抽象出鸟类这个词。抽象也分程度，按需求去有层次的抽象才能得到有用的信息，过度抽象会导致信息缺失，还是之前的例子，我按照不同的层次去抽象，还可以得到动物这个关键词

抽象运用到具体开发中时，可以表现为表现为面向对象的思想，通过封装、继承和多态的方法去进行抽象：

• 封装：可以将多个有共性的事物，变成一种事物，即抽象成为开发中的类，类的数据结构和方法。是信息的隐藏和包装
• 继承：不同的类之间会存在关系，继承可以更好地表达不同层次抽象出的类之间的关系。是信息的关联和拓展
• 多态：让类的方法在运行时能稳定地表现出不同的状态，以面对不同的需求

抽象需要遵从原则，抽象原则可以更好的完成抽象，避免过度抽象

• 单一职责原则：一个模块只做一件事
• 开放封闭原则：模块应该对拓展开放，对修改封闭
• 依赖倒置原则：高层模块不用依赖底层模块，应共同依赖于抽象
• 里氏替换原则：基类出现的地方，一定可以用子类代替
• 接口隔离原则：类不要强制依赖于他不需要的接口
• 迪米特法则：一个类应该和其他类保持最少的交流

等待补充