嵌入式軟件設計上的經(jīng)驗與感悟
時間：2021-10-26 14:23:29
手機看文章
掃描二維碼
隨時隨地手機看文章
[導讀]今天回到了深圳，開始了今年最后4個月的工作，一年的時間真的過得挺快的，2021年又只剩下三分之一了，在返程途中思考了很多，有對未來的憧憬，也有擔憂~或許人生也跟代碼中的bug一樣需要邊寫邊解吧。bug菌比較習慣集中抽出一些時間交流一些問題，所以在途中跟很多朋友聊到了學習、技術和生...
今天回到了深圳，開始了今年最后4個月的工作，一年的時間真的過得挺快的，2021年又只剩下三分之一了，在返程途中思考了很多，有對未來的憧憬，也有擔憂~或許人生也跟代碼中的bug一樣需要邊寫邊解吧。
bug菌比較習慣集中抽出一些時間交流一些問題，所以在途中跟很多朋友聊到了學習、技術和生活上的一些事情，同時也對比了一下自己之前走過的路，所以就有了這篇關于軟件開發(fā)設計經(jīng)驗與心得與體會：
1、思路不清晰，不要輕易敲代碼
個人覺得代碼這些東西，都是思維的產(chǎn)物，更何況現(xiàn)在也出現(xiàn)非常多的非代碼類語言，比如labview等等。
剛開始學習編程的我也一直認為代碼是敲出來的，一旦有新的軟件需求，就噼里啪啦代碼敲個不停，然而逐漸的發(fā)現(xiàn)這樣敲出來的代碼不僅質(zhì)量不咋樣，以后多半會遭到“無情的拋棄”。這也是很多朋友"敲三行刪兩行"尷尬場面的重要原因。
思維指導行為，這些都是學校學習哲學、馬克思老師經(jīng)常提到的，如果你手上還有這些指導思想的書籍，閑暇十分可以回味一下，會發(fā)現(xiàn)很多設計思想都有諸多相似之處~
2、狀態(tài)機與流程圖
既然要理清楚思路當然記憶力和邏輯思維足夠強大，也是沒有問題的。
一般人應該做不到，還得借助一些工具，簡單點的話那就紙、筆，畫個大體的框圖等；復雜一點的還是需要借助專業(yè)的工具，比如思維導圖，統(tǒng)一建模語言UML等。
特別要跟大家介紹的是UML，它對于嵌入式朋友們可能還有點陌生，其采用一種面向?qū)ο蟮姆绞絹頌橄到y(tǒng)建立一個模型和描述，其主要是圖形的方式表述，類似于進行控制器設計前需要建立一下系統(tǒng)的控制模型，同樣軟件編碼設計也需要這樣一個模型，那么bug菌推薦UML。
有了這些輔助工具來設計軟件，這樣就能從整體上把控軟件的脈絡和組織，對后續(xù)軟件功能的增、刪、改都能有一個比較清晰的把握。
同樣狀態(tài)機也是必不可少的，一個功能分哪些狀態(tài)，每個狀態(tài)該如何轉(zhuǎn)移，似乎看起來沒什么難的，畢竟狀態(tài)機的實現(xiàn)文章多如牛毛。
其實狀態(tài)機的難點并不在于狀態(tài)機的如何編碼實現(xiàn)，難點在于一個功能如何更加合理的把所有狀態(tài)和各狀態(tài)的轉(zhuǎn)移條件分好，狀態(tài)分太多，沒有意義，影響運行效率，程序冗長；狀態(tài)分得太少，每個狀態(tài)相對比較復雜，不便于模塊化，不好維護。
那問題來了，如何把狀態(tài)和狀態(tài)轉(zhuǎn)移區(qū)分好呢？這個問題有點難回答，針對不同的項目和需求，需要結合自身對該部分功能的理解和抽象，以及未來對此部分功能的擴展等綜合考慮。
3、編碼習慣與版本把控
所謂"沒有規(guī)矩不成方圓",編碼習慣bug菌也是在之前的文章中反復強調(diào)，因為直到現(xiàn)在我還時不時受到以前老項目的維護之苦。
我們得承認編程語言都一個樣，不過編程的思路和方式卻千差萬別，不同的人編碼習慣或者風格差異太大，猶如兩個互相不懂其語言的外國人，而文檔、注釋就是這中間的"翻譯官"。
而版本把控主要是為了各種文檔、設計資料的變更，類似于git這種分布式版本管理系統(tǒng)還是非常有必要的。
像我司要求負責開發(fā)項目的同事至少一天上傳一次設計資料及代碼，因為每個人粗心大意是難免的，經(jīng)常有后面的設計遠不如之前的情況，所以為了降低這塊的風險，版本的管控在軟件開發(fā)中是非常有必要的。
4、多參考官方資料
大部分軟件開發(fā)工程師都屬于應用型工程師，更多的是站在巨人的肩膀上來應對一些新的需求，所以很多成熟的、官方的技術知識更多的是詳細了解其如何使用，而非花太多的精力重復造輪子。
如今網(wǎng)絡化時代，文檔資料也是魚龍混雜，然而把官方、權威的文檔資料放在旁邊作為參考才會讓人更加安心。
END
來源：最后一個bug，作者：bug菌版權歸原作者所有，如有侵權，請聯(lián)系刪除。
▍
下載文檔
