新闻中心

EEPW首页 > 牛人业话 > 不断增长的年纪,需要尽快转向基于模型的设计

不断增长的年纪,需要尽快转向基于模型的设计

作者:麦宅客时间:2019-11-04来源:电子产品世界收藏

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

本文引用地址:/article/201911/406679.htm

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

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

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

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

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

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

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

对于脑力工作者而言,这绝对是个大忌!

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

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

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

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

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

问君能有几多愁,摸摸自己光秃秃的头!

那么,问题来了,手写代码为什么会那么累撒?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

洒家开的药方便是,基于模型的设计(MBD)。

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

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

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

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

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

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

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

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

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

靠机器而不是人写代码,这合适吗?合理吗?

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

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

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

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

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

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

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

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

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

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

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

后记

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

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

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

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

我爱你们!



关键词:

评论


相关推荐

技术专区

关闭
www.chuaqi.com
友情链接:幸运蛋蛋是真的吗  幸运蛋蛋开户  幸运蛋蛋开奖  幸运蛋蛋网址多少  幸运蛋蛋娱乐  幸运蛋蛋首页  幸运蛋蛋  幸运蛋蛋  幸运蛋蛋平台  幸运蛋蛋开奖