軟體架構原理–題解

引言

本文試著解答《軟體架構原理》的習題(尚未完整)。

習題

第一章 介紹

1. 定義軟體架構的四個維度為何？
A. 結構、架構特性、架構決策、設計原理。
2. 架構決策與設計原理的差異是什麼？
A. 在於設計原理是個指導方針，而非不可改變的規則。
3. 列出對於軟體架構師的八個核心期望。
A. 做出有關架構的決策、持續分析架構、跟上最新的趨勢、確保遵守決策、實踐及工作經驗的多樣性、擁有業務領域的知識、處理人際關係的技能、能了解並駕馭辦公室政治。
4. 什麼是軟體架構的第一法則？
A. 軟體架構的一切皆是取捨。

第二章 架構思維

1. 描述架構的傳統做法與開發的異同，並解釋為何此法不再奏效。
A. 傳統的架構師與開發團隊是分開的；現今的架構師與開發團隊則緊密合作。
2. 列出知識三角形裡三種層次的知識，並對每一種提供例子。
A. 一，你清楚的事情，例如Java程式設計師要懂得Java語言；二，你知道的那些你不清楚的事情，例如大部份程式設計師聽過、但無法拿來寫程式的Clojure程式語言；三，你不知道的那些你並不清楚的事情，例如連這些東西的存在都不知道。
3. 為什麼對架構師來說，專注在技術廣度比技術深度來得重要？
A. 因為架構師的決策得讓功能與技術限制配合，廣泛了解各種解決方案是很有價值的。
4. 架構師維持技術深度、及保有實踐經驗可以使用哪些方法？
A. 可以跟團隊共同開發的架構師，第一個訣竅是避開瓶頸陷阱；無法跟團隊共同開發的架構師，第一種方法是常做概念驗證，第二種方法是處理技術負債或架構的故事，第三種方法是創建簡單的命令行工具與分析工具以便於自動作，第四種方法是常常進行程式碼審查。

第三章 模組化

1. 共生性這個詞的意義為何？
A. 系統的兩個元件，如果其中一個的變數使得另一個也須有所變動，才能維持整個系統的正確性，則這兩個元件即為共生。
2. 靜態與動態共生性的差別何在？
A. 靜態共生性指的是原始碼層級的耦合，包含名字共生性、型別(型態)共生性、含義共生性或慣例共生性、位置共生性、演算法共生性；其他共生類型則為動態共生性，它們會在執行期對呼叫進行分析，包含執行共生性、時序共生性、數值共生性、同一共生性。
3. 型態共生性的意思是什麼？是靜態或動態共生性？
A. 皆有。許多靜態型別的語言中，常見的用來限制變數/參數只能是特定型別的功能，但是此功能不只是一項語言特色–有些動態型別語言也提供了選擇性型別。
4. 最強形式的共生性是什麼？
A. 名字共生性。
5. 最弱形式的共生性是什麼？
A. 同一共生性。
6. 代碼庫更偏好哪一種–靜態或動態共生性？
A. 架構師應該更偏好靜態而非動態共生性。

第四章 定義架構特性

1. 一個屬性必須滿足哪三個準則，才能被視為一個架構特性？
A. 指定與領域無關的設計考量、影響設計的某些結構面向、對應用程式的成功至為關鍵或重要。
2. 隱性或外顯特性的差別為何？每一種給個例子。
A. 隱性(隱含)的架構特性很少出現在需求上，但對專案的成功卻不可或缺，例如可用性、可靠度、安全性。顯性的架構特性則會出現在需求文件、或其他特殊的指令當中。
3. 給一個運維特性的例子。
A. 可用性；系統可持續使用的時間有多長(如果是24/7，必須有適當的步驟，讓系統在任何失效發生時保持系統的持續運作)。
4. 給一個結構特性的例子。
A. 可配置性；終端使用者輕易更改軟體配置的能力(透過可用的介面)。
5. 給一個跨領域特性的例子。
A. 易用性/可行性；使用者需要接受什麼層次的訓練，才能利用應用/解決方案完成目標。易用性得跟其他架構問題一樣地被嚴肅對待。
6. 哪種架構特性更重要–可用性或效能？
A. 這是個取捨問題，也就是決策師結為在許多競爭考量之間做取捨。別總是想瞄準最佳架構，而應該找尋別無選擇下的架構。

第五章 確認架構特性

1. 給個理由，說明為何限制架構應支援的特性數目(「各項能力」)是個好做法。
A. 舉個反例。一個常見的架構反模式，是嘗試去設計一個支援所有架構特性的通用架構。每一個支援的架構特性都會讓整個系統的設計複雜–在架構師與開發人員甚至都還沒開始處理問題領域(即打造軟體的原始動機)之前，支援太多架構特性會讓複雜度越來越大。
2. 此敘述為真或假：大部分架構來自於業務需求及使用者故事。
A. 假；大部分架構特性來自於傾聽主要的領域利益相關方、並與其合作，以決定從領域觀點來看哪些才是重要的；業務需求及使用者故事屬於領域利益相關方的使用者。
3. 如果有位業務利益相關方述說上市時間(盡快發行新功能或修正錯誤後的版本)是最重要的業務考量，那麼架構該支援哪個架構特性？
A. 敏捷性、可測試性、可部署性。
4. 可擴展性與彈性的差異何在？
A. 可擴展性–能同時處理大量使用者卻不致於嚴重減低效能的能力；彈性–處理突發請求的能力。
5. 你發現公司將要進行好幾場主要的併購，來大幅增加客戶群。你該擔心哪些架構特性？
A. 互通性、可擴展性、適應性、延伸性。

第六章 測量及管理架構特性

1. 在架構分析上，為什麼循環複雜性的是這麼重要的指標？
A. 循環複雜度CC是程式碼層級的指標，被設計來提供程式碼複雜度的客觀測量–在函數/方法、類別、或應用的層級上。架構師與開發人員普遍同意太複雜的程式碼顯示可能會有問題，因為會傷害代碼庫所有可取的特性：模組化、可測試性、可部署性等等。
2. 架構適應度函數是什麼？怎麼用它來分析架構？
A. 為某個架構特性、或架構特性的組合提供客觀的完整性評估的任何機制。適應度函數與許多現有的驗證機制重疊–依其使用方式而定。有許多不同工具可用來實作適應度函數。
3. 給個測量架構可擴展性之適應度函數的範例。
A. 略。
4. 為讓架構師與開發人員得以創造適應度函數，架構特性應滿足的最重要的準則為何？
A. 架構師在強加適應度函數到開發人員身上之前，必須確認他們知道目的何在。

第七章 架構特性之範圍

1. 架構量子為何，為什麼對架構很重要？
A. 架構量子，係指具備高功能性內聚及同步共生性，能被獨立部署的工件。
2. 假設一個系統由單一使用者介面、及四個獨立部署的服務構成，每個服務有自己分開的資料庫。這個系統有一個或四個量子？為什麼？
A. 略。
3. 假設一個系統有個管理靜態參考資料(例如產品型錄、倉庫資訊)的管理部分，以及管理下單的面向客戶部分。這個系統的量子數是多少，為什麼？如果你預見有多個量子，那麼管理量子與面向客戶的量子會共享資料庫嗎？如果是，那麼資料庫該放在哪個量子？
A. 略。

第八章 以元件為基礎的思維

1. 我們把元件定義為應用的組件–應用該做的某些事。元件通常由一組類別或原始檔組成。通常元件在應用或服務中的如何體現的？
A. 相關程式碼打包、分層或子系統、事件處理器、或分散式服務。
2. 技術分割與領或領域分割的區別為何？每一種都給個例子。
A. 技術分割就是依依照技術能力來對架構進行組織，例如像分層式架構；領域分割辨識出彼此獨立、互不影響的領域或工作流程，例如微服務架構。
3. 領域分割的好處是什麼？
A. 建模方式更接近商業運作，而綜實作細節。比較容易利用向Conway操縱，圍繞著領域來打造跨功能團隊。跟模組化單體及微服務架構風格更為一致。訊息流與問題領域匹配。容易將資料與元件遷移至分散式架構。
4. 什麼情況下技術分割會好過領域分割？
A. 清楚地將客裝化程式碼區分開來。跟分層架構模式更為一致。
5. 實體陷阱是什麼？為什麼它在元件確認上不是個好做法？
A. 在需求中確認的每個實體所打造的元件，不簡是架構，而是一個從框架到資料庫的元件關聯對映。
6. 確認核心元件時，什麼情況你會選擇工作流程、而非行動者/動作的做法？
A. 工作流程方法乃是確認關鍵角色，接著判斷角色參與的工作流程種類，而圍繞這些確認的活動來打造元件。瀑布流軟體開發程序可能會偏好行動者/動作方法，領域驅動設計則會偏好事件風暴、或工程流程方法。

第九章 基礎

1. 列出分散式計算的八種謬誤。
A. 網路是可靠的、不會有延遲、頻寬是無限的、網路是安全的、網路拓撲絕不會改變、只有一位管理員、傳輸成本為零、網路為均質性的。
2. 列舉分散式架構會遇到、但單體架構不會遇到的三種挑戰。
A. 分散式登錄、分散式交易、合約維護與版本控制。
3. 標記耦合是什麼？
A. 針對往來服務之間的通信大量占用到頻寬、而僅有部分的通信內容是必要的(大部分內容是不必要的)。
4. 處理標記耦合有哪些方法？
A. 打造私有的RESTful API端點、在合約中使用欄位選擇器、使用GraphQL讓合約彼此獨立、使用數值驅動合約時也利用消費者驅動合約、使用內部傳訊端點。

第十章 分層式架構風格

1. 開放與封閉分層的區別為何？
A. 封閉層的意思是請求自上而下地從一層到另一層，它不能跳過任一層，而必須先通過正底下的那一層，才能到另一層。開放層的意思則是請求可以跳過其他層。
2. 描述隔離層的概念及其好處。
A. 隔離層概念的意思是：架構某一層的改變，通常不會影響其他層的元件–如果層與層之間的合約沒有改變的話。好處是可以在不影響其他層的情形下被置換。
3. 架構汙水池反模式為何？
A. 架構汙水池是請求只是單純地從一層移動到另一層、而且直接穿過並未執行任何業務邏輯。
4. 驅動你使用分層架構的主要架構特性有哪些？
A. 整體花費與簡單性。
5. 為什麼可測試性在分層架構的支援不佳？
A. 因為面對簡單的變動，大部分開發人員不會花很長的時間來執行整組的迴歸測試。任何特定的業務領域會分散到架構的每一層。
6. 為什麼敏捷性在分層架構的支援不佳？
A. 略。

第十一章 管道架構風格

1. 管道架構的管道有可能是雙向嗎？
A. 此架構裡的管道形篩選器之間的通信通道。出於效能考慮，通常通道是單向且點對點(而非廣播)，從一個來源輸入、並輸出到另一個地方。
2. 列舉四種篩選器及其目的。
A. 生產器：一道程序的起點，而且只向外。轉換者：接收輸入，接著選擇性地對某些或全部資料做轉換，然後傳送至向外的管道。測試者：接收輸入，測試一個或多個準則，然後依測試結果選擇性地產生輸出。消費者：管道流程的終點。
3. 篩選器可以透過多個管道送出資料嗎？
A. 通常是點對點(而非廣播)。
4. 管道架構是技術或領域分割？
A. 因為應用邏輯被分割成各種篩選器，所以管道架構屬於技術分割架構。
5. 管道架構以何方式支援模組化？
A. 架構的模組化，是透過將各種考量分散到不同型態的篩選器、與轉換者來達成的。
6. 給出管道架構的兩個例子。
A. 略。

第十二章 微核心架構風格

1. 微核心架構的另一個名字為何？
A. 略。
2. 在什麼情況下，外掛元件依賴其他外掛元件是可接受的？
A. 略。
3. 可用來管理外掛的工具及框架有哪些？
A. OSGi、Prism。
4. 如果有個第三方外掛並不遵從核心系統的標準外掛合約，你會如何處理？
A. 略。
5. 給兩個微核心架構的例子。
A. 略。
6. 微核心架構是技術或領域分割？
A. 同時被領域與技術分割。
7. 為什麼微核心架構總只有一個架構量子？
A. 因為所有請求必須通過核心系統，才能到達獨立的外掛元件。
8. 什麼是領域/架構同構？
A. 略。

第十三章 服務式架構風格

1. 一個典型的服務式架構會有多少個服務？
A. 4到12。
2. 在服務式架構中必須把資料庫拆分嗎？
A. 服務式架構中的服務經常共享單一個資料庫。
3. 什麼情況下你會把資料庫拆分？
A. 必須確定另一個領域服務不需要與之分開的資料庫。這樣就可以避免領域服務之間的跨服務通信。
4. 有什麼技巧可以在服務式架構中管理資料庫變更？
A. 從邏輯上分割資料庫，並透過聯合共享程式庫實現邏輯分割。
5. 領域服務需要跑在容器(例如Docker)上嗎？
A. 略。
6. 哪些架構特性在服務式架構中得到良好的支援？
A. 可佈署性、容錯、模組化、整體花費、可靠性、可測試性。
7. 為何彈性在服務式架構的支援不佳？
A. 粗顆粒。
8. 如何在服務式架構中增加量子的數目？
A. 參照「拓撲結構的變形」所示，使用者介面與資料庫皆可採聯合形式，使整個系統有多個量子。

第十四章 事件驅動架構風格

1. 代理者與調停者拓撲的主要差異何在？
A. 代理者拓撲沒有中心化的事件調停者，調停者拓撲有個事件調停者。
2. 為實現更好的工作流程控制，你會使用調停者或代理者拓撲？
A. 在需要控制事件程序的工作流程中，常使用調停者拓撲。
3. 代理者拓撲通常採用主題的發佈/訂閱模式，或是佇列的點對點模式？
A. 事件代理者常以聯合形式呈現，而且每個聯合代理者都包含特定領域事件流程的所有事件通道。因為代理者拓撲具備獨立、非同步，射後不理的廣播特性，所以通常會使用主題的發佈/訂閱傳訊模式。
4. 列出非同步通信的主要好處。
A. 增加系統整體反應性。
5. 給出一個在請求式模型中，典型的請求範例。
A. 提取訂單歷史資訊。
6. 給出一個在事件式模型中，典型的請求範例。
A. 線上拍賣上針對特定物品出價。
7. 在事件驅動架構上，初始事件與處理事件的區別是什麼？
A. 初始事件是啟動整個事件流程的最初事件，接著創造的稱為處理事件。
8. 從佇列傳送及接收訊息時，要避免資料遺失有些什麼技巧？
A. 持久性訊息佇列以及同步傳送，客戶確認模式，ACID資料庫認可以及最後參與者支持(LPS)。
9. 有哪三個主要的架構特性會驅使採用事件驅動架構？
A. 效能、可擴展性、容錯。
10. 事件驅動架構對哪些架構特性支援不佳？
A. 簡單性、可測試性。

第十五章 空間式架構風格

1. 空間式架構的名字來源為何？
A. 空間式架構之名稱來自於元組空間(tuple space)的概念，這是透過共享記憶體溝通，來使用多個平行處理器的技巧。
2. 空間式架構與其他架構風格有所差異的主要面向為何？
A. 移除成為系統同步限制的中央資料庫，並以複製在記憶體內的資料網格來代替。
3. 列出空間式架構中，構成虛擬中介軟體的四種元件。
A. 傳訊網格、資料網格、處理網格、部署管理員。
4. 傳訊網格扮演什麼角色？
A. 負責管理輸入請求以及工作資段的狀態。
5. 空間式架構中，資料寫入器的角色為何？
A. 資料寫入器從資料幫浦接收訊息，然後利用裡面所含的資訊更新資料庫。
6. 在何種情況下，服務得透過資料讀取器取得資料？
A. 空間式架構的資料讀取器，只在三種情況之一啟動：有著同名快取的所有處理單元實例一起當掉、重新部署所有擁有同名快取的處理單元、提取不在複製快取內的封存資料。
7. 小尺寸的快取會增加或減少資料衝突的機會嗎？
A. 快取大小是唯一一個跟衝突率成反比的因子。快取變小，衝突率上升。
8. 複製快取與分散式快取有何區別？通常在空間式架構會使用哪一個？
A. 複製快取，每個處理單元有自己的記憶體內的資料網格，並透過同名快取在所有處理 單元間取得同步。分散式快取需要專屬的外部伺服器或服務，來掌控中心化的快取。在空間式架構選擇快取模型的時候，請記得在大部分情況中，兩者在任何給定應用背景下皆可適用，也就是說，沒有哪一個模型可以解決所有的問題。
9. 列出空間式架構支援最好的三種架構特性。
A. 彈性、效能、可擴展性。
10. 為什麼空間式架構在可測試性上的評分這麼低？
A. 因為要模擬此架構所支援的高度可擴展性及彈性，其複雜度很高。

第十六章 協作驅動的服務導向架構

1. 服務導向架構背後的主要驅動力為何？
A. 驅動架構師採取此架構的哲學，乃是集中在企業層級的復用。
2. 服務導向架構四種主要的服務型態為何？
A. 業務服務、企業服務、應用服務、基礎設施服務。
3. 列出服務導向架構沒落的一些因素。
A. 大量的耦合，額外的複雜度、專注在技術分割的架構根本不切實際。
4. 服務導向架構是技術或領域分割？
A. 技術分割。
5. SOA如何處理領域復用的問題？如何處理運維復用？
A. 略。

第十七章 微服務架構

1. 有界背景的概念為何在微服務架構中如此重要？
A. 驅動微服務的哲學是有界背景的概念：每個服務就是一個領域或工作流程的模型。因此，每個服務包含運作所需的每樣東西，包括類別、其他子元件、資料庫綱要。在此架構中，這種折學驅動著許多架構師的決策。例如，在單體架構上，開發人員常常在截然不同的部分之間，分享共同的類別–例如Address。但是微服務則嘗試避免耦合，所以打造架構的架構師偏好複製，而非耦合。
2. 判定微服務之顆粒度是否適當有哪三種方法？
A. 目的、交易、編排。
3. 什麼功能可能放在邊車上？
A. 運維上的課題。
4. 協作與編排有何差異？微服務支援哪一種？有哪一種通信方式在微服務中更容易嗎？
A. 編排沒有中心化的協調者，協作則有。微服務都支援。軟體架構的第一法則暗示這些解決方案沒有一個是完美的，因為每個都有取捨。
5. 微服務中的傳奇是什麼？
A. 有個處理多重服務呼叫、並協調交易的服務充當調停者。
6. 為什麼微服務對敏捷性、可測試性、可部署性的支援很好？
A. 略。
7. 微服務的效能常成為問題的兩個原因是什麼？
A. 分取式架構必須透過許多網路呼叫，因此額外成本很高；而且還得在每個端點進行安全檢查，驗證身分以及存取權限。
8. 微服務是領域分割或技術分割架構？
A. 領域分割。
9. 描述一種拓撲，其中的微服務生態系可能只有單一量子。
A. 略。
10. 微服務如何處理領域復用？運維復用呢？
A. 略。

第十八章 選擇適當的架構風格

1. 資料架構(邏輯及實體資料模型的結構)如何影響採用哪種架構風格？
A. 架構師與DBA(資料庫管理員)在資料庫、綱要、及其他資料相關考量上必須合作。
2. 它如何影響你選用的架構風格？
A. 領域，影響結構的架構特性，資料結構，組織因素，關於程序、團隊、運維考量的知識，領域/架構同構。
3. 描述架構師決定採用哪種架構、資料分割、以及通信方式的步驟。
A. 略。
4. 什麼因素讓架構師採用分散式架構？
A. 利用早先討論的量子概念，架構師得決定是否一組架構特性就夠了，或者系統的不同部分需要不同的架構特性？如果是一組的話暗示單體比較適合(雖然其他因素可能讓架構師選擇分散式架構)，如果是要求不同的架構特性，則暗示應該改用分散式架構。

第十九章 架構決策

1. 什麼是掩蓋資產反模式？
A. 當架構師因為害怕做錯決定而逃避或延遲做出架構決定時。
2. 有哪些技巧可以避開電子郵件驅動架構反模式？
A. 不要把架構決策放在信件主體，只通知在乎決的相關人等。
3. 由Michael Nygard所定義、用來確認某事物在架構上是否重要的五個因素是什麼？
A. 結構、非功能性的特性、相依性、介面、建造技巧。
4. 一個ADR(架構決策紀錄)的五個基本段落是什麼？
A. 標題、狀態、背景、決策、後果。
5. 通常把架構決策的理由放在ADR(架構決策紀錄)的哪個段落？
A. 決策。
6. 假如不需要一個分開的替代方案段落，那麼你會把提議方案的替代方案列示在哪個段落？
A. 背景。
7. 根據哪三個基本準則會讓人把ADR(架構決策紀錄)的狀態標記為已提議？
A. 費用、跟團隊的影響、以及安全性。

第二十章 分析架構風險

1. 風險評估矩陣的兩個維度是什麼？
A. 風險發生的可能性、風險的全面影響。
2. 在風險評估中，有哪些方法可以顯示特定風險的方向？你能想到其他方法，來指示風險變得更好或更差嗎？
A. 正(+)負(-)號、箭頭、顏色。
3. 為什麼風險激盪要共同進行？
A. 單獨一個架構師可能遺漏或忽略某區域的風險，而少有架構師對系統的每個部分完全了解。
4. 為什麼風險激盪中的確認活動，是屬於個人活動而非共同進行？
A. 確認一直是種個人化、非共同進行的活動，而共識及減緩則總是牽涉到所有參與者、而且在同一個房間(至少虛擬上)一起進行的。
5. 如果有三個參與者認定架構特定區域的風險為高(6)，但另一個參與者認定只是中度而已(3)，此時你會怎麼做？
A. 取得共識。
6. 對於未被證明或未知的技術，你會設定風險等級(1-9)為多少？
A. 對未經證實或不了解的技術，總是將其界定為最高風險(9)。這是因為風險矩陣無法處理這個維度。

第二十一章 架構的圖解與簡報

1. 什麼是不理性的工件依戀，為什麼它對架構的記錄與圖解很重要？
A. 一個人對某些工件的不理性依戀，跟其花了多少時間去製造它有成比例的關係。敏捷軟體開發的低儀式做法的一個好處，乃圍繞著以盡量少的儀式，即時地創建需要的工件，利用低科技的工具讓團隊成員捨棄不對的事物，讓他們自由去實驗，並且讓工件的真實性透過改版、合作、討論而出現。
2. 在C4建模技巧中，4個C指的是什麼？
A. 背景、容器、元件、類別。
3. 圖解架構時，元件之間的點狀線表示什麼？
A. 點狀線表示非同步通信、實體線指示同步通信。
4. 什麼是佈滿子彈的屍體反模式？打造簡報時如何避免此種反模式？
A. 每張投影片在本質上就是簡報者的筆記。比較好的解法是利用增量法建構投影片，在需要時增加(最好是圖像)資訊、而不是全部一次打造完畢。
5. 簡報者在簡報時有哪兩個主要的資訊通道？
A. 言語及視覺。

第二十二章 打造有效的團隊

1. 架構師人格有哪三種？每種人格各創造什麼樣的邊界？
A. 控制狂架構師，界限太緊、產生挫折感；只會空談的架構師，界限太鬆、產生混亂；有效的架構師，適當的界限、創造出有效的團隊。
2. 決定該對團隊施行什麼層次的控制時，有哪五個因素要考慮？
A. 團隊熟悉度、團隊大小、整體經驗、專案複雜度、專案長短。
3. 可以觀察哪三種徵兆，來判斷團隊是否已經變得太過龐大？
A. 過程損失、多數無知、責任分散。
4. 列出對開發團隊有好處的三個基本檢查表。
A. 開發人員的程式碼完成度檢查表、單元及功能測試檢查表、軟體發行檢查表。

第二十三章 交涉與領導技巧

1. 為什麼交涉對架構師如此重要？
A. 克服意見上的不同以創造所有利益相關方同意的解決方案。
2. 當業務利益相關方堅持要5個9的可用性，但實際只需要3個9時–列出一些可用的交涉技巧。
A. 利用語法與流行詞的搭配，來對情況有更清楚的了解；開始交涉前盡可能蒐集最多的資訊；如果其他手段都失效，就從費用與時程的角度來談事情；利用「分而治之」的規則，來確認要求或需求是否合理。
3. 如果業務利益相關方告訴你「我昨天就需要了」，你可以推論出什麼？
A. 上市時間對此利益相關方很重要。
4. 為什麼在交涉中，把有關時程與費用的討論放在最後很重要？
A. 這樣可以先嘗試其他更重要的原因與理由。
5. 什麼是「分而治之」法則？如何應用在與業務利益相關方交涉架構特性的時候？給個例子。
A. 略。
6. 列出架構的4個C。
A. 溝通、合作、清晰、簡明。
7. 解釋為何既務實、卻又有遠見對架構師很重要？
A. 業務利益相關方會欣賞滿足限制並具有遠見的解決方案，而開發人員則會感激能夠去打造一個實體(而非理論)的解決方案。
8. 要管理並減少受邀會議的數目，有哪些技巧？
A. 要求先看會議議程，有助於判斷是否需要在會議出現。

第二十四章 發展一條職涯路徑

1. 什麼是20分鐘法則？什麼時候用最好？
A. 每天投注至少20分鐘在架構師的職涯上–藉由學習新的事物，或深入探討特定主題。
2. ThoughtWorks技術雷達的四個環帶是什麼，其意義為何？如何套用到你自己的雷達上？
A. 暫停，不要在新案子嘗試這項技術；評估，在把目標設定為了解技術對組織的影響下，該技術值得進行探索；試驗，值得追求的技術；採納，強烈認為業界應當採用。
3. 描述對軟體架構師而言，知識深度與廣度的區別。架構師應當追求哪一個的最大化？
A. 架構師金字塔的頭段即為架構師的技術深度，架構師金字塔的中段能穿透底層多深則代表了架構師的技術廣度。相較於深度，技術廣度對架構師更重要。

參考文獻

http://books.gotop.com.tw/o_A620