听说，我国的手机都带有美颜和减龄功用，每每在朋友圈里看到女同学自己拍的冻龄自拍照，总是感到穿越般的含糊不已：莫非，这便是当年的“翠花”？
只见，那月光般柔软的脸上竟没有一丝丝皱纹，如水的大眼睛秋波泛动，摄人心魂，一口细碎的小白牙洋溢着满满的芳华气味，似乎在诉说着无言的柔情蜜意。
再看那茭白的脸蛋蛋和娇滴滴的红唇，就像要透过手机的屏幕，贴到我的眼前，轻轻地说：我的脸庞，就像那洁白的月光，想不想踩在我的鼻尖上，抚摸那温顺的月光？
可是，有的时分，她们的朋友圈竟而也会有漏网之鱼。
在受制于手机算力无法集体美颜的集体照里，年月这把无情的照妖镜，严酷地揭开了昨日美人的画皮，暴露了她们奔四的年岁！
是的，她们当年的小伙伴-洒家，也开端奔四了。
一
中年男不必定油腻，可是肯定会间或感到精力不济，想提起神，做些深度的考虑和学习，但总觉脑袋里没有满足的电力，只能浅尝辄止，扼腕叹息。
保温杯里泡上满满的枸杞，也无法找回当年满当当的生机。
关于脑力作业者而言，这肯定是个大忌！
洒家不烟不酒不油腻，锻炼身体，不打游戏，可是，跟着慢慢地上了年岁，也开端常常感到精力不济。其中有一个杰出的体现：越来越不愿意手写代码了。
这当然不是由于洒家追求转型，想从科研一线逃离，走向“一壶水一包烟，晃晃悠悠过一天”的办理岗位。而是靠着手写代码干活吃饭、赚钱养家的洒家，实在是觉得手艺编码越来越辛苦了。
广大人民群众对美好生活的等待，加上当今世界的算力不断添加，导致嵌入式产品中的代码量出现爆破式的添加。作为一名小公司的嵌入式软件工程师，虽然自己的经历日积月累，可是悲催的是，经历永久赶不上作业量添加的速度，加上公司“利欲熏心”，不可能招聘更多工程师来帮助分管，所以天然越来越累。
可是，还有另一方面一同也是最重要的原因：手写代码十分烧脑，喝凉水睡凉炕全赖火力壮的小伙子还能扛得住，奔四的老码农哪能受得了？
可是，洒家也只能默不作声两行泪。要知道，在许多IT公司中，过了35岁就被扫地出门了，不舍得招人的领导还能听你在这儿叨逼叨地抱怨？你忙你累，你还有理了？
问君能有几多愁，摸摸自己光溜溜的头！
二
那么，问题来了，手写代码为什么会那么累撒？
记住有位经济学砖家说过，我国经济发展的一切问题都是由于准则没有理顺。同理，手写代码累人的原因在于开发进程没有理顺。
先看看手写代码遵从的开发进程：需求界说->规划->完成->测验与验证。
这儿的四个阶段看起来形似连接，其实在很大程度上是各自独立的。试为诸君细剖之。
需求界说，望文生义，搞清楚所开发产品有哪些功用、功能、标准上的要求，它的输出是一些文本文档。
有人说，我国科技不发达的原因之一就在于汉语的含糊和歧义性。虽然汉语毫无因由地背了这么大一个锅着实委屈，可是，在文档方法的需求界说中，各色人等对需求的了解的确是“横看成岭侧成峰，远近凹凸各不同”。
千人千面，无法一致，这就为缝隙和缺点埋下了火药线。
再看规划阶段，规划人员依照需求文档规划原型，挑选架构，区分模块。在这个阶段，可能会搭个电路，买个开发板，做一些什物原型，看看自己的思路是否可行。可是明显，这种方法十分地耗时、好本钱，一同也很不完好。
到了完成阶段，先声明一点，大部分嵌入式软件工程师都是把规划阶段和完成阶段混在一同的。这个阶段，工程师会凭借各种开发东西，开端手艺编码代码。手写代码考究个心到、眼到、手敲，用脚丫子都能想得到，这种方法特别地简单引进人为过错。
最终是测验阶段，也是开发进程的最终一个阶段。一般，测验人员在该阶段介入进来，对照着需求逐条测验。在整个链条的最终一环查找并修正过错，会花费很大的时刻和人力本钱。
各个阶段之间，实际上都有一道墙横亘在那里。
从需求剖析到规划，文本文档的歧义性和含糊性可能会让你误入歧途，成为日后危险的导火索。
从规划到完成，李宗盛大哥说：“已然不是仙，不免有杂念”，洒家说：“已然有杂念，不免会智商掉线”，然后在编码中埋下一个又一个天雷滚滚，日后劈得自己外焦里嫩。
从完成到测验，面临的便是一道肉墙了。测验大姐带着饱满的脂肪在你面前一站，一边说落你不遵从编码规矩的自由散漫，一边控诉你糟糕的编程经历，你说你尴尬不尴尬？
三
只提问题不说答案的都是在耍流氓。洒家风姿潇洒，天然是要脸面的。
洒家开的药方便是，根据模型的规划（MBD）。
MBD，是以模型为中心，对算法进行建模、验证，并支撑文档主动化、主动代码生成。
仍是依照上面的四个阶段，比照一下MBD的优势。
在需求剖析阶段，MBD的输出结果是一个可视化的模型，不同的人运用相同的模型。
它的优势在于：比较于文本文档，可视化的图形模型显得十分清楚、明晰，最要害的是明晰一致且仅有的需求，便于人们的沟通。洒家认为，图形化的模型是消解汉语歧义性的最佳手法，各位看官认为然否？
规划阶段能够认为是一个模型不断细化的进程，跟着模型的细化，验证能够一同进行，没错，传统开发流程中第四个阶段-测验能够提前到规划阶段来进行了。它的优点在哪里呢？
佛门有句话，“不怕念起，只怕觉迟”。在“打得想法死，许汝法身活”的语境中，起心动念是不对的，要早点消除，不要察觉地太迟。在软件开发上也是如此，要尽可能在前期发现过错，这样会给后续的开发进程带来许多便当。
在手写代码的传统流程中，尽早发现问题靠的是“评定”，可是明显那只适用于大公司。据我一个在大公司干过活的同学讲，写了文档后要评定，做了规划后要评定，敲完代码后要评定，弄完测验用例仍是要评定，没完没了的评定，功率实在是低。
现在好了，MBD在“前期”规划阶段便能够做测验和验证，然后将过错的预兆尽早地摧残在了摇篮里。
再下一个便是完成阶段。MBD正是在这个阶段，极大地解放了码农的生产力，由于您不必手写代码啦，MBD支撑主动代码生成！
靠机器而不是人写代码，这适宜吗？合理吗？
好吧，人类是核算机的造物主，可是在这儿，咱不谈精力，不说魂灵。
有必要供认的是，核算机在生成代码方面的确要比人类的才智高，且不说他们支撑好几种生成方法，能够挑选功率优先，或许RAM优先，人家还能够主动支撑MISRA-C编码标准，光这一条，还不得秒一大街码农？
没有情感的核算机消除了编码阶段的人为过错，便是对码农最大的温情！
最终一个测验阶段不必说了，由于在MBD规划里，这四个阶段之间没有“墙”，模型不断细化，测验验证是继续进行的，在前期就引进了验证，把过错消除在前期，尽可能降低了修正的本钱。
四
提到这儿，老码农们也不要悲伤，觉得脊梁骨发凉。都主动代码生成了，公司领导要是拿自己开刀咋办？
需求明晰的是，MBD并非彻底不需求软件工程师的聪明才智了，比如对程序中各种变量、函数的命名，无论是手写代码仍是MBD方法都很重要，程序规划中的命名是一个充溢创造力的当地，一个智商不到两岁小孩的核算机能起好名？
在MBD规划中，需求码农动用自己的创造力来注重标识符命名。由于好的命名具有极强、极精准的描绘才能，能够明晰地表达函数或变量的意义，这样会添加程序的可读性和可维护性，也能够在必定程度上消除不必要的注释。
其次，在底层驱动上，也很难引证MBD方法，由于在许多应用领域中，底层驱动是比较复杂的，输入驱动、输出驱动、通讯驱动、特别器材的驱动等等这些，仍然是手写代码的全国。
还有通讯、确诊、操作体系这些东西，用MBD很难完成，并且也没有优势，还不得靠咱？
所以，一般的情形是：在一个产等第的开发中，会在一个大体系中的一个使命中或许ISR中，把MBD完成的算法放进去，其它当地，仍然是手写代码的全国。将代码集成到整个嵌入式体系的软件中时，仍然需求手写代码的经历。
那种试图让MBD替代一切编码作业，是傲慢的，也是不现实的。
跋文
从手写代码到MBD，是一种开发流程思想的革新。
在这个过渡的进程中，不要有太大的担负和畏难心思。无论是手写代码仍是MBD的主动代码生成，便是个东西，一层窗户纸的事儿。没有捅破之前觉得很难，可是一旦捅破了，不过尔尔。
革新革新，革掉自己的命，方能迎来重生。往日种种比如昨日死，今天种种比如今天生。
在这个不断添加的年岁，期望各位老码农尽早转型到根据模型的规划上来。
我喜欢你们！
