一 背景
剛從學校出來實習那會兒，在深圳南山某龍電控公司上班，職位是售后維修，用伺服電機控制繡花機，有個顯示終端應該用的是桌面系統。一進公司就開始修板子，在經過一番培訓之后就出去駐場服務，看到軟件開發工程師來支持我們的工作，他們沒什么頭發，大部分都戴著眼鏡，看上去很厲害的樣子，他們拿著示波器的探頭，拿著萬用表打到二極管檔位，測量線路的通斷，當時真的很想成為這樣的人。
二 畢業后換工作
來到我人生中最重要的一家公司，有個老同事真的很熱心，手把手教我怎么看原理圖，為什么控制這個IO為高電平，三極管就輸出低電平，為什么電磁閥可以動起來，怎么控制繼電器，怎么寫代碼怎么畫原理圖，怎么畫PCB板，一條龍服務毫無保留地非常耐心地指導我，部門經理在下班后，等我們吃完飯手把手教我們怎么用JAVA與下位機通信，怎么創建線程，那段時光真的很美好，把我帶進了軟件開發行業。
三 感謝
非常感謝過去幫助過我的人，這個社會真的需要你們這樣的人，特別是剛畢業的學生，進到這樣一家公司真的是很不錯的選擇。
四 嵌入式軟件開發流程
因為大部分做的是嵌入式開發，所以是按照這個話題來開展
4.1 好的軟件深受4個人的喜愛和1個人的無奈
4.1.1 老板
通常老板都喜歡又快又好，交期快，訂單量大。前期應該達不到,但有了良好的框架后理論上是可以達到這種效果的。
4.1.2 多個用戶
傻瓜式操作、操作一步到位、快速上手、大量通俗易懂的手冊、查閱文檔自助解決問題、視頻教程、技術支持快速響應(客服機器人)、穩定可靠不會崩潰滿足一個用戶是比較簡單的，但是同時滿足不同的用戶就比較困難了,在技術支持方面我們需要引導用戶自助解決問題、提供通俗易懂的用戶手冊。
4.1.3 同事
代碼風格和編程思想良好、命名方式通俗易懂、有注釋、良好的設計架構、閱讀代碼不會難受、有豐富的通俗易懂的技術文檔，易于更新維護、易于跨平臺移植、沒有潛在的BUG。
4.1.4 自己
錢多事少，更新、維護、擴展、移植時只需更改少量代碼、或不用改代碼，軟件測試、領導簽字一次性通過，用戶使用過程中體驗良好，沒有收到任何BUG反饋，深受用戶喜愛。
4.1.5 軟件測試
測了半天沒有發現一個BUG,功能全部正常,一個版本都沒有升,感覺太無聊,沒有一點成就感，完全沒有發揮他的價值,他會感到很迷茫,甚至開始懷疑人生但是沒辦法，只能委屈一下他了。
五 具體實施方法
5.1 現場考察
用戶需求在開發之前,如果有現成的產品,最好去客戶現場了解一下,就像做生意先要踩點記錄一下人流量,人均消費水平,房租之類的同樣的道理,我們需要知道:
5.1.1 用戶使用現有產品體驗是否良好,操作是否方便,如何改進
5.1.2 用戶將來會遇到哪些問題
5.1.3 用戶遇到問題時,如何通過我們提供的資源,他自己獨立解決問題用戶能夠使用文檔或者現有功能來自己解決問題，可結合公眾號，服務器，數據庫
5.1.4 總結哪些尚未被滿足的、而又被廣泛渴望的需求(用戶痛點)
5.1.5 將以上用戶需求轉換成規范的開發計劃、開發文檔(硬件系統框架圖、軟件功能定義等)
5.2 設計原則
5.2.1 開閉原則
軟件設計應該在滿足功能需求的基礎上增加一些東西當應用的需求改變時，在不修改軟件實體的源代碼或者二進制代碼的前提下，可以擴展模塊的功能，使其滿足新的需求視覺反饋、觸感反饋，為什么要有反饋，可能是一個很深奧的話題了，可能跟人體分泌的多巴胺有關系，我不確定。以不變應萬變(無論用戶需求有什么變化，我們都不用改固件)，用戶的可變動需求，還可以通過(GPIO)(撥碼開關)或者其他通信接口來配置，把配置權交給硬件或者通信接口,交給用戶
5.2.2 有軟件框架和設計模式
5.2.3 有分層，做框架之前有個前提條件,要拿到功能定義、硬件系統框架圖
分好層之后,分別編譯成庫文件,后續獨立維護相應的庫文件即可，便于移植減少維護時地相互影響，改動時不影響其他功能
5.2.4 穩定可靠
不出錯,不崩潰(訪問了空地址、內存溢出、內存泄露、數組越界、堆棧溢出等)
5.2.5 參數檢查
有輸入參數的函數,要有參數檢查(排除所有可能的非法值)、錯誤處理、返回值用戶輸入是一個非常危險的事情,需要謹慎處理
5.2.6 自定義malloc
-不使用庫函數malloc動態申請或釋放內存創建內存池(靜態),自己實現申請和釋放的函數
-多任務時,需要對公共資源進行原子性訪問，防止數據出錯
5.2.7 重試機制
為了保證數據的有效傳輸,可能需要加入重試機制
5.2.8 易擴展、易維護更新軟件時,更改代碼量較少或無需更改代碼
5.2.9 抽象變動部分
-改宏定義,或者類、靜態鏈表、集合、數組等的定義,不更改過程將未來可能會變的部分抽象出來，定義成數組、靜態鏈表、集合等,使用通用的過程來處理可變的部分
-不支持編程語法的將未來可能會變的部分抽象到外部文件(xml,bin)，創建動態鏈表或者動態數組等再觸發遍歷
-支持編程語法的增加腳本解釋器,將未來可能會變的部分抽象到外部腳本文件(asm,lua,js,html,php)，創建動態鏈表或者動態數組等再觸發遍歷
5.2.10 有使用設計模式，例如工廠模式、創造者模式等
5.2.11 易維護,能夠快速定位異常(追溯)
5.2.12 JAVA、VB.NET、C#，不確定C 有這種方法增加全局異常捕捉事件,拋出異常時將具體文件名和行號追加寫入日志文件
5.2.13 有調試打印功能單片機可通過串口/LCD/并口(電腦主板)/PCI(電腦主板)來打印,串口/LCD/并口(電腦主板)/PCI(電腦主板)的讀寫字節函數映射到printf的相關讀寫字節函數上位機可通過控制臺打印，輸出到文件或者控制臺窗口
5.2.14 軟件層級之間通用的接口函數，便于移植跨平臺
-write2.7.2 read
-control(cmd,data,void*parameter)可以不斷地擴展新功能
-接口函數中void *作為輸入參數,可以傳遞任意類型任意長度的參數
5.2.15 必要的錯誤碼
幫助客戶自主解決問題,依賴于函數有返回值
5.2.16 有自檢功能
(硬件電路自檢)、上電自檢(通過指示燈來顯示，用于檢查IC，硬件電路等)3.1 當出現故障時,可通過系統自檢來鎖定問題,提示用戶排除原因，解決問題能夠便于移植(跨平臺)的原因
5.2.17 分層設計
抽象出通用的類，通用的接口函數，除非資源太少，不能支持面向對象編程思想
例如GPIO類有什么屬性，有什么接口函數，要兼容所有的平臺，就要按照擁有最多的屬性來做GPIO類
六 可實施步驟
嵌入式軟件開發可以遵循一定的流程來執行:
6.1 總結用戶需求，兼容多個用戶的需求
6.2 了解現有方案,總結用戶痛點(尚未被滿足的、而又被廣泛渴望的需求)
6.3 總結用戶可能會遇到的困難
6.4 總結如何引導用戶解決困難
6.4.1 將以上總結轉換成規范的開發計劃及技術文檔
6.5 輸出功能定義及設計要點(文檔)
6.6 輸出軟件框架圖(文檔)
6.7 輸出軟件流程圖(文檔)
6.8 確認以上文檔OK，開始寫代碼
6.8.1 確認好軟件測試計劃
6.9 軟件測試(自己)
6.10 軟件測試(正式)，輸出測試報告
6.11 更新改善
6.12 穩定性測試、可靠性測試、極端環境下測試
6.13 客戶驗收
6.14 客戶現場跟蹤，總結已知缺陷
6.15 持續改善
6.16 項目資料存檔，輸出測試文檔
七 總結
以上是我以個人工作經驗做的總結，不過我們的能力再好也要先提高自己的溝通能力，良好的溝通能力能夠讓我們打開彼此的心扉，讓家庭更加和諧，讓我們與朋友同事相處的更加融洽，讓我們更好地開展工作，最大限度的發揮我們的工作經驗和個人能力。
心有多大舞臺就有多大，我現在也成了嵌入式軟件工程師，但我還有更大的夢想，希望大家大膽去想象，大膽去挑戰，一起努力去做到心想事成。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。