在如今言必称IoT的时代，嵌入式软件工程师的称呼似乎越来越式微了。但无论是上古时代的经典嵌入式，还是如今万物互联的“内置超级算力的节点”，依托的基础能力模型却一直未变。
我喜欢给自己打上“恋旧”的标签，于是我也更愿意称呼自己为“嵌入式工程师”。
通俗来说，成为优秀的嵌入式工程师，要具备2种能力模型。
软件工程师通用能力模型
- 坚持
成为一名合格的软件工程师不是一件特别难的事。努力学习，勤奋工作，尝试比别人付出多一些的时间，总是能在工作中得到回报。过了新手村的手忙脚乱之后，大部分人都能够在职场中占据自己的一席之地。但是决定大部分人职场上限的，却是对一个领域的持续付出。而这个道理，也被总结为了“一万小时定律”被人耳熟能详。人生要面对的问题很多，解决方式也千变万化。而升级之路的基本原理却简单得令人发指，只要你能坚持得下去。 - 责任心
事由人承载，人的能力总是需要事情来证明。工程师的升级之路就像打怪升级，刚开始你的对手是一个小怪，轻轻松松。慢慢遇到大怪，绞尽脑汁也平安度过。再到后来的BOSS，于是你开始没办法单打独斗，你需要和团队配合去挑战。在这样一个大家都无比熟悉的过程中，是什么能让“你”在一群技能熟练度都差不多的队友中脱颖而出？很简单，事情的结果与预期的匹配度。决定这个匹配度的因素很多。给你一个能力超出当前挑战一个量级的选手，你必然能得到一个很漂亮的局面：轻轻松松将事情的完成度超过预期值。但是在“企业”这种长期处于资源不足、面对的挑战多元化的商业世界，想要长期将事情的结果与预期管理起来，答案就变成了唯一一个：责任心。
对，说的就是你。
就是那个“不会但我可以学，没有条件但我可以创造”的你。 - 持续学习的能力
逐渐习惯了以往的打怪升级套路，日常的工作对你也越来越顺手。在一个平凡的上午，你刷着一篇新技术的报道。此时的你，你会不会去思考这个技术背后的原理？会给行业带来哪些变革？甚至去实践？也许你很快抛之脑后，也许你只是当成了谈资。可是总有一小部分的玩家真的在工作之余将这些额外的东西纳入了自己的知识体系，当这些新东西能够与工作结合起来不断给出更优的结果时，这种积累就变成了正反馈。我们有时总是惊叹某某大神，怎么那么厉害。岂不知大神的成绩背后，是多年的习惯养成的量变下的质变：我们在工作中的一个顿悟，真的只是他们的常识之一。
优良的持续学习能力也同样影响着我们的人生轨迹。工程师领域面对的问题，大部分有相对固定套路的解法。同时，我们大多数人所在的平台能提供的挑战也基本落在了这个区间内。很多人跨过了这个阶段之后，要么觉得自己在领域内可以呼风唤雨便止步不前，要么觉得自己无法再继续成长而焦虑导致郁郁终日。面对这样的“岔路口”，持续学习便自然而然成了最好的路标：也许你会衡量自身实力后毅然去了行业最前沿的企业寻求更刺激的发展，也许你会依据自身的积累与别的行业的结合开辟了新的商业机会，也许你依靠过去的赫赫战功顺利转了管理层，也许你觉得鸵鸟就是最好的选择，就这么安逸地过了下去......
等等，为什么天赋没在这里？如果天赋也是能力的一种的话，大部分人都没有这种能力。而这种能力并不影响一个人成为一个优秀的工程师，或者说软件工程师。假如有了以上基本能力的人，还拥有天赋这样一种耀眼的光环，嗯，卓越的工程师在向你招手。
嵌入式领域特定能力模型
嵌入式领域需要解决的特定问题决定了嵌入式软件工程师的第二个能力模型：
数电与模电基础
硬件产品的原理图设计与PCB的布局一般算作硬件设计的范畴内，但是有效阅读硬件设计后的产物尤其是原理图，却是嵌入式软件工程师的必备技能之一。原理图包含了一般意义上的软硬件之间的约定与注意事项，是嵌入式软件设计时要考虑进去的主要信息。
同时，能直接控制硬件是嵌入式系统的一大特色。了解目标硬件的基本电器特性，也是软件能否正常工作的重要因素之一。资源敏感性
资源受限，也是嵌入式系统的命名由来。这一点也基本决定了整个嵌入式生态的语言与工具形态：
- 编程语言常年被C/C++与汇编统治。熟练掌握这些，成了嵌入式软件工程师的准入门槛。
- 存储模型特异。不同的硬件平台可能对应完全不同的构建工具链、存储布局、OS依赖、字节序等细节，嵌入式软件工程师要对这些底层的知识有自己的理解。没有真正理解的前提下，就直接按照sample生搬硬套很可能会让自己吃大亏。
- 基本的数学素养。嵌入式系统的算力跟手机、桌面和Server端比起来，真是一个天一个地（说起手机，多说两句，以前这哥们也是嵌入式阵营的。但是架不住人家越做越高端，量越做越大啊，最后索性直接独立成了手机阵营）：嵌入式系统的算力基本都是以M为单位的，不像其他几个平台，算力动辄上G；内存是以KB，甚至B为单位的，也不比其他几个平台都是上GB的内存。所以一般嵌入式场景下的算法都会做精心选择，同时再做优化或者裁剪：常见的如舍弃精度、定点化、查表等等。而现在很多专有运算单元都硬件化了，让嵌入式软件工程师能够专注于业务场景，不用过多操心这些细枝末节。
- 功耗
对于大部分电池供电的硬件产品，功耗都是嵌入式软件工程师心头绕不过去的痛（尤其是对经验不多的工程师来说）。为啥这么说？功耗优化可能是工作量最大，也是最难搞定的一个指标。往往在DVT阶段，功耗并不被大家那么重视，工期和稳定性则是更加受大家青睐的问题；而等到后面都稳定了，大家看到功耗的短板了，投入精力进行相关的设计审查，代码审查才发现前期设计的不合理，算法选择的不合理，这就是整个项目组的梦魇了。推倒重来？还是凑合改改降低产品预期？如果这时候产品发布会也开了，牛也吹出去了，项目组就等着喝一壶吧，嘿嘿......
其实职业生涯前期吃点亏不是坏事，大部分企业的研发管控与质量管理流程都是踩着这些坑过来的，只是如果自己没踩坑的时候，往往觉察不到前人定下很多莫名其妙的流程、要求、限制的背景与其用意。等真正hold住了这些模型，恭喜你，你已经具备了优秀的嵌入式软件工程师的必备条件，假以时日，让我们一起期待一个非凡的你！
