軟件架構可能不是你想象的那個樣子
軟件架構在敏捷社區中存在爭議。在許多人的經驗中，架構只會導致毫無價值的會議和無關緊要的文件，“地圖不是領土”的說法可以恰當地概括這一觀點。然而，架構不佳的應用程序很快就會變得像被遺棄在路邊的車輛一樣，破損且無法修復。那么，在毫無意義的兩極之間是否有一個有用的中間地帶呢？
產生這個問題的一部分原因是，對于軟件系統架構工作的成果來說，建筑設計是一個不恰當的比喻。對照建筑設計師的工作，這個詞會讓人聯想到預示著烏托邦式美好未來的設計。但是，軟件系統的架構遠比建筑架構更富于變化。建筑物是靜態的，建筑設計師的工作只做一次。軟件，就其本質而言，是不斷變化的、動態的；當它停止變化時，就開始走向死亡了。
為了更好地理解軟件架構，我們有必要追溯下建筑師（architect）這個詞的起源。它來自于古希臘詞 arkitekton，即 ρχι-（arkhi-，“chief”）+ τ κτων（téktōn，“builder”）。建筑是由建造東西的人創造的。在建筑設計師的工作中，這種意義已經消失了。他們中的許多人從未澆筑過地基，也沒有為建筑物搭過框架，更沒有安裝過水管或暖氣管。設計和建造已經被分開了。但在軟件領域卻不是這樣，構建方式會影響到構建內容，反之亦然。
1
軟件架構關乎決策，而非結構
以建筑物作類比導致一些軟件架構師過于關注結構和行為，而不是產生這些結構和行為的決策。這并不是說結構和行為不重要，而是它們是思想過程的結果。如果系統要隨著時間的推移持續演進，就必須保留這個思想過程。知道某人為什么做某事與知道他們做了什么同樣重要。如果代碼組織得很好并且有注釋的話，那么它們所做的事情應該很容易從代碼中看出來，但是為什么要這樣做卻常常被忽略。
其原因是，軟件的架構決策很少是一目了然的；幾乎每一個架構決策都是在相互競爭的備選方案之間做出妥協。而且，有一些備選方案，如果你不嘗試一下，看看它們是如何工作的，就很難看出它們的優點。知道試過什么，放棄了什么，往往比知道什么有效更有價值。有句老話說得好，好的判斷來自于經驗，而大部分的經驗來自于壞的判斷。
這也是為什么軟件架構師必須仍然是開發人員的原因之一；如果不開發和測試一些東西，他們就無法理解或預測系統中的影響因素。軟件架構師不應該作為某種酬金，付給那些已經從活躍的開發中退出，但擁有的知識被組織認為仍然有價值的人；它的意義應該不止于此。架構工作需要對系統有足夠的了解，以便能夠提出有益于質量屬性的假設，還需要有編寫代碼和設計測試以評估假設的專業知識（或與能夠評估這些假設的團隊成員緊密合作）。
2
架構是一項技能，而架構師不是一種角色
事實上，就工作性質而言，使用像軟件架構師這樣的頭銜傳達了錯誤的信息。現實情況是，很多軟件開發人員都在做架構工作，只是他們沒有意識到這一點。只要他們對如何滿足質量屬性做出決策，就會影響到系統的架構。充分了解背后的決策如何影響系統實現質量目標的能力，是改進系統架構的第一步。
那么，人們需要掌握什么樣的技能來提高其架構工作的質量呢？有以下幾個方面：
多關注質量屬性，這是好的架構應該解決的關鍵的橫切（cross-cutting）需求。功能需求很容易受到團隊關注，因為它們往往是有形的，甚至是系統幫其用戶做的一些肉眼可見的事情。但是，系統的質量屬性決定了它是否能長期存在下去，如可擴展性、性能、安全性、承載能力和可維護性，等等。
有能力將整個系統的問題概念化并加以解決。質量屬性往往是由能影響整個系統而不是僅僅影響某個部分的因素決定的。雖然模塊化設計和關注點分離對構建良好的系統至關重要，但它們也使團隊成員更難對系統有一個整體的認識。
理解系統的完整生命周期。這就要求我們不僅要有開發系統的經驗，還要有測試系統、部署系統、在生產環境中運行系統、長期維護系統的經驗，以及在系統需要重大創新時對其進行實質性的現代化改造。了解系統的生命周期以及它如何應對變化，對于做出明智的決策，限制技術債務至關重要，因為隨著時間的推移，技術債務會威脅到系統的生存。
平衡關切以及調和折中的能力。架構工作很少會有正確答案。架構經常涉及到在相互沖突的質量屬性要求（QAR）和約束條件之間做出權衡。
從經驗中學習和合成新方法的能力。這種能力是指直接進行嘗試（運行實驗），并將實驗結果概括為可以進一步指導實驗的原則。其中一些原則采取了“標準”形式。這個術語有點誤導性，因為標準需要不斷地通過實驗來檢驗，以確定它們何時不再有用。我們看到，許多開發人員對組織的“標準”感到沮喪，因為它們在過去某個時候是有意義的，但現在卻把團隊困在了過去。
展示領導力的能力。能夠提出關注點，能夠讓持有不同觀點的人展開討論并達成共識，這有助于團隊面對并克服復雜的架構問題。團隊中的任何人都可以這樣做，而任何負責架構設計的人都必須做到這一點。
3
架構意味著持續探索
現代軟件應用程序架構設計是一項基礎性的探索活動?，F如今，構建應用程序的團隊每天都會遇到新的挑戰：前所未有的技術挑戰，以及為客戶提供解決新問題和其他各種問題的新方法。這種持續性的探索意味著架構不能根據過去的經驗預先確定；團隊必須找到滿足質量要求的新方法。
關于探索對于架構發現的重要性，請考慮這樣一個例子：假設你是一個從事軟件系統開發工作的團隊的一員。根據最初的設計，該系統是為了處理存儲在 SQL 數據庫中的結構化表格數據?，F在，這個系統需要增強，以便可以處理非結構化數據，包括圖像和視頻，而且數據量預計會比系統目前處理的多得多。你考慮在技術棧中引入 NoSQL 數據庫來處理新的數據類型，但由于你的團隊在這項技術上沒有多少經驗，所以要選擇合適的數據庫產品，進行配置并滿足新的數據量要求，實驗必不可少。
在團隊解決這些技術問題的過程中，關于哪些方法能最好地滿足所期望的 QAR，他們形成了自己的假設，這些假設會隨著時間變化。他們構建一部分解決方案來檢驗這些假設，并根據結果做出決策。這些關于如何滿足 QAR 的決策疊加起來就是系統的架構。團隊可能會以不同的方式溝通這些決策，包括使用文檔和圖表。但是，文檔和圖表不是架構，重要的是決策以及做出決策的原因。
關于這些決策，以下信息很重要：
如果有必要的話，說明推翻一項決策的成本。如果你必須更換一個服務、一個 DBMS、甚至一個框架，那么要知道更換的代價有多大。在某些情況下，這可能意味著重寫應用程序。
清楚地闡明所有限制或假設。了解使用約束和假設可能會幫助到將來要對你的工作進行更新的團隊。例如，知道你做了并發用戶個數不超過 X 的假設，并導致你對并發線程或進程做出某些決定，這有助于你未來的同事了解，如果超過這個約束，他們可能需要做出什么改變。
你是如何滿足具體的質量屬性要求（QAR）的。對于每個 QAR，你應該描述你做了什么來確保它可以得到滿足，不僅僅是在理論上，還要說明你運行了什么測試來證明。鏈接到具體的測試用例及其相關的自動測試。這樣，當 QAR 發生變化時，就能夠很容易地重新評估系統的架構質量。
在做出決策之前，你考慮過哪些選項。知道你考慮了什么以及放棄了什么，往往比知道你最終的決策更有用；它展示了你的思考過程，其他人可以從中看出你做決定時可能受到了什么樣的限制。如果這些限制將來消失了，那么知道你為什么做出某些決策將有助于未來的開發者做出更好的決策。
圖 1：QAR、決策和技術債務的關系
在知情的情況下產生了哪些技術債務。有些決策將不可避免地導致技術債務；例如，使用 SQL 數據庫來滿足可靠性目標的決策會對技術債務有一些副作用（見圖 1）。現在，早已成為過去式的“千年蟲問題”就源于開發人員當時有意識的決策。為了減少了數據存儲、內存使用和處理時間，他們在存儲標準日期時沒有存儲世紀數據。產生這個問題的原因是，他們沒有想到應用程序會存在這么久，在那些限制不合時宜之后還存在很長時間。如果他們能更準確地傳達他們的決策并描述潛在的影響，可能人們就不會在上個世紀末出現如此強烈的反應。
轉載請在文章開頭和結尾顯眼處標注：作者、出處和鏈接。不按規范轉載侵權必究。
未經授權嚴禁轉載，授權事宜請聯系作者本人，侵權必究。
本文禁止轉載，侵權必究。
授權事宜請至數英微信公眾號(ID: digitaling) 后臺授權，侵權必究。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）