嵌入式硬體轉職軟體開發，這十點是必不可少的技能

3、避免使用全局變量

嵌入式特別是單片機os-less的程序，最易范的錯誤是全局變量滿天飛。這個現象在早期彙編轉型過來的程式設計師以及初學者中常見，這幫傢伙幾乎把全局變量當作函數形參來用。

在.h文檔裡面定義許多雜亂的結構體，extern一堆令人頭皮發麻的全局變量，然後再這個模塊裡邊賦值123，那個模塊裡邊判斷123分支決定做什麼。

不否認全局變量的重要性，但要十分謹慎地使用它，濫用全局變量會引申帶來其它更為嚴重的結構性系統問題。

它會造成不必要的常量頻繁使用，特別當這個常量沒有用宏定義「正名」時，代碼閱讀起來將萬分吃力。

它會導致軟體分層的不合理，全局變量相當於一條快捷通道，它容易使程式設計師模糊了「設備層」和「應用層」之間的邊界。寫出來的底層程序容易自作多情地關注起上層的應用。這在軟體系統的構建初期的確效率很高，功能調試進度一日千里，但到了後期往往bug一堆，處處「補丁」，雷區遍布。說是度日如年舉步維艱也不為過。

由於軟體的分層不合理，到了後期維護，哪怕僅是增加修改刪除小功能，往往要從上到下掘地三尺地修改，涉及大多數模塊，而原有的代碼注釋卻忘了更新修改，這個時候，交給後來維護者的系統會越來越像一個「泥潭」，注釋的唯一作用只是使泥潭上方再加一些迷煙瘴氣。

全局變量大量使用，少不了有些變量流連忘返於中斷與主迴圈程序之間。這個時候如果處理不當，系統的bug就是隨機出現的，無規律的，這時候初步顯示出病入膏肓的特徵來了，沒有大牛來力挽狂瀾，註定慢性死亡。

兩個原則對策

能不用全局變量儘量不用，除了系統狀態和控制參數、通信處理和一些需要效率的模塊，其他的基本可以靠合理的軟體分層和編程技巧來解決。

如果不可避免需要用到，那能藏多深就藏多深。

1)如果只有某.c文件用，就static到該文件中，順便把結構體定義也收進來；

2)如果只有一個函數用，那就static到函數裡面去；

3)如果非要開放出去讓人讀取，那就用函數return出去，這樣就是只讀屬性了；

4)如果非要賦值，開放函數接口傳參賦值；

5)實在非要extern強J我，還可以嚴格控制包含.h檔的對象，而不是放到公共的includes.h中被人圍觀，丟人現眼。

注意：避免使用，不是不讓使用！

4、利用模塊性的好處

無論問哪一名工程師，項目的哪部分最有可能延遲交付並超出預算？答案都是軟體。軟體往往是複雜的，且難以開發和維護，尤其是當整個應用都存在於單一文件或鬆散關聯的多個文件中時。為了緩解可維護性、可重用性及複雜性，強烈建議程式設計師充分利用現代程式語言的模塊化特性，將常用功能分解成模塊。

以這樣的方式分解編碼，程式設計師就能著手建立函數與特性庫，然後在一個接一個的應用中重用它們，從而通過連續測試而改善代碼質量，同時也減少了時間，降低了開發成本。

5、保持中斷服務例程的簡單性

中斷服務例程用來中斷處理器對當前代碼分支的執行，從而處理剛剛觸發中斷的外圍設備。無論何時執行中斷，都需要一定數量的開銷，用於保存當前程序的狀態、運行中斷，然後將處理器回歸原程序狀態。

現代處理器要比多年前的處理器快得多，但仍需要考慮此花銷。一般情況下，程式設計師都想把中斷運行時間降至最低，以避免干擾主代碼分支。這意味著中斷應該短而簡單。

中斷中不應調用函數。此外，如果中斷開始變得過於複雜或耗時，則僅應在必要時利用中斷做最少量的工作，例如，將數據裝入緩衝區並設置一個標誌，然後讓主分支處理輸入的數據。這樣做可保證大多數處理器周期被用於運行應用，而不是處理中斷。

6、使用示例代碼做外設的實驗

設計硬體時，做原型測試電路總是有益的，這樣可確保工程師對電路有正確的理解，然後再做電路板布局。此點對設計軟體也同樣適用。矽片製造商通常都有示例代碼，可用來測試微處理器的各個部分，這樣工程師們就可判定該部分的工作情況。

此方法使人們洞察到軟體體系架構的應該組織方式，以及可能造成的任何潛在問題。在設計初期階段認清潛在的障礙，比在產品交付前最後幾小時才發現它們要好。

這是預先測試代碼片段的一個很好的方法，但需提醒的是，製造商代碼往往不是模塊化的，未經大的修改不方便用於實際應用。這一局限已隨著時間的發展而改變，也許某一天晶片供應商會給出可用於生產的代碼。

7、限制功能複雜度

工程學中有一個舊詞叫「KISS」——保持簡單和直接。無論在處理何種複雜工作時，最簡單的方法就是把它分解為更小、更簡單、更易處理的任務。隨著工作或功能變得越來越複雜，人們要準確無誤地記錄所有的細節也變得更困難。

在寫一個函數時，其複雜度在當時看似適中，然而要考慮到，一名工程師如何在六個月的維護時間內查看代碼。測量函數複雜度（如循環的複雜度）的方法很多。現在有工具可以自動計算某個函數的循環複雜度。經驗法則建議，函數的循環複雜度保持在10以下是最理想的。

無論在處理何種複雜工作時，最簡單的方法就是把它分解為更易處理的任務。

8、使用原始碼存儲庫

人都是會犯錯誤的，寫代碼時也會犯錯。這就是為什麼開發人員使用原始碼存儲庫是如此重要。原始碼存儲庫可使開發人員「登記」一個好的代碼版本，並描述對該代碼所做的修改。該步驟不僅使得開發人員可以復原或追溯到代碼的舊版本，還可以比較舊版本之間的不同。

如果開發人員做的一系列改變破壞了系統，只需點擊一下即可恢復好的代碼版本！請謹記，如果不頻繁提交代碼，存儲庫就不會達到預期目的。如果做了不可逆的修改，兩周後才提交代碼，然後再恢復，就會造成大量工作和時間的損失！

9、代碼做詳細說明

在軟體開發的激烈戰鬥中，開發人員很容易把注意力集中在編寫和代碼上，因此會忽略詳細解釋的需求。在壓力之下，說明工作往往是項目的收尾工作，因為開發人員認為它是最後的一項工作。

然而，當代碼仍在你腦中新鮮熱火時就做出詳細解釋是至關重要的，這樣做可使開發人員或你自己讀懂注釋，理解代碼的工作方式。如果開發人員做的一系列改變破壞了系統，只需點擊一下即可恢復好的代碼版本！

10、學會模塊化編程、驅動分離

當項目小組做一個相對較複雜的工程時，意味著你不再獨自單幹。而是和小組成員分工合作，這就要求小組成員各自負責一部分工程。比如你可能只是負責通訊或者顯示這一塊。

這個時候，你就應該將自己的這一塊程序寫成一個模塊，單獨調試，留出接口供其它模塊調用。最後，小組成員都將自己負責的模塊寫完並調試無誤後，由項目組長進行組合調試。

像這些場合就要求程序必須模塊化。模塊化的好處是很多的，不僅僅是便於分工，它還有助於程序的調試，有利於程序結構的劃分，還能增加程序的可讀性和可移植性。

記住以下四點就可以了：

1.模塊即是一個.c文件和一個.h文件的結合，頭文件(.h)中是對於該模塊接口的聲明；

2.某模塊提供給其它模塊調用的外部函數及數據需在.h中文件中冠以extern關鍵字聲明；

3.模塊內的函數和全局變量需在.c文件開頭冠以static關鍵字聲明；

4.永遠不要在.h文件中定義變量！