軟件架構(gòu)是一個系統(tǒng)的基本組織，體現(xiàn)在它的組件，它們之間的關(guān)系和環(huán)境，以及指導它的設(shè)計和發(fā)展的原則。每個嵌入式系統(tǒng)都應該有一個軟件架構(gòu)來指導嵌入式開發(fā)人員構(gòu)建什么。但是，在成功的軟件架構(gòu)的道路上遇到幾個陷阱并不罕見。在本帖中，我們將探討五個嵌入式軟件架構(gòu)陷阱以及如何避免它們。

　　陷阱1——相信進化架構(gòu)

　　有些開發(fā)團隊存在一種想法，即在開始編碼之前沒有必要考慮你的軟件架構(gòu)。相反，人們相信系統(tǒng)軟件架構(gòu)會奇跡般地從無到有，自行發(fā)展成可伸縮、可重用、高質(zhì)量的架構(gòu)。但是，這種信念似乎源于對敏捷運動思想的曲解。所以，讓我們澄清事實。

　　軟件架構(gòu)是一張路線圖，一張藍圖，它告訴編碼人員他們的代碼如何適應更大的難題。軟件架構(gòu)確定了主要的組件、它們的輸入、輸出以及彼此之間的交互。設(shè)計良好的軟件架構(gòu)的一個特點是它可以不斷發(fā)展，以滿足客戶不斷變化的需求。最成功的團隊會花一些時間在軟件架構(gòu)的前期工作。

　　提前花一些時間找出軟件架構(gòu)的各個部分仍然適合在敏捷方法中工作的團隊。該架構(gòu)不需要以瀑布的方式開發(fā)，但可以隨著細節(jié)和經(jīng)驗的積累，通過多次迭代來設(shè)計和完善。以這種方式開發(fā)的軟件架構(gòu)通常更靈活，并且比嵌入式開發(fā)團隊希望架構(gòu)只是出現(xiàn)要成功得多。

　　陷阱2——不遵循數(shù)據(jù)

　　設(shè)計軟件架構(gòu)的一個很好的原則是遵循數(shù)據(jù)。我的第一個現(xiàn)代嵌入式軟件原則是數(shù)據(jù)決定設(shè)計。數(shù)據(jù)是每個嵌入式系統(tǒng)都要管理的真正資產(chǎn)。數(shù)據(jù)以各種形式進入系統(tǒng)，形成輸入。這些數(shù)據(jù)輸入然后被處理、存儲和/或用于從系統(tǒng)產(chǎn)生輸出。

　　當你設(shè)計嵌入式軟件時，你不應該關(guān)心使用什么溫度傳感器，系統(tǒng)中設(shè)計了什么按鈕，甚至不應該關(guān)心使用什么微控制器。相反，設(shè)計人員和開發(fā)人員應該識別并遵循他們系統(tǒng)中的數(shù)據(jù)資產(chǎn)。因此，例如，架構(gòu)應該識別溫度數(shù)據(jù)資產(chǎn)，而不是擔心溫度傳感器供應商。同樣，在軟件架構(gòu)中，我們不關(guān)心硬件，只關(guān)心有一個接口作為溫度數(shù)據(jù)。

　　如果嵌入式開發(fā)人員遵循這些數(shù)據(jù)，在這些數(shù)據(jù)上執(zhí)行期望的系統(tǒng)行為所必需的軟件架構(gòu)就會自然而然地到位。奇怪的是，它將創(chuàng)建一個獨立于硬件且更容易測試的軟件架構(gòu)。通過軟件系統(tǒng)識別和跟蹤數(shù)據(jù)來避免這個陷阱。

　　缺陷3——沒有考慮響應時間

　　嵌入式系統(tǒng)通常有與之相關(guān)的實時響應要求。例如，如果用戶按下緊急停止按鈕，系統(tǒng)將在十毫秒內(nèi)停止。

　　雖然目標是創(chuàng)建可伸縮和靈活的架構(gòu)，但是軟件架構(gòu)師還需要考慮他們的架構(gòu)決策對實現(xiàn)的影響。在架構(gòu)師階段，它可能無法完全量化響應時間。但是，可以盡快識別和測試高風險區(qū)域。

　　開發(fā)人員在創(chuàng)建基于任務的架構(gòu)時遇到困難。如果架構(gòu)師在基于任務的設(shè)計模式方面經(jīng)驗不足，那么響應延遲遠遠超過預期的情況并不少見。許多定時問題源于中斷和周期性任務之間的交互。這個問題有時可以通過將問題任務的架構(gòu)從基于時間改為事件驅(qū)動來解決。

　　缺陷4——沒有實施/架構(gòu)反饋回路

　　當一個嵌入式開發(fā)團隊把它的軟件架構(gòu)放在一起時，團隊表現(xiàn)得好像架構(gòu)是福音，不能被改變。對于編寫代碼的開發(fā)人員來說，進行架構(gòu)上的更改，而從不將這些更改反饋給架構(gòu)師，這種情況并不罕見。缺點是在實現(xiàn)和架構(gòu)之間需要一個反饋回路。

　　架構(gòu)師基于他們認為的應用程序的最佳解決方案來構(gòu)建他們的體系結(jié)構(gòu)。不幸的是，架構(gòu)師通常沒有完全構(gòu)建架構(gòu)所需的所有信息。因此，在實現(xiàn)過程中，由編碼人員向架構(gòu)師更新他們的發(fā)現(xiàn)、問題等等，以確定整個軟件架構(gòu)的最佳方向。如果編碼人員在沒有架構(gòu)師反饋的情況下自己進行更改，他們可能會將系統(tǒng)推向?qū)軜?gòu)來說不是最佳的方向。結(jié)果是代碼和架構(gòu)慢慢積累了阻礙成功的技術(shù)債務。

　　陷阱5——選擇錯誤的架構(gòu)

　　幾種不同類型的軟件架構(gòu)可以應用于嵌入式應用。例如，有非結(jié)構(gòu)化整體、分層整體、事件驅(qū)動、狀態(tài)驅(qū)動和微服務架構(gòu)。如果架構(gòu)師為他們的系統(tǒng)選擇了錯誤的體系結(jié)構(gòu)，他們可能會發(fā)現(xiàn)他們在應用程序的伸縮性方面有問題，在響應時間方面有問題，或者其他許多潛在的問題。

　　嵌入式開發(fā)人員可能為工作選擇錯誤架構(gòu)的幾個原因。首先，他們可能只是對嘗試一種他們從未使用過的新架構(gòu)感興趣。雖然擴大自己的視野可能是好的，但設(shè)計師必須小心確保他們決定使用的架構(gòu)類型能夠解決手頭的問題，并且不會引入復雜性或其他潛在的問題。例如，微服務架構(gòu)已經(jīng)變得非常流行，但是如果不小心的話，它們可能會受到復雜性和響應時間問題的困擾。

　　設(shè)計嵌入式系統(tǒng)時，請仔細查看數(shù)據(jù)和數(shù)據(jù)運行的領(lǐng)域，以幫助確定最適合應用的架構(gòu)模型。在某些應用程序中，你可能會發(fā)現(xiàn)需要混合架構(gòu)類型來解決問題。

　　結(jié)論

　　軟件架構(gòu)是指導開發(fā)者成功構(gòu)建嵌入式應用的關(guān)鍵設(shè)計元素。開發(fā)人員可以利用廣泛的軟件架構(gòu)和設(shè)計模式來解決常見的設(shè)計問題。在探索這些體系結(jié)構(gòu)和設(shè)計模式之前，嵌入式開發(fā)人員應該首先檢查了五個軟件體系結(jié)構(gòu)陷阱，它們會妨礙好的體系結(jié)構(gòu)。