功能實現(xiàn)了就行了？需要多考慮代碼的可移植性和可復(fù)用性！

時間：2021-11-15 14:42:41

關(guān)鍵字：代碼移植

手機看文章

掃描二維碼
隨時隨地手機看文章

[導(dǎo)讀]最近幾天在完成一個項目的EVT收尾工作，EVT這個名詞可能有些朋友不是很熟悉，EVT（EngineeringVerificationTest）表示進行工程驗證測試階段。一般的新產(chǎn)品開發(fā)都分為三個階段:EVT、DVT和PVT，EVT主要是調(diào)試單板，設(shè)計方案的可行性驗證，所以這個階段...

最近幾天在完成一個項目的EVT收尾工作，EVT這個名詞可能有些朋友不是很熟悉，EVT（Engineering Verification Test）表示進行工程驗證測試階段。

一般的新產(chǎn)品開發(fā)都分為三個階段 : EVT、DVT和PVT，EVT主要是調(diào)試單板，設(shè)計方案的可行性驗證，所以這個階段非常的關(guān)鍵，而后面幾個階段在流程比較成熟的公司，一般都是順理成章的事。前一段時間沒怎么更新，也主要是把更多的精力投入到了工作中，根據(jù)一直以來的習慣，每個項目的每個階段都會組織研發(fā)團隊進行復(fù)盤。

而這一次復(fù)盤給我感受頗深的是代碼的可移植性和可復(fù)用性，所以也就有了今天的文章。

代碼的價值

其實軟件都是朝著，高內(nèi)聚、低耦合、良好的可移植性以及較強的可復(fù)用性來不斷發(fā)展的，其中高內(nèi)聚和低耦合就不多說了，這兩點跟項目的軟件功能結(jié)構(gòu)劃分存在較大的聯(lián)系，而可移植性和可復(fù)用性就相對比較通用和獨立。

可移植性與我們平時所說的跨平臺能力比較相近，而軟件復(fù)用則是一種通過已有軟件子件來構(gòu)建新產(chǎn)品軟件的能力。

這些代碼屬性都將成為評估代碼價值的指標，很多朋友該說了，嵌入式中的代碼不就是在滿足客戶需求的前提下穩(wěn)定運行嗎？bug不要太多就好。

沒錯，但這屬于代碼最基本的價值，也是被稱為代碼本該有的價值，否則那不叫代碼，叫"隨隨便便默寫的abc"。

要想成為一名優(yōu)秀的程序員，滿足基本的代碼價值還遠遠不夠，還要有能力創(chuàng)造代碼的其他價值，讓代碼的生命力延續(xù)得更久，其中可移植性和可復(fù)用性是衡量的重要指標。

可移植與可復(fù)用

開發(fā)一套軟件，猶如生產(chǎn)一套工具，大部分情況下都不提倡一次性工具，你所開發(fā)的東西不僅能夠滿足當前需求，還需要為以后相似的開發(fā)或者應(yīng)用以及產(chǎn)品的更新?lián)Q代提供支持。

比如拿構(gòu)建的濾波算法庫，每次用到新的濾波算法都不會與實際的項目耦合，而是單獨分離出來與算法庫融合，并且開放出較全的對外接口。

這樣僅僅只是考慮了軟件的可復(fù)用能力，還要考慮該庫的跨平臺能力，比如把與平臺相關(guān)的部分抽出來進行各平臺的兼容等處理來加強各部分的可移植性。

其實很多時候有些人把軟件的可復(fù)用更多的看成是一種縱向的可移植能力。

這樣當我們進行下一個項目軟件開發(fā)的時候，前期就可以直接把該庫移植過去，后面就不需要再“重復(fù)造輪子”了。

一方面縮短了嵌入式軟件的開發(fā)周期，另一方面相應(yīng)的代碼也會更加的穩(wěn)定，從而提高了產(chǎn)品交付能力。

嵌入式更需要

在嵌入式軟件開發(fā)中，代碼的可移植和可復(fù)用能力相對而言會有更多的訴求。嵌入式就是用有限的資源來構(gòu)建特定的應(yīng)用場景，這句話里面有兩個詞"有限"和“特定”，我覺得這不僅把嵌入式描述清楚了，而且把嵌入式與其他領(lǐng)域的區(qū)別道出來了。

很多做嵌入式的朋友玩了一段時間更上層的應(yīng)用開發(fā)，就會覺得上層開發(fā)是那么的輕松，確實那很輕松，因為那些所帶來的便利都是建立在過盛的硬件資源條件下完成的，然而嵌入式與此并不協(xié)調(diào)。

有過較長時間嵌入式軟件開發(fā)的朋友，應(yīng)該有一個感受--"嵌入式太雜了"，首先還不說各種應(yīng)用的場景，單單嵌入式平臺的底層驅(qū)動就非常的繁雜，平臺種類繁多，同一平臺下不同系列外設(shè)也會存在差異等等，甚至這些繁多的軟件版本管控都是一個大學問。

剛開始學單片機的朋友，在起初都會有這樣的挫敗感，”又換MCU了呀？感覺又要重頭開始學了？有開發(fā)板嗎？有參考demo嗎？“等等。

其實真正參加工作以后，幾年下來接觸到好幾款芯片應(yīng)該不是什么新鮮事了，甚至那些芯片都非常的冷門，所以在各平臺上都游刃有余是一種重要能力的體現(xiàn)。

隨著芯片工藝和技術(shù)的提升，MCU各方面的性能和功能都有加強，底層驅(qū)動部分的開發(fā)也是越來越復(fù)雜，datasheet更是需要經(jīng)常查閱，因為很多時候廠家的例程無法滿足目前的使用需求。

然而各大廠家都有自己的一套外設(shè)驅(qū)動流程和配套開發(fā)風格，沒有得到統(tǒng)一，如果經(jīng)常使用同一家廠家的產(chǎn)品，影響相對小一點。

比如st庫就為大家做了這一塊的工作，只要是使用st系列的MCU很多驅(qū)動都是通用的，但是也免不了標準庫的停更和hal庫與llc庫的誕生，為了適應(yīng)新鮮的東西，都需要花時間去測試、評估和修改。

所以對于底層驅(qū)動開發(fā)的復(fù)雜度，目前來看并沒有很好的辦法，如果驅(qū)動部分與應(yīng)用部分再雜糅在一起，這樣的代碼就大大降低了我們今天談的這兩大屬性。

所以驅(qū)動部分、平臺相關(guān)的都要與具體應(yīng)用代碼進行分離。

構(gòu)建中間層

對于底層驅(qū)動為了達到分離的目標，我們需要構(gòu)建中間層，也有人稱之為硬件抽象層，既然在MCU上底層驅(qū)動庫很難得到較好的統(tǒng)一，通過分層的思想，把驅(qū)動和上層進行分離，通過構(gòu)建一個中間層，中間層就相當于一個萬能轉(zhuǎn)換器，提供給上層的將是一套統(tǒng)一的接口，而內(nèi)部通過API適配把底層的差異進行統(tǒng)一，以達到屏蔽掉底層的各種差異性的目的。

說起來好像挺簡單的，其實不然，這套統(tǒng)一的接口是需要定義者對多個平臺非常的熟悉，建立之前豐富的軟件設(shè)計經(jīng)驗之上，并不簡單的傳遞幾個參數(shù)，封裝成一個函數(shù)就完事了，往往如果接口統(tǒng)一不好，不僅僅達到到較好的可移植目的，甚至反而降低了處理的效率。

最后小結(jié)

在可移植性方面，對代碼進行平臺驅(qū)動的適配，以及平臺屬性方面的適配(比如數(shù)據(jù)類型的平臺差異等)，就可以滿足系統(tǒng)的運作。

面對目前缺芯的境況，代碼的可移植性的價值就體現(xiàn)出來了，可移植性好的改動也非常小。

而對于可復(fù)用能力，體現(xiàn)在新產(chǎn)品軟件的快速構(gòu)建能力了，代碼的可復(fù)用能力越高，公司培養(yǎng)的CV工程師就越多，可復(fù)用性是一個解放程序員的代碼屬性。

為什么有些人越來越強，開發(fā)速度越來越快，很大程度上是因為他們所積累的軟件子類具有較強的可移植性和可復(fù)用能力。

當你要進行一個新項目開發(fā)中，只需要把這些可復(fù)用的軟件以模塊的方式進行拼湊和協(xié)調(diào)即可實現(xiàn)一個你想要的工程，就跟我們建房子也是類似的道理。

中間件以上的軟件部分，盡量不要使用編譯器或者平臺的特有屬性，比如特定的關(guān)鍵字、函數(shù)、或者編譯器的擴展語法等。

當然盡量不要用，并不是說你不要去了解和學習，如果其對系統(tǒng)性能提升有非常大的幫助，最好是想辦法與實際的應(yīng)用代碼進行分離。

最后

好了，今天就跟大家分享這么多了，如果你覺得有所收獲，一定記得點個贊~，