作者：[美]倫·巴斯等

第2章為什么軟件架構重要

如果架構是答案，那么問題是什么？

本章主要從技術角度討論為什么架構重要。我們將研究13個重要原因。你可以利用它們來推動新架構的創(chuàng)建，或者對已有系統(tǒng)架構進行分析和優(yōu)化。

1)架構可以抑制或支持系統(tǒng)的質(zhì)量屬性。

2)在架構中做出的決策允許你根據(jù)系統(tǒng)的發(fā)展進行推理和變更管理。

3)對架構的分析能夠提前預測系統(tǒng)的質(zhì)量。

4)文檔化的架構增強了利益相關者之間的溝通。

5)架構是最早的，因此也是最基本的、最難改變的設計決策的載體。

6)架構定義了后續(xù)實現(xiàn)的一組約束。

7)架構決定了組織的結(jié)構，反之亦然。

8)架構可以為增量開發(fā)提供基礎。

9)架構是允許架構師和項目經(jīng)理推理成本和進度的關鍵制品。

10)架構可以作為一個可轉(zhuǎn)移、可重用模型來創(chuàng)建，它構成了產(chǎn)品線的核心。

11)基于架構的開發(fā)將注意力集中在組件的合并上，而不是簡單地關注組件的創(chuàng)建。12)通過限制設計的備選范圍，架構引導開發(fā)人員的創(chuàng)造力，降低設計和系統(tǒng)復雜性。13)架構可以是培訓新團隊成員的基礎。

即使你已經(jīng)相信架構是重要的并且不必再強調(diào)13次，也可以將這13點(構成本章的大綱)視為在項目中使用架構的13種有用方法，或者用于證明架構投入是合理的。

2.1抑制或支持系統(tǒng)的質(zhì)量屬性

系統(tǒng)滿足其期望的(或要求的)質(zhì)量屬性的能力實質(zhì)上是由架構決定的。如果你想不起本書里的其他內(nèi)容，那么請記住這一點。

這種關系是如此重要，以至于我們用了本書的第二部分來詳細闡述這一信息。在此之前，請記住以下例子：

• 如果你的系統(tǒng)需要高性能，那么你需要關注管理元素基于時間的行為、它們對共享資源的使用以及元素間通信的頻率和數(shù)量。

• 如果可修改性很重要，那么你需要關注將責任分配給元素，并限制這些元素的交互(耦合)，以便系統(tǒng)的大多數(shù)變更只影響到這些元素中的少數(shù)。理想情況下，每個變更將只影響單個元素。

• 如果你的系統(tǒng)必須是高度防護的，那么你需要管理和保護組件間的通信，并控制哪些組件可以訪問哪些信息。你可能還需要在架構中引入專門的元素(例如授權機制)來設置一個強大的“邊界”以防止入侵。

• 如果你想讓系統(tǒng)安全可靠，你需要設計保障措施和恢復機制。

• 如果你認為性能的可伸縮性對系統(tǒng)的成功非常重要，那么你需要將資源的使用本地化，以便引入更高容量資源來替換，并且必須避免在資源假設或資源限制中進行硬編碼。

• 如果你的項目需要交付系統(tǒng)增量子集，那么你必須管理組件間的使用。

• 如果你想讓系統(tǒng)中的元素在其他系統(tǒng)中可重用，那么你需要限制元素間的耦合，這樣當你提取一個元素時，它不會帶出太多與當前環(huán)境相關的內(nèi)容。

針對這些和其他質(zhì)量屬性的策略是非常架構化的。但是，架構本身不能保證系統(tǒng)所需的功能或質(zhì)量。糟糕的下游設計或?qū)崿F(xiàn)決策總是會破壞合理的架構設計。就像我們常說的那樣(多半是開玩笑)：架構給予什么，實現(xiàn)就拿走什么。軟件生命周期的所有階段(從架構設計到編碼、實現(xiàn)和測試)的決策都會影響系統(tǒng)質(zhì)量。因此，質(zhì)量并不完全是架構設計的一個功能，但它是起點。

2.2推理和變更管理

這是上面觀點的推論。

可修改性—可以對系統(tǒng)進行變更的便捷程度，是一個質(zhì)量屬性(在前一節(jié)討論過)，但它是如此重要的一個屬性，以至于我們在13個原因中專門提到了它。軟件開發(fā)社區(qū)開始認識到這樣一個事實：一個典型的軟件系統(tǒng)大約80%的總成本發(fā)生在初始部署之后。人們使用的大多數(shù)系統(tǒng)都處于這個階段。許多程序員和軟件設計師從來沒有從事新的開發(fā)工作—他們在現(xiàn)有架構和代碼體的約束下工作。事實上，所有軟件系統(tǒng)在其生命周期中都會發(fā)生變更，以適應新特性、新環(huán)境，修復bug等。但現(xiàn)實是，這些變更往往充滿了困難。

每個架構，無論它是什么，都將可能的變更劃分為三類：局部的、非局部的和架構的。局部變更可以通過修改單個元素來完成。例如，在定價邏輯模塊中添加新的業(yè)務規(guī)則。

非局部變更需要對多個元素進行修改，但不會影響底層架構。比如，在定價邏輯模塊添加一個新的業(yè)務規(guī)則，然后在數(shù)據(jù)庫中添加業(yè)務規(guī)則所需的字段，并根據(jù)需要修改用戶界面。架構變更會影響元素之間相互作用的基本方式，并可能需要對整個系統(tǒng)進行變更。

例如，將一個系統(tǒng)從單線程改變?yōu)槎嗑€程。顯然，局部變更是最理想的，因此有效的架構中最常見的變更是局部的，因此很容易進行。非局部變更不是那么令人滿意，但它們確實有一個優(yōu)點，那就是它們通?？梢苑制谶M行，也就是說，隨著時間的推移，以有序的方式展開。例如，你可能首先進行變更以添加新的定價規(guī)則，然后進行更改以實際部署新規(guī)則。

決定什么時候變更是至關重要的，決定哪些變更路徑具有最小的風險，評估變更的影響，決定變更的順序和優(yōu)先級，都需要對軟件元素的關系、性能和行為有著廣泛的了解。這些任務都是架構師工作的一部分。對架構進行推理和分析提供了對預期變更做出決策所必需的洞察力。如果你不采取這一步，并且不注意維護架構的概念完整性，那么你幾乎肯定會積累架構債。我們在第23章討論這個問題。

2.3預測系統(tǒng)質(zhì)量

這一點是由前兩點引出的：架構不僅賦予系統(tǒng)質(zhì)量屬性，而且以可預測的方式進行。

這似乎是顯而易見的，但事實并非如此。設計一個架構，做出一系列相當隨意的設計決策，構建系統(tǒng)，測試質(zhì)量屬性，并期待最好的結(jié)果。哎呀—速度不夠快，還不堪一擊？開始被黑客攻擊。

幸運的是，根據(jù)系統(tǒng)架構評估結(jié)果就可以對系統(tǒng)進行質(zhì)量預測。如果我們知道某些類型的架構決策會支持系統(tǒng)中的某些質(zhì)量屬性，那么我們就可以做出那些決策，并理所當然地期望得到相應的質(zhì)量屬性回報。之后，當檢查架構時，我們可以確定決策是否已經(jīng)完成，并自信地預測架構將顯示相應的品質(zhì)。

這一點和前面的一點結(jié)合起來，意味著架構在很大程度上決定了系統(tǒng)質(zhì)量，甚至更好!我們知道它是如何做到的，我們也知道如何讓它做到。

即使你有時不執(zhí)行必要的定量分析建模以確保能夠交付符合要求的架構，這種基于質(zhì)量屬性含義的評估對于及早發(fā)現(xiàn)潛在的問題也是非常寶貴的。

2.4利益相關者之間的溝通

在第1章中提到，架構是一種抽象，這是有用的，因為它代表了整個系統(tǒng)的簡化模型(與整個系統(tǒng)的無限細節(jié)相反)，你可以記住它，團隊里的其他人也可以記住它。架構是系統(tǒng)的公共抽象，大多數(shù)(如果不是全部的話)的利益相關者可以將它作為創(chuàng)建相互理解、協(xié)商、形成共識和彼此交流的基礎。架構(或至少部分架構)是非常抽象的，大多數(shù)非技術人員，特別是在架構師的指導下，都可以理解它。而且這種抽象可以被細化為足夠豐富的技術規(guī)范，以指導實現(xiàn)、集成、測試和部署。

軟件系統(tǒng)的每一個利益相關者(客戶、用戶、項目經(jīng)理、編碼人員、測試人員等)都與受架構影響的不同系統(tǒng)特征有關。例如：

• 用戶關心系統(tǒng)是否快速、可靠且在需要時可用。

• 客戶(為系統(tǒng)付費的人)關心架構可以按計劃和預算實施。

• 管理者關心架構(除了成本和進度方面之外)是否最大限度允許團隊獨立工作，以有紀律和受控的方式進行交互。

• 架構師關心實現(xiàn)所有這些目標的策略。

  架構提供了可以表達、協(xié)商和解決不同問題的通用語言，甚至對于大型復雜系統(tǒng)也是這樣的。如果沒有這樣的通用語言，就很難充分理解大型系統(tǒng)，從而導致做出影響質(zhì)量的早期決策。正如我們將在第21章中看到的，架構分析既依賴于某個層面的溝通，又增強了這個溝通。

關于架構文檔的第22章更深入地介紹了利益相關者及其關注的問題。

“當我按下這個按鈕時會發(fā)生什么”：架構作為利益相關者溝通的工具

項目審查沒完沒了地進行。政府資助的項目落后于計劃，超出了預算，而且項目大到足以引起美國國會的注意?，F(xiàn)在政府正在通過馬拉松式的一對一評審來彌補過去的疏忽。承包商最近接受了一次買斷，但情況也沒改善。那是第二天的下午，會議議程要求展示軟件架構。這位年輕的架構師(系統(tǒng)總架構師的學徒)勇敢地解釋了大規(guī)模系統(tǒng)的軟件架構如何能夠滿足實時、分布式、高可靠性的要求。他有一個扎實的陳述和一個扎實的架構。這是合情合理的。聽眾是大約30名政府代表，他們在這個棘手的項目中承擔著不同的管理和監(jiān)督角色，他們已經(jīng)厭倦了。他們中的一些人甚至在想，也許應該進入房地產(chǎn)業(yè)，而不是忍受另一場馬拉松式的“讓我們終于把事情做對了”的評審。

幻燈片以半正式的框線符號展示了系統(tǒng)運行時的主要軟件元素。年輕的架構師說，這些名字都是首字母縮寫，未經(jīng)解釋，沒有任何語義。這些線顯示了數(shù)據(jù)流、消息傳遞和流程同步。正如架構師所解釋的那樣，這些元素在內(nèi)部是冗余的?！叭绻l(fā)生故障，”他用激光筆標出其中一條線說，“就會沿著這條路徑觸發(fā)一個重啟裝置，當……”

“當按下模式選擇按鈕時會發(fā)生什么？”一位聽眾打斷了他的話。他是代表這個系統(tǒng)的用戶的政府與會者。

“您能再說一遍嗎？”架構師問。

他說：“模式選擇按鈕，當你按它的時候會發(fā)生什么？”

“嗯，這會觸發(fā)設備驅(qū)動程序中的一個事件，在這里，”架構師開始用激光筆，“然后讀取注冊表并解釋事件代碼。如果是模式選擇，它向黑板發(fā)出信號，黑板又向訂閱了該事件的對象發(fā)出信號……”

“不，我是說系統(tǒng)做了什么?！碧釂栒叽驍嗔怂?，“它會重置顯示器嗎？如果在系統(tǒng)重新配置時出現(xiàn)這種情況會發(fā)生什么？”

架構師看起來有點驚訝，甩掉了激光筆。這不是一個架構問題，但由于他是一個架構軟件架構實踐師，因此對需求很熟悉，所以他知道答案。他說：“如果命令行處于設置模式，顯示器將重置。否則，一個錯誤消息將被顯示在控制臺上，但信號將被忽略。”他把激光筆放回去，說：“我剛才說的重啟機制……”

“嗯，我只是想知道，”用戶代表說，“因為我從你的圖表上看到，顯示器正在向目標位置模塊發(fā)送信號?！薄皶l(fā)生什么？”另一位聽眾對第一個提問者問道，“你真的希望用戶在重新配置時獲得模式數(shù)據(jù)嗎？”在接下來的45min，架構師看著觀眾占用著他的時間爭論在各種深奧的狀態(tài)下系統(tǒng)的正確行為應該是什么—這是一個絕對必要且應該在需求制定的時候就應該明確的問題，但是，不知出于什么原因沒有明確。爭論的焦點不是架構，但架構(以及它的圖形化呈現(xiàn))引發(fā)了爭論。

很自然地，我們可以把架構看作交流的基礎—在架構師和開發(fā)人員之外的一些利益相關者之間進行交流，例如，管理人員使用架構來創(chuàng)建團隊并分配資源。但是用戶呢？畢竟，架構對用戶是不可見的，為什么他們要把架構作為理解系統(tǒng)的工具？

事實是他們確實如此。在這個例子中，提問者已經(jīng)坐了兩天的時間查看了所有關于功能、操作、用戶界面和測試的圖表。盡管他很累，想回家，但第一張關于架構的幻燈片讓他意識到自己有些東西不懂。參加了許多架構評審使我確信，以一種新的方式來看待系統(tǒng)會刺激人們的思維，并帶來新的問題。

對于用戶來說，架構通常是一種新的方式。用戶提出的問題本質(zhì)上是與行為有關的，在幾年前的一個令人難忘的架構評審中，用戶代表對系統(tǒng)將要做什么更感興趣，而不是它將如何做，而且很自然地是這樣。在那之前，用戶與供應商的唯一聯(lián)系是后者營銷人員。架構師是用戶可以接近的第一個合法的系統(tǒng)專家，他們會毫不猶豫地抓住這個機會。

當然，詳細和徹底的需求規(guī)范將改善這一點，但由于各種原因，需求并不總是明確或可用的。如果缺少這樣的需求規(guī)范，架構規(guī)范通常有助于引發(fā)問題并提高需求清晰度。認識到這種可能性要比抵制它更為明智。

有時，這樣的演練會暴露出不合理的需求，然后可以重新審視這些需求的效用。這種類型的評審強調(diào)需求和架構之間的協(xié)同作用，通過在整個評審會議中為年輕的架構師提供處理這類信息的機會，可以讓故事中的年輕架構師擺脫困境。而用戶代表也不會覺得像離開了水的魚，在一個明顯不合適的時間問他的問題?！狿CC

2.5早期設計決策

軟件架構是關于系統(tǒng)的早期設計決策的體現(xiàn)，這些早期約束對于系統(tǒng)后續(xù)開發(fā)、部署和維護具有巨大的影響。這也是對這些影響系統(tǒng)的重要設計決策進行詳細評審的最早時間點。

在任何規(guī)程中的任何設計都可以看作一系列決策。在作畫時，甚至在開始作畫之前，藝術家就開始決定畫布和材料—油彩、水彩還是蠟筆。一旦開始作畫，就會相應做出其他的決定：第一條線在哪里，它的寬度是多少，它的形狀是什么？所有這些早期的決策都對最終畫面的外觀有很大的影響，并且每個決策都限制了接下來的許多決策。每一個單獨的決策可能看起來都是無關緊要的，但早期的決策尤其具有不成比例的重要性，因為它們影響和限制了接下來的許多事情。

架構設計也是如此。架構設計也可以看作一系列的決策。就現(xiàn)在必須改變的額外決策而言，改變這些早期的決策將會引起連鎖反應。是的，有時架構必須重構或重新設計，但這不是一項輕松的任務，因為一片雪花就可能引發(fā)雪崩。

軟件架構體現(xiàn)了哪些早期設計決策？想想看：

系統(tǒng)是運行在一個處理器上還是分布在多個處理器上？軟件是分層的嗎？如果是，分幾層？每層做什么？組件間是同步通信還是異步通信？它們是通過控制流或數(shù)據(jù)流交互，還是兩者兼而有之？流經(jīng)系統(tǒng)的信息會被加密嗎？使用哪種操作系統(tǒng)？選擇哪種通信協(xié)議？

想象一下，如果你不得不改變其中一個或其他相關決策，而這樣的決策一開始就決定了架構的某些結(jié)構及其交互方式，那么改變決策將是一場噩夢。

2.6實現(xiàn)約束

如果你希望實現(xiàn)是符合架構的，那么它必須符合架構規(guī)定的設計決策，包括必須具有架構所規(guī)定的元素集，元素之間必須以架構所規(guī)定的方式相互交互，并且每個元素必須按照架構規(guī)定履行其職責。每一個規(guī)定都是對實現(xiàn)者的約束。

元素構建者必須熟悉元素對應的規(guī)范，他們可能不了解整體架構權衡點—架構(或架構師)只是以滿足權衡的方式約束元素構建者。性能約束分配是一個經(jīng)典的例子，架構師常常將一個大功能的性能約束分配給涉及的軟件單元。如果每個單元都滿足約束，那么整體也將滿足。而每個組成部分的實現(xiàn)者可能不知道整體性能約束，而只知道他們自己的。

相反，架構師不需要精通算法設計的所有方面或復雜的編程語言。當然，他們應該有足夠的知識，避免設計出難以實現(xiàn)的東西。架構師是負責建立、分析和執(zhí)行架構決策并進行權衡的人。

2.7對組織結(jié)構的影響

架構不僅規(guī)定了正在開發(fā)系統(tǒng)的結(jié)構，而且深刻影響開發(fā)項目的結(jié)構(有時是整個組織的結(jié)構)。在一個大型項目中，劃分工作的通常方法是將系統(tǒng)的不同部分分配給不同的組。這個所謂的工作分解結(jié)構在第1章中有所體現(xiàn)。因為架構包含了系統(tǒng)的最廣泛的分解，所以它通常被用作工作分解結(jié)構的基礎。工作分解結(jié)構反過來決定了計劃、調(diào)度和預算的單位，團隊間的溝通渠道，配置控制和文件系統(tǒng)結(jié)構，集成和測試計劃及程序，甚至項目的細節(jié)，比如項目內(nèi)部網(wǎng)如何組織，公司野餐時誰和誰坐在一起。團隊根據(jù)接口規(guī)范彼此溝通。當組建運維團隊時，也將依據(jù)軟件結(jié)構中的特定元素—數(shù)據(jù)庫、業(yè)務規(guī)則、用戶界面、設備驅(qū)動程序等進行相應分工。

建立工作分解結(jié)構的一個副作用是凍結(jié)了軟件架構的某些方面。負責其中一個子系統(tǒng)的組可能會拒絕將其職責分到其他組。如果這些職責已經(jīng)在合同中確認，改變職責可能會變得昂貴，甚至會引起訴訟。

因此，一旦架構達成一致，出于管理和業(yè)務上的原因，對其進行重大修改就變得非常昂貴。所以對于大型系統(tǒng)，在做出具體選擇之前，一定要分析其軟件架構。

2.8賦能增量開發(fā)

一旦定義了架構，它就可以作為增量開發(fā)的基礎。第一個增量可以是一個骨架系統(tǒng)，其中至少包含一些基礎設施—元素的初始化、通信、共享數(shù)據(jù)、訪問資源、報告錯誤、日志活動等，但系統(tǒng)的大部分應用功能并不存在。

構建基礎設施和構建應用功能可以同時進行。設計和構建一個小的基礎設施來支持少量端到端的功能，不斷重復，直到完成。

許多系統(tǒng)先構建成骨架系統(tǒng)，然后使用插件、包或擴展庫進行擴展。比如R語言、VisualStudioCode和大多數(shù)Web瀏覽器。每當添加擴展時，就增加了額外功能。這種方法需要確保系統(tǒng)在產(chǎn)品生命周期的早期就能執(zhí)行。隨著擴展的持續(xù)增加，早期版本不斷被更完善的版本所取代，系統(tǒng)越來越逼近最終目標。在某些情況下，這些是最終功能的低保真版本或原型；在其他情況下，它們可能是替代品(surrogate)，以適當?shù)乃俣认暮蜕蓴?shù)據(jù)，但幾乎不做其他事情。除此之外，這允許在產(chǎn)品生命周期的早期識別潛在的性能(和其他)問題。

這種做法在21世紀初通過AlistairCockburn的思想和他的“行走骨架”概念而受到關注。最近，它被那些采用MVP(最低可行產(chǎn)品)作為風險降低策略的人所采用。

增量開發(fā)的好處包括減少項目中的潛在風險。如果架構是針對一個系統(tǒng)家族的，那么基礎設施可以在整個家族中重用，從而降低每個系統(tǒng)的成本。

2.9成本和進度估算

成本和進度估算是項目經(jīng)理的一個重要工具。它們幫助項目經(jīng)理獲取必要的資源，并監(jiān)控項目的進展。架構師的職責之一是幫助項目經(jīng)理在項目生命周期的早期開展成本和進度估算。雖然自頂向下的估算對于設定目標和分配預算是有用的，但是基于自底向上對系統(tǒng)各部分的理解的成本估算通常比純粹基于自頂向下系統(tǒng)知識的估算更準確。

正如我們所說的，項目的組織和工作分解結(jié)構幾乎總是基于它的架構。對工作項目負責的每個團隊或個人對從事的工作能夠比項目經(jīng)理做出更準確的估算，在實現(xiàn)這些估算的過程中，也會有更多的自主權。但是最好的成本和進度估算通常是在自頂向下的估算(由架構師和項目經(jīng)理創(chuàng)建)和自底向上的估算(由開發(fā)人員創(chuàng)建)之間達成一致。這一過程中通過討論和協(xié)商產(chǎn)生的估算要比使用任何一種方法精確很多。

對系統(tǒng)需求進行審查和驗證是很有幫助的。你對范圍了解越多，成本和進度估算就越準確。

第24章深入探討了架構在項目管理中的作用。

2.10可轉(zhuǎn)移、可重用模型

在軟件生命周期中執(zhí)行重用越早，獲得的好處就越大。代碼重用是好事，而架構重用為具有類似需求的系統(tǒng)提供了巨大的重用機會。當架構決策可以跨多個系統(tǒng)重用時，前面描述的所有早期決策結(jié)果也會轉(zhuǎn)移到那些系統(tǒng)中。

產(chǎn)品線或產(chǎn)品家族是使用同一組共享資產(chǎn)(軟件組件、需求文檔、測試用例，等等)構建的一組系統(tǒng)。這些資產(chǎn)中最主要的是面向整個產(chǎn)品線設計的架構。產(chǎn)品線架構師選擇一個架構(或一系列緊密相關的架構)，該架構服務于產(chǎn)品線的所有成員，定義了什么是固定的，什么是可變的。

產(chǎn)品線代表了一種強大的多系統(tǒng)開發(fā)方法，在上市時間、成本、生產(chǎn)率和產(chǎn)品質(zhì)量方面能得到數(shù)量級的回報。架構的力量處于這種方法的核心。與其他資本投資類似，產(chǎn)品線的架構是開發(fā)組織的共享資產(chǎn)。

2.11架構允許合并獨立開發(fā)的元素

早期的軟件范例把編碼作為主要的活動，以代碼行來衡量進度，而基于架構的開發(fā)通常把重點放在組合或組裝可能分開開發(fā)的元素，甚至是彼此獨立開發(fā)的元素上。這種組合是可能的，因為架構定義了可以合并到系統(tǒng)中的元素。架構根據(jù)它們與環(huán)境的交互方式、它們接收和放棄控制的方式、它們消費和生成的數(shù)據(jù)、它們訪問數(shù)據(jù)的方式以及它們進行軟件架構實踐通信和資源共享所使用的協(xié)議來約束可能的替換(或添加)。我們將在第15章詳細闡述這些觀點。

現(xiàn)成的商業(yè)組件、開源軟件、公開可用的App和網(wǎng)絡服務都是獨立開發(fā)的元素。將許多獨立開發(fā)的元素集成到系統(tǒng)的復雜性和普遍性催生了整個軟件工具行業(yè)，如ApacheAnt、ApacheMaven、MSBuild和Jenkins。

對于軟件，有以下收益：

• 縮短投放市場的時間(使用別人的現(xiàn)成解決方案比自己開發(fā)更容易)。

• 提高可靠性(廣泛使用的軟件更利于消除bug)。

• 更低的成本(軟件供應商在客戶群中分攤開發(fā)成本)。

• 增加靈活性(如果你想購買的元素不是極端特別的，就可能有多個來源，從而增加議價空間)。

一個開放系統(tǒng)為軟件元素定義了一組標準—它們?nèi)绾芜\轉(zhuǎn)，它們?nèi)绾闻c其他元素交互，它們?nèi)绾喂蚕頂?shù)據(jù)，等等。開放系統(tǒng)支持甚至鼓勵許多不同的供應商能夠生產(chǎn)元素。這可以避免“綁定供應商”，即只有單個供應商能夠提供元素并因此收取額外費用。開放系統(tǒng)是通過定義元素及其交互的架構實現(xiàn)的。

2.12限制設計的備選范圍

隨著架構解決方案不斷增加，盡管軟件元素能以或多或少無限的方式組合，但如果我們主動選擇較少的元素并限制其相互關系，則可以最小化正在構建系統(tǒng)的設計復雜性。

軟件工程師不是一個創(chuàng)造性的和自由至上的藝術家。相反，工程是關乎規(guī)程的，而規(guī)程在一定程度上是限制已證實方案的替代詞匯。這些已證實方案包括戰(zhàn)術和模式，這些將在第二部分廣泛討論。重用現(xiàn)成的元素也是限制設計詞匯的另一種方法。

將你的設計詞匯限制為經(jīng)過驗證的解決方案可以產(chǎn)生以下好處：提高重用性。

更有規(guī)律、更簡單的設計更容易理解和溝通，并帶來更可靠的可預測結(jié)果。更容易分析，更有信心。更短的選擇時間。更廣泛的互操作性。

史無前例的設計是有風險的。經(jīng)過驗證的設計是可驗證的。這并不是說軟件設計永遠不能創(chuàng)新或提供新的和令人興奮的解決方案，當然可以，但這些解決方案的發(fā)明不應該只是為了新奇，當現(xiàn)有的解決辦法不足以解決眼前問題時，就應該尋求創(chuàng)新方案。

軟件的特性取決于架構戰(zhàn)術或模式的選擇。選擇對于特定問題更合適的戰(zhàn)術和模式能改進最終解決方案，可能通過使仲裁沖突的設計約束變得更容易，加深人們對設計環(huán)境的理解，幫助發(fā)現(xiàn)需求中的不一致性。我們將在第二部分討論架構戰(zhàn)術和模式。

2.13培訓的基礎

架構，包括對元素如何相互作用以實現(xiàn)所需行為的描述，可以作為新項目成員了解系統(tǒng)的第一課。這進一步證明軟件架構的一個重要用途是支持和鼓勵不同利益相關者之間的交流，并為所有這些人提供一個公共參考點。

模塊視圖是向人們展示項目結(jié)構(如誰做什么，哪個團隊被分配到系統(tǒng)的哪個部分，等等)的絕佳方法。組件和連接器視圖是解釋系統(tǒng)如何工作和完成其任務的極佳選擇。分配視圖顯示為新項目成員分配一個適合他的項目開發(fā)或部署環(huán)境。

2.14進一步閱讀

GregorHohpe所著的TheSoftwareArchitectElevator：RedefiningtheArchitect’sRoleintheDigitalEnterprise描述了架構師與組織內(nèi)外各級人員交互的獨特能力，并促進利益相關者溝通[Hohpe20]。

關于架構和組織的論文的鼻祖是文獻[Conway68]。Conway定律指出：“設計系統(tǒng)的組織……只能設計出這些組織溝通結(jié)構的復制品。”

Cockburn在《敏捷軟件開發(fā)》(AgileSoftwareDevelopment：TheCooperativeGame)中描述了“行走骨架”的概念[Cockburn06]。

開放系統(tǒng)架構標準的一個很好的例子是AUTOSAR，它是為汽車工業(yè)開發(fā)的(autosar.org)。

有關構建軟件產(chǎn)品線的詳細處理，請參見文獻[Clements16]?；谔匦缘漠a(chǎn)品線工程是一種現(xiàn)代的、以自動化為中心的構建產(chǎn)品線的方法，它將范圍從軟件擴展到系統(tǒng)工程。一個很好的總結(jié)可以在文獻[INCOSE19]中找到。

2.15問題討論

1.如果你對本書沒有任何印象，那你記住了什么？

2.針對本章闡述的架構為何重要的13個原因，采取相反的立場：提出一組環(huán)境，在這些環(huán)境下，架構對于實現(xiàn)對應結(jié)果是不必要的。證明你的立場。(嘗試為這13個原因中的每一個想出不同的情況。)

3.本章認為架構帶來了許多切實的好處。在一個特定的項目中，你如何衡量這13點中的每一點所帶來的好處？

4.假設你想向組織引入以架構為中心的實踐，你的管理層對此持開放觀點，但想知道這樣做的投資回報率。你會如何回應？

5.根據(jù)一些對你有意義的標準來排列本章中列出的13個原因。證明你的答案。或者，如果你只能選擇其中兩三個來促進架構在一個項目中的使用，你會選擇哪幾個，為什么？

推薦閱讀：

《軟件架構實踐（原書第4版）》

圖書屆奧斯卡Jolt大獎獲獎作品，全球10余個國家出版。卡內(nèi)基梅隆等名校教材，IEEE雜志10佳圖書，軟件架構圖書事實標準。

往期推薦：

• 談談ChatGPT的低成本“平替”實現(xiàn)路線

• 華為官宣進軍ERP的背后透露出哪些信息，華為會成功么

• 招商銀行數(shù)據(jù)分析平臺的前世今生
  

• NB的GPT4，王炸更新，解封了！

技術瑣話?

以分布式設計、架構、體系思想為基礎，兼論研發(fā)相關的點點滴滴，不限于代碼、質(zhì)量體系和研發(fā)管理。文章來源地址http://www.zghlxwxcb.cn/news/detail-639886.html