不斷增長(cháng)的年紀，需要盡快轉向基于模型的設計

據說(shuō)，中國的手機都帶有美顏和減齡功能，每每在朋友圈里看到女同學(xué)自己拍的凍齡自拍照，總是感到穿越般的恍惚不已：難道，這就是當年的“翠花”？

只見(jiàn)，那月光般柔和的臉上竟沒(méi)有一絲絲皺紋，如水的大眼睛秋波蕩漾，攝人心魂，一口細碎的小白牙洋溢著(zhù)滿(mǎn)滿(mǎn)的青春氣息，仿佛在訴說(shuō)著(zhù)無(wú)言的柔情蜜意。

再看那茭白的臉蛋蛋和嬌滴滴的紅唇，就像要透過(guò)手機的屏幕，貼到我的眼前，輕輕地說(shuō)：我的臉龐，就像那皎潔的月光，想不想踩在我的鼻尖上，撫摸那溫柔的月光？

但是，有的時(shí)候，她們的朋友圈竟而也會(huì )有漏網(wǎng)之魚(yú)。

在受制于手機算力無(wú)法群體美顏的集體照里，歲月這把無(wú)情的照妖鏡，殘酷地揭開(kāi)了昨日美女的畫(huà)皮，暴露了她們奔四的年紀！

是的，她們當年的小伙伴-灑家，也開(kāi)始奔四了。

一

中年男不一定油膩，但是肯定會(huì )間或感到精力不濟，想提起神，做些深度的思考和學(xué)習，但總覺(jué)腦袋里沒(méi)有足夠的電力，只能淺嘗輒止，扼腕嘆息。

保溫杯里泡上滿(mǎn)滿(mǎn)的枸杞，也無(wú)法找回當年滿(mǎn)當當的活力。

對于腦力工作者而言，這絕對是個(gè)大忌！

灑家不煙不酒不油膩，鍛煉身體，不打游戲，但是，隨著(zhù)慢慢地上了年紀，也開(kāi)始經(jīng)常感到精力不濟。其中有一個(gè)突出的表現：越來(lái)越不愿意手寫(xiě)代碼了。

這當然不是因為灑家謀求轉型，想從科研一線(xiàn)逃離，走向“一壺水一包煙，晃晃悠悠過(guò)一天”的管理崗位。而是靠著(zhù)手寫(xiě)代碼干活吃飯、掙錢(qián)養家的灑家，實(shí)在是覺(jué)得手工編碼越來(lái)越辛苦了。

廣大人民群眾對美好生活的期待，加上當今世界的算力不斷增長(cháng)，導致嵌入式產(chǎn)品中的代碼量呈現爆炸式的增長(cháng)。作為一名小公司的嵌入式軟件工程師，盡管自己的經(jīng)驗與日俱增，但是悲催的是，經(jīng)驗永遠趕不上工作量增長(cháng)的速度，加上公司“唯利是圖”，不可能招聘更多工程師來(lái)幫忙分擔，所以自然越來(lái)越累。

但是，還有另一方面同時(shí)也是最重要的原因：手寫(xiě)代碼非常燒腦，喝涼水睡涼炕全靠火力壯的小伙子還能扛得住，奔四的老碼農哪能受得了？

可是，灑家也只能默默無(wú)言?xún)尚袦I。要知道，在好多IT公司中，過(guò)了35歲就被掃地出門(mén)了，不舍得招人的領(lǐng)導還能聽(tīng)你在這里叨逼叨地訴苦？你忙你累，你還有理了？

問(wèn)君能有幾多愁，摸摸自己光禿禿的頭！

二

那么，問(wèn)題來(lái)了，手寫(xiě)代碼為什么會(huì )那么累撒？

記得有位經(jīng)濟學(xué)磚家說(shuō)過(guò)，中國經(jīng)濟發(fā)展的所有問(wèn)題都是因為制度沒(méi)有理順。同理，手寫(xiě)代碼累人的原因在于開(kāi)發(fā)過(guò)程沒(méi)有理順。

先看看手寫(xiě)代碼遵循的開(kāi)發(fā)過(guò)程：需求定義->設計->實(shí)現->測試與驗證。

這里的四個(gè)階段看起來(lái)貌似連貫，其實(shí)在很大程度上是各自獨立的。試為諸君細剖之。

需求定義，顧名思義，搞清楚所開(kāi)發(fā)產(chǎn)品有哪些功能、性能、標準上的要求，它的輸出是一些文本文檔。

有人說(shuō)，中國科技不發(fā)達的原因之一就在于漢語(yǔ)的模糊和歧義性。雖說(shuō)漢語(yǔ)毫無(wú)來(lái)由地背了這么大一個(gè)鍋著(zhù)實(shí)冤枉，但是，在文檔形式的需求定義中，各色人等對需求的理解確實(shí)是“橫看成嶺側成峰，遠近高低各不同”。

千人千面，無(wú)法統一，這就為漏洞和缺陷埋下了火藥線(xiàn)。

再看設計階段，設計人員按照需求文檔設計原型，選擇架構，劃分模塊。在這個(gè)階段，可能會(huì )搭個(gè)電路，買(mǎi)個(gè)開(kāi)發(fā)板，做一些實(shí)物原型，看看自己的思路是否可行。但是顯然，這種方式非常地耗時(shí)、好成本，同時(shí)也很不完整。

到了實(shí)現階段，先聲明一點(diǎn)，大部分嵌入式軟件工程師都是把設計階段和實(shí)現階段混在一起的。這個(gè)階段，工程師會(huì )借助各種開(kāi)發(fā)工具，開(kāi)始手工編碼代碼。手寫(xiě)代碼講究個(gè)心到、眼到、手敲，用腳丫子都能想得到，這種方式特別地容易引入人為錯誤。

最后是測試階段，也是開(kāi)發(fā)過(guò)程的最后一個(gè)階段。一般，測試人員在該階段介入進(jìn)來(lái)，對照著(zhù)需求逐條測試。在整個(gè)鏈條的最后一環(huán)查找并修復錯誤，會(huì )花費很大的時(shí)間和人力成本。

各個(gè)階段之間，實(shí)際上都有一道墻橫亙在那里。

從需求分析到設計，文本文檔的歧義性和模糊性可能會(huì )讓你誤入歧途，成為日后隱患的導火線(xiàn)。

從設計到實(shí)現，李宗盛大哥說(shuō)：“既然不是仙，難免有雜念”，灑家說(shuō)：“既然有雜念，難免會(huì )智商掉線(xiàn)”，從而在編碼中埋下一個(gè)又一個(gè)天雷滾滾，日后劈得自己外焦里嫩。

從實(shí)現到測試，面對的便是一道肉墻了。測試大姐帶著(zhù)豐滿(mǎn)的脂肪在你面前一站，一邊說(shuō)落你不遵循編碼規則的自由散漫，一邊控訴你蹩腳的編程經(jīng)驗，你說(shuō)你難堪不難堪？

三

只提問(wèn)題不說(shuō)答案的都是在耍流氓。灑家風(fēng)度翩翩，自然是要臉面的。

灑家開(kāi)的藥方便是，基于模型的設計（MBD）。

MBD，是以模型為核心，對算法進(jìn)行建模、驗證，并支持文檔自動(dòng)化、自動(dòng)代碼生成。

還是按照上面的四個(gè)階段，對比一下MBD的優(yōu)勢。

在需求分析階段，MBD的輸出結果是一個(gè)可視化的模型，不同的人使用相同的模型。

它的優(yōu)勢在于：相比于文本文檔，可視化的圖形模型顯得非常清楚、明確，最關(guān)鍵的是明確統一且唯一的需求，便于人們的交流。灑家認為，圖形化的模型是消解漢語(yǔ)歧義性的最佳手段，各位看官以為然否？

設計階段可以認為是一個(gè)模型不斷細化的過(guò)程，隨著(zhù)模型的細化，驗證可以同時(shí)進(jìn)行，沒(méi)錯，傳統開(kāi)發(fā)流程中第四個(gè)階段-測試可以提前到設計階段來(lái)進(jìn)行了。它的好處在哪里呢？

佛門(mén)有句話(huà)，“不怕念起，只怕覺(jué)遲”。在“打得念頭死，許汝法身活”的語(yǔ)境中，起心動(dòng)念是不對的，要早點(diǎn)消除，不要覺(jué)察地太遲。在軟件開(kāi)發(fā)上也是如此，要盡可能在早期發(fā)現錯誤，這樣會(huì )給后續的開(kāi)發(fā)過(guò)程帶來(lái)很多便利。

在手寫(xiě)代碼的傳統流程中，盡早發(fā)現問(wèn)題靠的是“評審”，但是顯然那只適用于大公司。據我一個(gè)在大公司干過(guò)活的同學(xué)講，寫(xiě)了文檔后要評審，做了設計后要評審，敲完代碼后要評審，弄完測試用例還是要評審，沒(méi)完沒(méi)了的評審，效率實(shí)在是低。

現在好了，MBD在“早期”設計階段便可以做測試和驗證，從而將錯誤的苗頭盡早地扼殺在了搖籃里。

再下一個(gè)便是實(shí)現階段。MBD正是在這個(gè)階段，極大地解放了碼農的生產(chǎn)力，因為您不用手寫(xiě)代碼啦，MBD支持自動(dòng)代碼生成！

靠機器而不是人寫(xiě)代碼，這合適嗎？合理嗎？

好吧，人類(lèi)是計算機的造物主，但是在這里，咱不談精神，不說(shuō)靈魂。

必須承認的是，計算機在生成代碼方面確實(shí)要比人類(lèi)的智慧高，且不說(shuō)他們支持好幾種生成方式，可以選擇效率優(yōu)先，或者RAM優(yōu)先，人家還可以自動(dòng)支持MISRA-C編碼規范，光這一條，還不得秒一大街碼農？

沒(méi)有情感的計算機消滅了編碼階段的人為錯誤，便是對碼農最大的溫情！

最后一個(gè)測試階段不用說(shuō)了，因為在MBD設計里，這四個(gè)階段之間沒(méi)有“墻”，模型不斷細化，測試驗證是持續進(jìn)行的，在早期就引入了驗證，把錯誤消滅在早期，盡可能降低了修復的成本。

四

說(shuō)到這里，老碼農們也不要傷心，覺(jué)得脊梁骨發(fā)涼。都自動(dòng)代碼生成了，公司領(lǐng)導要是拿自己開(kāi)刀咋辦？

需要明確的是，MBD并非完全不需要軟件工程師的聰明才智了，比如對程序中各種變量、函數的命名，無(wú)論是手寫(xiě)代碼還是MBD方式都很重要，程序設計中的命名是一個(gè)充滿(mǎn)創(chuàng )造力的地方，一個(gè)智商不到兩歲小孩的計算機能起好名？

在MBD設計中，需要碼農動(dòng)用自己的創(chuàng )造力來(lái)重視標識符命名。因為好的命名具有極強、極精準的描述能力，能夠清晰地表達函數或變量的含義，這樣會(huì )增加程序的可讀性和可維護性，也可以在一定程度上消除不必要的注釋。

其次，在底層驅動(dòng)上，也很難引用MBD方式，因為在很多應用領(lǐng)域中，底層驅動(dòng)是比較復雜的，輸入驅動(dòng)、輸出驅動(dòng)、通信驅動(dòng)、特殊器件的驅動(dòng)等等這些，依然是手寫(xiě)代碼的天下。

還有通信、診斷、操作系統這些東西，用MBD很難實(shí)現，而且也沒(méi)有優(yōu)勢，還不得靠咱？

所以，通常的情景是：在一個(gè)產(chǎn)品級的開(kāi)發(fā)中，會(huì )在一個(gè)大系統中的一個(gè)任務(wù)中或者ISR中，把MBD實(shí)現的算法放進(jìn)去，其它地方，仍然是手寫(xiě)代碼的天下。將代碼集成到整個(gè)嵌入式系統的軟件中時(shí)，依然需要手寫(xiě)代碼的經(jīng)驗。

那種妄圖讓MBD取代所有編碼工作，是狂妄的，也是不現實(shí)的。

后記

從手寫(xiě)代碼到MBD，是一種開(kāi)發(fā)流程思維的革命。

在這個(gè)過(guò)渡的過(guò)程中，不要有太大的負擔和畏難心理。無(wú)論是手寫(xiě)代碼還是MBD的自動(dòng)代碼生成，就是個(gè)工具，一層窗戶(hù)紙的事兒。沒(méi)有捅破之前覺(jué)得很難，但是一旦捅破了，不過(guò)爾爾。

革命革命，革掉自己的命，方能迎來(lái)新生。往日種種譬如昨日死，今日種種譬如今日生。

在這個(gè)不斷增長(cháng)的年紀，希望各位老碼農盡早轉型到基于模型的設計上來(lái)。

我愛(ài)你們！