电子产品世界

据说，中国的手机都带有美颜和减龄功能，每每在朋友圈里看到女同学自己拍的冻龄自拍照，总是感到穿越般的恍惚不已：难道，这就是当年的“翠花”？

只见，那月光般柔和的脸上竟没有一丝丝皱纹，如水的大眼睛秋波荡漾，摄人心魂，一口细碎的小白牙洋溢着满满的青春气息，仿佛在诉说着无言的柔情蜜意。

再看那茭白的脸蛋蛋和娇滴滴的红唇，就像要透过手机的屏幕，贴到我的眼前，轻轻地说：我的脸庞，就像那皎洁的月光，想不想踩在我的鼻尖上，抚摸那温柔的月光？

但是，有的时候，她们的朋友圈竟而也会有漏网之鱼。

在受制于手机算力无法群体美颜的集体照里，岁月这把无情的照妖镜，残酷地揭开了昨日美女的画皮，暴露了她们奔四的年纪！

是的，她们当年的小伙伴-洒家，也开始奔四了。

一

中年男不一定油腻，但是肯定会间或感到精力不济，想提起神，做些深度的思考和学习，但总觉脑袋里没有足够的电力，只能浅尝辄止，扼腕叹息。

保温杯里泡上满满的枸杞，也无法找回当年满当当的活力。

对于脑力工作者而言，这绝对是个大忌！

洒家不烟不酒不油腻，锻炼身体，不打游戏，但是，随着慢慢地上了年纪，也开始经常感到精力不济。其中有一个突出的表现：越来越不愿意手写代码了。

这当然不是因为洒家谋求转型，想从科研一线逃离，走向“一壶水一包烟，晃晃悠悠过一天”的管理岗位。而是靠着手写代码干活吃饭、挣钱养家的洒家，实在是觉得手工编码越来越辛苦了。

广大人民群众对美好生活的期待，加上当今世界的算力不断增长，导致嵌入式产品中的代码量呈现爆炸式的增长。作为一名小公司的嵌入式软件工程师，尽管自己的经验与日俱增，但是悲催的是，经验永远赶不上工作量增长的速度，加上公司“唯利是图”，不可能招聘更多工程师来帮忙分担，所以自然越来越累。

但是，还有另一方面同时也是最重要的原因：手写代码非常烧脑，喝凉水睡凉炕全靠火力壮的小伙子还能扛得住，奔四的老码农哪能受得了？

可是，洒家也只能默默无言两行泪。要知道，在好多IT公司中，过了35岁就被扫地出门了，不舍得招人的领导还能听你在这里叨逼叨地诉苦？你忙你累，你还有理了？

问君能有几多愁，摸摸自己光秃秃的头！

二

那么，问题来了，手写代码为什么会那么累撒？

记得有位经济学砖家说过，中国经济发展的所有问题都是因为制度没有理顺。同理，手写代码累人的原因在于开发过程没有理顺。

先看看手写代码遵循的开发过程：需求定义->设计->实现->测试与验证。

这里的四个阶段看起来貌似连贯，其实在很大程度上是各自独立的。试为诸君细剖之。

需求定义，顾名思义，搞清楚所开发产品有哪些功能、性能、标准上的要求，它的输出是一些文本文档。

有人说，中国科技不发达的原因之一就在于汉语的模糊和歧义性。虽说汉语毫无来由地背了这么大一个锅着实冤枉，但是，在文档形式的需求定义中，各色人等对需求的理解确实是“横看成岭侧成峰，远近高低各不同”。

千人千面，无法统一，这就为漏洞和缺陷埋下了火药线。

再看设计阶段，设计人员按照需求文档设计原型，选择架构，划分模块。在这个阶段，可能会搭个电路，买个开发板，做一些实物原型，看看自己的思路是否可行。但是显然，这种方式非常地耗时、好成本，同时也很不完整。

到了实现阶段，先声明一点，大部分嵌入式软件工程师都是把设计阶段和实现阶段混在一起的。这个阶段，工程师会借助各种开发工具，开始手工编码代码。手写代码讲究个心到、眼到、手敲，用脚丫子都能想得到，这种方式特别地容易引入人为错误。

最后是测试阶段，也是开发过程的最后一个阶段。一般，测试人员在该阶段介入进来，对照着需求逐条测试。在整个链条的最后一环查找并修复错误，会花费很大的时间和人力成本。

各个阶段之间，实际上都有一道墙横亘在那里。

从需求分析到设计，文本文档的歧义性和模糊性可能会让你误入歧途，成为日后隐患的导火线。

从设计到实现，李宗盛大哥说：“既然不是仙，难免有杂念”，洒家说：“既然有杂念，难免会智商掉线”，从而在编码中埋下一个又一个天雷滚滚，日后劈得自己外焦里嫩。

从实现到测试，面对的便是一道肉墙了。测试大姐带着丰满的脂肪在你面前一站，一边说落你不遵循编码规则的自由散漫，一边控诉你蹩脚的编程经验，你说你难堪不难堪？

三

只提问题不说答案的都是在耍流氓。洒家风度翩翩，自然是要脸面的。

洒家开的药方便是，基于模型的设计（MBD）。

MBD，是以模型为核心，对算法进行建模、验证，并支持文档自动化、自动代码生成。

还是按照上面的四个阶段，对比一下MBD的优势。

在需求分析阶段，MBD的输出结果是一个可视化的模型，不同的人使用相同的模型。

它的优势在于：相比于文本文档，可视化的图形模型显得非常清楚、明确，最关键的是明确统一且唯一的需求，便于人们的交流。洒家认为，图形化的模型是消解汉语歧义性的最佳手段，各位看官以为然否？

设计阶段可以认为是一个模型不断细化的过程，随着模型的细化，验证可以同时进行，没错，传统开发流程中第四个阶段-测试可以提前到设计阶段来进行了。它的好处在哪里呢？

佛门有句话，“不怕念起，只怕觉迟”。在“打得念头死，许汝法身活”的语境中，起心动念是不对的，要早点消除，不要觉察地太迟。在软件开发上也是如此，要尽可能在早期发现错误，这样会给后续的开发过程带来很多便利。

在手写代码的传统流程中，尽早发现问题靠的是“评审”，但是显然那只适用于大公司。据我一个在大公司干过活的同学讲，写了文档后要评审，做了设计后要评审，敲完代码后要评审，弄完测试用例还是要评审，没完没了的评审，效率实在是低。

现在好了，MBD在“早期”设计阶段便可以做测试和验证，从而将错误的苗头尽早地扼杀在了摇篮里。

再下一个便是实现阶段。MBD正是在这个阶段，极大地解放了码农的生产力，因为您不用手写代码啦，MBD支持自动代码生成！

靠机器而不是人写代码，这合适吗？合理吗？

好吧，人类是计算机的造物主，但是在这里，咱不谈精神，不说灵魂。

必须承认的是，计算机在生成代码方面确实要比人类的智慧高，且不说他们支持好几种生成方式，可以选择效率优先，或者RAM优先，人家还可以自动支持MISRA-C编码规范，光这一条，还不得秒一大街码农？

没有情感的计算机消灭了编码阶段的人为错误，便是对码农最大的温情！

最后一个测试阶段不用说了，因为在MBD设计里，这四个阶段之间没有“墙”，模型不断细化，测试验证是持续进行的，在早期就引入了验证，把错误消灭在早期，尽可能降低了修复的成本。

四

说到这里，老码农们也不要伤心，觉得脊梁骨发凉。都自动代码生成了，公司领导要是拿自己开刀咋办？

需要明确的是，MBD并非完全不需要软件工程师的聪明才智了，比如对程序中各种变量、函数的命名，无论是手写代码还是MBD方式都很重要，程序设计中的命名是一个充满创造力的地方，一个智商不到两岁小孩的计算机能起好名？

在MBD设计中，需要码农动用自己的创造力来重视标识符命名。因为好的命名具有极强、极精准的描述能力，能够清晰地表达函数或变量的含义，这样会增加程序的可读性和可维护性，也可以在一定程度上消除不必要的注释。

其次，在底层驱动上，也很难引用MBD方式，因为在很多应用领域中，底层驱动是比较复杂的，输入驱动、输出驱动、通信驱动、特殊器件的驱动等等这些，依然是手写代码的天下。

还有通信、诊断、操作系统这些东西，用MBD很难实现，而且也没有优势，还不得靠咱？

所以，通常的情景是：在一个产品级的开发中，会在一个大系统中的一个任务中或者ISR中，把MBD实现的算法放进去，其它地方，仍然是手写代码的天下。将代码集成到整个嵌入式系统的软件中时，依然需要手写代码的经验。

那种妄图让MBD取代所有编码工作，是狂妄的，也是不现实的。

后记

从手写代码到MBD，是一种开发流程思维的革命。

在这个过渡的过程中，不要有太大的负担和畏难心理。无论是手写代码还是MBD的自动代码生成，就是个工具，一层窗户纸的事儿。没有捅破之前觉得很难，但是一旦捅破了，不过尔尔。

革命革命，革掉自己的命，方能迎来新生。往日种种譬如昨日死，今日种种譬如今日生。

在这个不断增长的年纪，希望各位老码农尽早转型到基于模型的设计上来。

我爱你们！

关键词：