優秀實踐 #1 – 使用抽象層移除依賴項

審查代碼庫的常見問題之一是開發人員將他們的應用程序代碼與他們使用的軟件庫緊密結合在一起。例如，如果開發人員正在使用 FreeRTOS，他們的應用程序代碼會調用特定于 FreeRTOS API 的方式，如果開發人員決定更改他們的 RTOS，他們將不得不重寫大量代碼來替換所有這些 RTOS來電。你可能會認為更改庫很少見，但你會驚訝于團隊經常使用一個操作系統、庫或組件開始一條路徑，只是在他們決定需要進行更改時才不得不返回并重寫代碼。

團隊在選擇開源組件甚至商業組件時應該做的第一件事是創建一個抽象層來與該組件進行交互。以 RTOS 為例，團隊將使用 OS 抽象層 OSAL，這將允許他們使用獨立于 OS 的 API 編寫應用程序代碼。如果操作系統發生變化，應用程序并不關心，因為它正在訪問一個抽象層，而軟件更改可能需要幾分鐘而不是幾天。

優秀實踐 #2 – 盡可能利用集成軟件

大多數開源軟件都是在自己的沙箱中編寫的，沒有過多考慮可能需要與之交互的其他組件。組件通常使用不同的編碼標準、風格、測試程度等來編寫。如果嵌入式開發人員開始將多個并非旨在相互協作的開源組件組合在一起時，可能會導致長時間的調試會話和錯過最后期限，盡可能選擇已經集成和測試的組件。

一個很好的例子是使用 Amazon FreeRTOS 連接到 AWS。FreeRTOS 已經與連接到云所需的其他連接庫進行了集成和測試，因此不要選擇其他庫，除非它也已經過測試和集成。另一個例子是許多微控制器制造商生產的代碼生成器工具。這些工具通常已經集成了驅動軟件組件、RTOS、文件系統、USB 和其他幾個組件。它們已經被證明可以一起工作，因此如果可以利用它們，它將節省時間和金錢。

優秀實踐#3——執行軟件審計和質量分析

有很多很棒的開源軟件和很多不太好的軟件，在開發人員決定在他們的項目中使用開源組件之前，他們需要確保他們花時間對軟件進行盡職調查，這涉及花時間審核組件并執行質量分析，質量往往在旁觀者的眼中。

至少，在開始使用開源組件時，應審查源代碼：

• 使用圈復雜度測量的復雜度
• 在功能上確保它滿足業務需求和目標
• 遵守最佳實踐和編碼標準(根據需要)
• 處理錯誤的能力
• 可測試性

至少，這將幫助嵌入式開發人員了解他們正在使用什么，以及潛在的問題和陷阱。

優秀實踐#4 – 讓律師審查許可證

開源軟件許可可能難以駕馭，有十幾種不同的許可方案，它們對用戶提出了不同的要求。在某些情況下，開發人員可以按照他們認為合適的方式使用開源軟件。在其他情況下，可以使用該軟件，但任何其他軟件也必須是開源的，這意味著它可能需要發布產品的秘方，這可能會損害他們的競爭市場優勢。

盡管近年來這些許可證變得更加易于理解，但產品開發人員正在開展業務，因此必須聘請律師來審查軟件許可證，以確保一切正常。會有額外的費用，但它是經商成本的一部分，如果發生錯誤，從長遠來看可以節省資金。

優秀實踐 #5 – 從活躍的社區中選擇軟件

快速進行網絡搜索或仔細閱讀 github 以找到解決問題的軟件組件總是很誘人。嵌入式開發人員在選擇開源組件時，確保該組件具有活躍的社區非常重要。

例如，使用 FreeRTOS 的開發人員知道他們可以上論壇、提出問題，并且通常會得到快速響應。新版本會定期發布，并且軟件始終會隨著新功能的添加而不斷改進。選擇具有不活躍社區的組件可能會導致開發人員獨自一人，被迫自己找出問題，或者更糟糕的是，不得不維護該組件。

結論

正確利用開源軟件可以極大地使開發團隊受益。然而，為了取得成功，開發人員需要確保他們明智地選擇他們的開源組件，這包括抽象出組件以確保其應用程序保持靈活和可維護。它還需要仔細審查開源軟件，假設它不是 Linux，以確保在提交組件之前滿足質量和一般要求。

遵循這些最佳實踐可以幫助嵌入式開發團隊避免導致產品延遲、架構不佳的解決方案、質量問題以及產品開發過程中經常出現的許多其他問題的泥潭。