前言
開源軟件無處不在,有潛力幫助企業加快開發和提高軟件質量。但如果不謹慎行事,它們可能是一個挑戰。
下面是五個成功利用開源軟件的最佳實踐。
1、使用抽象層解決依賴關系
筆者審閱代碼庫時發現的一個常見問題是,開發人員將應用程序代碼與使用的軟件庫緊耦合。例如,如果一個開發人員正在使用FreeRTOS,那么應用程序代碼調用特定于FreeRTOS API的方法是,如果開發人員決定更改RTOS,則必須重寫大量代碼來替換所有這些RTOS調用。
你可能會認為更改庫是很少見的,但你會驚訝,經常是團隊開始使用某個操作系統、庫或組件后,而當他們決定需要進行更改時,卻不得不返回并重寫代碼。
當團隊選擇一個開源組件,甚至是商業組件時,他們應該做的第一件事就是創建一個與該組件交互的抽象層。以RTOS為例,一個團隊應該使用OS抽象層OSAL(它允許他們使用獨立于OS的API編寫應用程序代碼)。
如果操作系統發生變化,應用程序不會在意,因為它正在訪問一個抽象層,軟件更改可能只需要幾分鐘而不是幾天。
2、盡可能利用集成軟件
大多數開源軟件都是在自己的沙盒中編寫的,而沒有考慮到它可能需要與之交互的其他組件。組件通常使用不同的編碼標準、樣式、測試程度等編寫。
當你開始將多個設計為不能相互協作的開源組件組合在一起時,可能會導致長時間的調試、頭疼和錯過最后期限。所以,盡可能選擇已經集成并測試在一起的組件。
一個很好的例子是使用Amazon FreeRTOs連接AWS。FreeRTOS已經與連接到云所需的附加連接庫進行了集成和測試,因此不要選擇其他庫,除非它也經過測試和集成。另一個例子是許多微控制器制造商生產的代碼生成器工具。
這些工具通常已經集成了驅動程序軟件組件、RTOS、文件系統、USB和其他一些組件。它們已經被證明可以協同工作,可以節省時間和金錢。
3、執行軟件審核和質量分析
有很多優秀的開源軟件,也有很多不太好的軟件。在開發人員決定在項目中使用開源組件之前,他們需要確保他對軟件進行盡職調查,或者雇傭別人做這件事。這包括花時間審核組件并執行質量分析。
在開始使用開源組件時,至少應檢查源代碼的以下方面:使用圈復雜度度量的復雜性、從功能上確保其滿足業務需求和目標、遵守最佳實踐和編碼標準(根據需要)、處理錯誤的能力、可測試性。
這至少可以幫助開發人員了解他們正在使用什么,以及潛在的問題和陷阱。
4、從活躍社區中選擇軟件
通過快速的網絡搜索或瀏覽github來找到解決問題的軟件組件總是很誘人的。在選擇一個開源組件時,確保其有一個活躍的社區是非常重要的。
這包括,在論壇上提問會得到快速的響應,新版本會定期發布,軟件也會隨著新功能的增加而不斷改進。選擇一個不活躍的社區的組件會導致開發人員被迫自己解決問題,或者更糟的是,不得不維護組件。
5、由律師審查許可證
開源軟件許可可能很復雜。有十幾種不同的許可方案,對用戶提出了不同的要求。在某些情況下,開發人員可以使用他們認為合適的開源軟件。在其他一些情況下,可以使用該軟件,但任何其他軟件也必須是開源的。
雖然這些許可證在最近幾年變得更加容易理解,但是產品開發人員正在經營一項業務,因此有必要聘請一名律師來審查軟件許可。這是一項額外的開支,但這是成本的一部分,從長遠來看可以節省開支。
結論
適當地利用開源軟件可以使開發團隊受益匪淺。然而,為了成功,開發人員需要確保明智地選擇開源組件。這包括抽象出組件,以確保其應用程序保持靈活性和可維護性。還需要仔細檢查開源軟件,以確保滿足質量和一般要求。
遵循這些最佳實踐可以幫助團隊避免陷入導致產品延遲、解決方案架構不良的解決方案、質量問題以及產品開發過程中經常出現的許多其他問題的泥潭。
-
開源軟件
+關注
關注
0文章
209瀏覽量
15889 -
RTOS
+關注
關注
22文章
809瀏覽量
119451 -
FreeRTOS
+關注
關注
12文章
483瀏覽量
62018
原文標題:嵌入式項目中使用開源項目,需要注意哪些問題?
文章出處:【微信號:最后一個bug,微信公眾號:最后一個bug】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論