讀《程序員向架構師轉型必備》

讀《程序員向架構師轉型必備》

 機會、人才、技術和產品是公司成長的主要牽動力。機會牽引人才，人才牽引技術，技術牽引產品，產品牽引更大機會。人才鎖找我的知識處於最核心的部位。 – 《華爲研發》 

讀完本書，頗有點相逢恰當時之感。內容翔實，而指導性又非常強，很多內容點自己在實際工作中深有感觸。其紙質書亦作爲自己又一本收藏案頭書，進行查閱回顧溫習。可惜的是沒有正版電子版，只能下本不太清晰的盜版電子書放在手機隨時查閱了。

---

• 以能力層次來看，程序員成金字塔型，中高端人才缺失；以學歷層次來看，程序員成橄欖型，本科學歷最多。

• 軟件企業發展的好壞取決於如下因素：

• 員工素質
• 人才結構
• 員工職業技能的縱深積累
• 員工職業技能的適時更新

• 純粹靠從外部招人的人才策略不現實。

• 架構設計主要思想：

分而治之

• 聚焦不同方面，更有效思考。
• 化大問題爲子問題。

迭代式設計

• 不同視圖設計交替迭代展開。
• 邏輯劃分逐步清晰，促進物理分佈設計；反之亦然。

• 架構設計主要視圖：

• 邏輯視圖
• 物理視圖

邏輯視圖		物理視圖
淺層設計	>>	淺層設計
<<		<<
深層設計	>>	深層設計

• 小系統和大系統的架構設計之不同，首先是概念架構上的不同，而歸根溯源這是由於架構鎖支撐的“關鍵需求”不同造成的。整個架構設計過程中的“確定關鍵需求”這一環節，可謂小系統和大系統架構設計的“分水嶺”。

• 概念架構指系統目標的設計思想、重大選擇。《方案建議書》《技術白皮書》和市場彩頁中，都有它的身影，以說明產品/項目/方案的技術優勢。因此，也成爲“市場（業務）架構”。

• 概念架構設計內容：

一個決定：

劃分頂級子系統

四個選型：

• 架構風格選型
• 開發技術選型
• 集成技術選型
• 二次開發技術選型

• 如何做概念架構設計：

• 首先，選擇架構風格、劃分頂級子系統。兩者相互影響、相輔相成。
• 然後開發技術選型、集成技術選型、二次開發技術選型。三者緊密相關、同時進行。集成技術和二次開發業可能不需要。

• 破解領域知識不足的有效方法：把領域模型作爲“理解領域的手段”。領域模型的強項是“理順概念關係、搞清業務規則”，通過對複雜領域進行“概念抽象”和“關係抽象”建立模型、獲得對領域知識總體上的把握。

• 軟件架構的定義：

組成派

軟件架構將系統描述計算組件及組件間的交互。關注軟件本身。

決策派

軟件架構是在一些重要方面所作出的決策的集合。關注實踐主體–人。

這些重要決策如下：

• 模塊如何劃分。
• 每個模塊的職責如何。
• 每個模塊的接口定義。
• 模塊間的交互機制。
• 開發技術選型。
• …

• 軟件架構師分與合的藝術。

• 架構設計是一棵決策樹：

• 軟件是由遞歸的組件的遞歸組成的。系統、子系統和框架均需要架構設計。

• 架構就是對複雜單元進行分解，並規定各部分之間的交互。

• 架構設計的幾個誤解：

• 架構設計是技術選型
• 架構設計是通用模塊
• 投標PPT中的架構就是架構的全部

• 在使用第三方庫時候，如果希望將來可以替換該SDK，那麼可以採用適配器模式：定義一套業務接口，實現接口（調用第三方庫）。

• 架構設計是一門解決複雜性的藝術。

• 架構的不同受衆者需要的“架構的樣子”是不一樣的。因此，架構師需要以不同的視圖架構。

技術經理：軟件架構就是模塊的劃分和接口定義。 系統分析師：軟件架構就是業務領域模型的關係建模。 數據庫工程師：軟件架構就是規定了數據結構，其他只不過是對數據的操作而已。 部署工程師：軟件架構就是規定了軟件部署到硬件的策略。 …

• 爲用戶設計，不僅滿足用戶需求的功能，也要達到用戶期望的質量。

• 客戶 ≠ 最終用戶

• 先研究需求，再設計架構，然後交由開發人員實現。作爲架構，不僅要爲用戶服務，還要爲“下游”的開發人員設計。需求不僅包含用戶的需求，也包含開發人員的需求。比如易測試性功能需求。

• 軟件複雜體現在兩個方面：1. 軟件本身的複雜性；2. 團隊管理複雜性。

• 開發人員之間的依賴源於他們負責的程序之間的依賴性。要清楚管理人員的協作，就必須清晰劃分模塊（子系統）。架構是開發和管理的核心。

• 架構師應當爲項目相關的不同角色而設計。手段就是多視圖：

• 架構師要爲“上游”客戶負責，爲他們的業務目標和約束條件負責。
• 架構師要爲“上游”用戶負責，使他們關心的功能需求和運行質量屬性得以滿足。
• 架構師必須顧及“下游”開發人員的協作分工。
• 架構師必須考慮周邊的管理人員，如配置管理員、運維工程師等。

• 一個架構視圖是對於從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的特定方面，而忽略了與之無關的其他方面。

• 架構設計是一種手段：

• 架構設計包含太多決策，超過了人腦“一蹴而就”的能力範圍，因此，採用“分而治之”的辦法從不同視角分別設計。
• 同時爲軟件架構的理解、交流、歸檔提供便利。

• 使用邏輯視圖和物理視圖刻畫大局非常有效。、

• 軟件的邏輯架構（視圖）規定了軟件系統的邏輯單元及交互。具體指邏輯層、功能子系統、模塊等。其核心任務是識別模塊、規劃接口，明確模塊間使用關係和使用機制。

• 軟件的物理架構（視圖）規定了組成系統的物理元素以及它們之間的聯繫和交互、部署和硬件策略等。

• 分佈式系統的流行，使得“物理層”的概念和設計比較流行和常態了。

• 多視圖≠多階段，不應瀑布式的設計每個視圖，而是應該迭代式設計。尤其對於大型系統而言，完全設計好邏輯視圖後，再設計物理視圖，是有很大問題的。

• 程序員向架構師轉變，難在何處？難在必須“試着做起來”，並慢慢積累感覺，進而積累經驗。

• “需求決定架構”之所以是一句廢話，在於其並沒有告訴開發人員“如何做架構設計”。

• 架構設計三個原則：

• 看透需求。架構師可能不是“需求”和“領域模型”的負責人，但必須深入瞭解。
• 大方向（即概念架構）正確。“關鍵需求”決定“概念架構”。
• 覆蓋各個方面。通過多視圖方法細化架構，滿足不同角色的需求。

• 看透需求，不僅要把需求找全，還要把需求項之間的矛盾關係、追溯關係搞清楚。

• 越是複雜的系統，越需要多視圖設計。這樣才能把問題研究和表達清楚。

• 什麼是概念架構（架構大方向）：

• 作爲架構師，進行大中型系統設計時，應該先比較幾種主流概念架構。
• 如果是售前，你所提到的架構，就是概念架構。
• 如果你去投標，那麼你提到的也是概念架構。

• 有經驗的架構師不會一上來就關注“模塊+接口”設計，而是優先關注：1. 重大需求；2. 特色需求；3. 高風險需求。

• 架構設計六大步驟：

1. 需求分析
2. 領域建模

領域建模的目的在於：透過問題領域的重重現象，捕捉其背後最爲穩固的概念以及這些概念之間的聯繫。架構師本人最好是作爲領域建模的領導者。

3. 確定關鍵需求
4. 概念架構設計

概念架構設計必須給出“一個決定、4個選型”。

5. 細化架構設計

指從五個不同視圖進行設計：邏輯架構、開發架構、運行架構、物理架構、數據架構。

6. 驗證架構設計

• 需求分析工作內容：

1. 需求溝通。
2. 確定非功能需求。

這是一個持續過程。

3. 需求分析主線。

• 領域建模的精髓是“業務決定功能，功能決定模型”。領域建模的輸入是當前的功能和未來的功能。

• 關鍵需求決定架構大方向。

• 概念架構設計輸入是“關鍵需求”，輸出是“一個決定，四個選擇”：

• 概念架構和細化架構的關鍵區別是：概念架構沒有設計到“模塊”+“接口”一級，而細化架構必須關注“模塊”+“接口”：

• 架構驗證需要根據情形判斷是否有必要。其目的在於儘早將那些有風險的重要部分開發出來，及早驗證。

• 需求分析必須基於“業務利益”：解決問題、創造機會、提高管控力。

• 軟件開發與交付流程：

其中概念化階段主要聚焦：

1. 願景分析
2. 風險評估
3. 可行性分析（比如硬件支撐等）
4. 項目進度和成本預估

• 需求分析=願景分析+需求分析

• 願景分析項目、產品、解決方案的起源問題。對於定製軟件而言，應由需方高層牽頭；對於產品軟件而言，應由市場部門的牽頭。願景分析必須闡述業務需求、及其產生的背景和理由。

• 願景分析最重要的文檔就是《願景與範圍文檔》，項目型公司可能叫《項目立項書》，產品型公司可能叫《產品需求書》或《市場需求書》：

• 業務需求

1. 背景
2. 業務機遇
3. 業務目標
4. 客戶或市場需求
5. 提供給客戶的價值
6. 業務風險

• 項目願景解決方案

1. 願景陳述
2. 主要特徵
3. 假設和依賴

• 範圍和侷限性

1. 首次發佈範圍
2. 隨後發佈範圍
3. 侷限性和專用性

• 業務環境

1. 客戶或用戶概貌
2. 項目優先級

• 成功的因素

• 上下文圖的目的是明確系統相關的外部因素和事件，促進更完整的認識系統需求和外部約束。通常將待研發系統放在上下文圖的中間，不展示系統的任何內部結構。只關注系統外圍，不關注系統內部。

• 上下文圖常見三種畫法：

1. 頂層數據流圖。
2. 將System處理成黑盒的用例圖。
3. Powerpoint繪製的框圖。

• 願景分析其實就是“需求調研”，前者重目標，後者重活動。

• 願景分析實踐要領：

• 範圍、特性、上下文圖是刻畫高層需求的“三劍客”：

• 軟件需求的定義：爲用戶做什麼？

• 軟件需求“上承願景”，“下接設計”。需求分析要在《願景與範圍文檔》的基礎之上，進一步細化軟件需求，將需求轉化爲功能定義。

• 需求分析分爲三個任務：

1. 需求捕獲 – 理解溝通

2. 需求分析 – 做什麼

3. 系統分析 – 怎麼做

三者不是獨立無關的階段，而是相互伴隨、交叉進行的。

• 典型的需求捕獲是使用“需求採集卡”：需求描述、需求提出者、需求記錄者、需求類型等。

• 需求捕獲得到的是“原始需求”，而需求分析則對其【用戶(人)的需求】進行分析、整理、歸納、論證形成明確的軟件需求。

• 需求分析要形成明確規範的《需求規格說明書》，使用用例圖聚焦每個功能刻畫系統行爲。

• 需求的分類：

第一緯度

• 組織需求（工期、資金、遺留系統整合等等）
• 用戶需求（用戶完成哪些工作）
• 開發需求（開發人員需要實現什麼、開發和維護期考量）

第二緯度

• 功能需求（直接業務需求）
• 質量屬性（運行期質量）
• 約束需求（業務環境因素+使用環境因素+構建環境因素+技術環境因素）

• 需求分析的“三橫兩縱”：

• 三橫

1. 確定系統目標
2. 研究高層需求
3. 建立用例模型

• 兩縱

1. 需求溝通、需求啓發、需求驗證
2. 確定非功能需求

• 在需求分析過程中需要和客戶不斷溝通，這時客戶希望能夠看到具有實際感的界面。爲此，應該在需求分析階段就開始界面設計，並用其輔助和客戶交流。但界面設計不應放在《需求規格書》中，它是設計而非需求。界面原型可以啓發需求。

• 《軟件需求規格說明書》是需求分析工作的最重要成果。

• 常用的用例技術包括：用例圖、用例簡述、用例規約（詳述）、魯棒圖（用例實現）。以“需求層次”（業務需求、用戶需求、行爲需求）爲背景，對四種技術的使用和定位進行分析：

• 用例規約就是用例的詳細稱述，一般應用在比較複雜的用例中。以下是一份典型的用例規約：

1. 用例名稱：

銀行銷戶

2. 簡要說明：

xxxxxx。

3. 事件流：

3.1 基本事件流

1. 銀行工作人員進入“活期賬戶銷戶”界面。
2. 銀行工作人員讀取磁條卡片信息。
3. 系統展示賬戶信息
4. 工作人員覈對證件材料
5. …

3.2 擴展事件流

1. 如果磁卡讀取失敗，需手動輸入賬號
2. …

4. 非功能需求：

5. 前置條件:

6. 後置條件：

7. 優先級

高。

• 用例圖 + 用例簡述可以應用於需求捕獲，或業務不太複雜的系統的需求分析。

• 用例規約應用於需求分析和需求規格定義書。

• 用例實現（魯棒圖）應用於初步設計。用例是需求，魯棒圖已經是設計。

• 基於用例的需求分析方法：

• 《需求規格書》需要區別對待每個用例，並不是每個用例都有必要細化到用例規約的程度。

• 典型的《需求規格書》：

• 需求變更對用例圖和用例簡述的影響小，而對用例規約和用例實現的影響大，因此，實踐中應該“推後用例細化、激發需求變更”。

• 實踐中是實踐決定方法，而不是方法一刀切實踐。需求分析的流程可以根據系統特性，定義爲“大中小”三套流程：

1. 小型系統

2. 中型系統

3. 大型系統

在大型系統中要避免一開始就畫用例圖，而應當首先儘可能的勾畫出主要流程圖，並層層細化流程，從而促進發現用例。

• 領域模型比《領域詞彙表》更進一步，其不僅關注領域概念，更刻畫它們之間的聯繫。

• 領域模型最常採用UML中的類圖和狀態圖進行表述。類圖是主要表現手段，狀態圖進行輔助表示。

• 領域層與視圖層關係（視圖層）密切；同時其對數據持久化（數據層）也影響巨大。經過精化的領域模型也將是業務層的核心。由此可見，領域模型對系統各個層面都有影響，其重要性不言而喻。

• 領域模型依賴於客戶的深度參與，因此，需求分析人員或架構師必須積極調動客戶參與度。

• 領域知識的核心是領域概念之間的聯繫。

• 破解“陌生領域知識不足”的關鍵是“理順概念關係、搞清業務規則”。

• 領域模型是對領域問題某種程度抽象，抽象就意味着有目的性的忽略。

• 領域建模影響功能擴展，那麼，反過來，就可以使用“功能擴展”驅動“領域建模”。

• 架構設計時，“確定關鍵需求”要一次做對！

• 關鍵需求決定架構，其餘需求驗證架構。

• 架構師沒有精力對“所有需求”進行深入分析，這是現實；架構師沒有必要對“所有需求”進行深入分析，這是策略。

• 概念架構指定義高層組件及其聯繫，不應涉及接口。

• 設計思想必須和“核心（直接）目標”相聯繫。

• 概念架構貴在針對性，“直指目標”、“設計思想”、“重大選擇”是它的三大特徵。

• 概念架構中關注高層組件，這些應該只有職責，而沒有接口。

• 需求和設計之間存在“鴻溝”：

1. 用例是面向問題域的，而設計是面向機器域的。
2. 用例技術本身不是面向對象的，而設計應該面向對象。
3. 用例規約採用自然語言描述，而設計採用形式化的模型表述（如UML）等。

• 從功能設計到設計的鴻溝需要“橋”：魯棒圖。魯棒圖設計之初的目的是用以回答“每個用例都需要哪些對象”。

• 概念架構設計任務順序：

• 可以根據系統複雜度，來靈活把握對多少“關鍵功能”進行“魯棒圖設計”。

• 對於個人能力的培養，對比備選設計、評審設計優缺點，能夠洞察設計的“所以然”，是非常有效的方式。

• 和2視圖法相比，5視圖法更適合大型系統。

• 架構視圖是設計架構、描述架構的核心手段。

• 程序員向架構師轉型的關鍵是“學會系統思考”。對軟件系統而言，系統思考就是對複雜系統各個構件之間的聯繫深入探究。

• 架構設計5視圖：

• 架構設計的15個任務：

• 邏輯架構任務：

1. 職責劃分（邏輯層、子系統、模塊、管件類）
2. 職責協作（接口、協作關係）

核心任務是模塊劃分、接口定義、領域模型細化。靜態方面使用UML包圖、類圖、對象圖；動態方面使用序列圖、協作圖、狀態圖、活動圖。

• 邏輯架構一般細化到模塊級別，但對如下幾種情況，需要可細化到類：

1. 接口定義類
2. Facade類
3. 核心控制類
4. 領域模型中的核心類

• 領域建模時一般並不區分“接口”和“類”，通常都是作爲“一般類”定義的。而到了細化架構階段，需要對領域模型細化到可以編程的程度，此時就必須明確區分“接口”和“類”，同時某些“類”要降級爲“屬性”，而某些“屬性”可能升級爲“類”。

• 軟件架構設計的難點在於：它是跨越現實世界（問題領域）到計算機世界（解決方案）之間的鴻溝。

• 需求分析的意圖是明確“問題領域”，架構設計的意圖是完成面向問題到面向解決方案的轉換。

• 功能樹 vs 功能模塊結構圖

1. 前者是功能分解結構，後者是對系統進行結構分解的結構示意圖。
2. 前者刻畫問題領域，後者刻畫解決方案。
3. 前者是需求分析層面，後者是設計層面。
4. 前者是架構師從上層（需求分析師）得到的，後者是架構師親自設計出來的。

• 從功能樹到功能模塊，是粗粒度功能模塊劃分的常見手段。

• 如何與需求人員交流溝通，是架構師的應有的技能。

• 功能樹不是界面結構圖。

• 描述需求的序列圖，描述的是“內外對話”；描述設計的序列圖，描述的是“內部（對象）協作”。

• 用例驅動的模塊劃分：

1. 第一步，回答“實現用例需要哪些類”的問題。運用魯棒圖、序列圖。
2. 第二部，回答“這些類應該劃分到哪些模塊”的問題。運用包圖。

• 魯棒圖是類圖，不是序列圖。魯棒圖中的連線並不是嚴謹的對象間協作關係。

• 用例驅動的設計時，沒必要每個用例都畫序列圖或魯棒圖。而應找關鍵用例（與關鍵需求相關）。

• 用例驅動的設計優缺點：

1. 用例多，從用例到類，再到模塊，設計工作量大。
2. 適用於不熟悉的領域軟件
3. 如果運用太死板，會落入“先詳細設計，再架構設計”的陷阱。
4. 爲後續詳細設計提供了便利，因此受到“程序組長”的歡迎。

• 模塊劃分技能的四種思路：

• 設計思維融合的關鍵是，把層、功能模塊（子系統）、細粒度模塊這三個概念看透：

1. 一個細粒度模塊，必然位於架構的某一層中。
2. 一個細粒度模塊，必然位於架構的某一功能模塊中。

• EDD（封裝驅動設計方法）是的目的是：細粒度模塊劃分。綜合運用分層、分層細化、功能模塊、通用模塊、通用機制框架化等手段，是該方法的核心特點。

• EDD的步驟：

1. 研究需求
2. 粗粒度分層
3. 細粒度劃分模塊
4. 用例驅動的模塊劃分結構評審、優化。

• 對模塊劃分促進最大的需求成果是上下文圖和功能樹。

• EDD步驟：