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

只見，那月光般柔和的臉上竟沒有一絲絲皺紋，如水的大眼睛秋波蕩漾，攝人心魂，一口細碎的小白牙洋溢著滿滿的青春氣息，仿佛在訴說著無言的柔情蜜意。

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

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

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

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

一

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

保溫杯里泡上滿滿的枸杞，也無法找回當年滿當當?shù)幕盍Α?/p>

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

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

這當然不是因為灑家謀求轉型，想從科研一線逃離，走向“一壺水一包煙，晃晃悠悠過一天”的管理崗位。而是靠著手寫代碼干活吃飯、掙錢養(yǎng)家的灑家，實在是覺得手工編碼越來越辛苦了。

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

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

可是，灑家也只能默默無言兩行淚。要知道，在好多IT公司中，過了35歲就被掃地出門了，不舍得招人的領導還能聽你在這里叨逼叨地訴苦？你忙你累，你還有理了？

問君能有幾多愁，摸摸自己光禿禿的頭！

二

那么，問題來了，手寫代碼為什么會那么累撒？

記得有位經(jīng)濟學磚家說過，中國經(jīng)濟發(fā)展的所有問題都是因為制度沒有理順。同理，手寫代碼累人的原因在于開發(fā)過程沒有理順。

先看看手寫代碼遵循的開發(fā)過程：需求定義->設計->實現(xiàn)->測試與驗證。

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

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

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

千人千面，無法統(tǒng)一，這就為漏洞和缺陷埋下了火藥線。

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

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

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

各個階段之間，實際上都有一道墻橫亙在那里。

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

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

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

三

只提問題不說答案的都是在耍流氓。灑家風度翩翩，自然是要臉面的。

灑家開的藥方便是，基于模型的設計（MBD）。

MBD，是以模型為核心，對算法進行建模、驗證，并支持文檔自動化、自動代碼生成。

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

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

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

設計階段可以認為是一個模型不斷細化的過程，隨著模型的細化，驗證可以同時進行，沒錯，傳統(tǒng)開發(fā)流程中第四個階段-測試可以提前到設計階段來進行了。它的好處在哪里呢？

佛門有句話，“不怕念起，只怕覺遲”。在“打得念頭死，許汝法身活”的語境中，起心動念是不對的，要早點消除，不要覺察地太遲。在軟件開發(fā)上也是如此，要盡可能在早期發(fā)現(xiàn)錯誤，這樣會給后續(xù)的開發(fā)過程帶來很多便利。

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

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

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

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

好吧，人類是計算機的造物主，但是在這里，咱不談精神，不說靈魂。

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

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

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

四

說到這里，老碼農(nóng)們也不要傷心，覺得脊梁骨發(fā)涼。都自動代碼生成了，公司領導要是拿自己開刀咋辦？

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

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

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

還有通信、診斷、操作系統(tǒng)這些東西，用MBD很難實現(xiàn)，而且也沒有優(yōu)勢，還不得靠咱？

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

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

后記

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

在這個過渡的過程中，不要有太大的負擔和畏難心理。無論是手寫代碼還是MBD的自動代碼生成，就是個工具，一層窗戶紙的事兒。沒有捅破之前覺得很難，但是一旦捅破了，不過爾爾。

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

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

我愛你們！