Software Architecture Organizational Principles and Patterns

    軟體架構組織原則與模式的摘要和筆記

   
誰才是架構師？怎樣做好架構？

   
軟體架構的主要障礙往往在於組織方面而非技術。創造切實可行的軟體架構需要對技術的深入把握、良好的認知能力和溝通技巧以及大量艱苦的工作。然而，軟體架
構的成功並非只是技術和優秀工程師的事情，它的成功往往依賴於資深經理、主管和實施者（此處指架構的實施者，可以理解為產品開發人員，即使用架構進行開發，
實現架構價值的人）所忽略的組織因素。技術上出色的架構往往由於沒有全面的處理好組織因素而失敗。

    VRAPS (Vision, Rhythm, Anticipation,
Partnering, and Simplification) Reference
Model
   
VRAPS模型的核心包括構想、節奏、預見、協作、簡化5項原則。模型的重點在實現和發展軟體架構的組織方面。

   
構想
   
可以把構想理解為願景、藍圖，架構構想指對架構價值的勾畫，實際中往往表現為對架構主體功能、某方面特性的描述、期望等。
    架構師：架構師的職責就是分析構想，設計實現構想。"作為一名架構師，更多的意味著如何平衡
業務、組織運作和技術，而不僅僅是技術細節"，架構師更像管理者而非實施者。架構師對外必須關注產品開發人員和最終客戶的世界，同時又對內關注架構和業務
團體的領域。
   
構想面臨的挑戰：並非所有擁有架構師頭銜的人都對架構有實質上的影響，可能需要在一個組織內找上一番，才能發現究竟是誰擔當了“架構構想看護人”的角色，
可能是創業軟體公司的CEO，或者產品/產品線經理、資深經理、一群進階開發人員等。許多因素影響架構構想的一致性（不存在衝突），其中一些因素是架構師
所能控制的，而其它許多對確保架構構想成功非常關鍵的因素則超出了架構師的影響能力和範圍。
   
當架構師與構想的發起人，或者構想的多個發起人之間發生分歧時，說明構想是不穩定的。

 
  
準則1：確保構想與發起人、使用者（指架構的使用者，即產品開發人員）和最終客戶（最終產品的客戶）期望實現的目標保持一致
    1. 反模式 反重力裝置 Antigravity
Module
   
因各方面原因去實現那些看似很好卻無法實現的功能特性。例如反重力裝置，能夠實現當然很好，卻要打破物理定律才能實現。
    2. 模式 前端符合 Front-End
Alignment
   
處理如何正確的為架構添加新功能特性，尤其對於那些較為激進的目標。
   
準則2：實施人員（架構的使用者，即產品開發人員，以及產品的最終客戶）信任並使用架構。
  
  1. 反模式 潮流追隨者 Trend
Surfer
   
追隨潮流會侵蝕架構的結構並攪亂構想。如果組織的所有部門（如高層經理、銷售、市場、客服、設計部等等）對構想、產品發展方向沒有達成基本的共識，都會支
配或影響組織的行為。市場的新技術、競爭者的新功能、客戶的新需求等都會驅使架構朝不同方向發展。
   2. 模式 建設性構想 Generative
Vision
   
如何為架構勾畫建設性構想。要抵制建立一個無所不能的架構的誘惑。規劃者應該把自己的構想更多的限定在功能或業務需求方面，而讓架構師關心實現問題（既包
括技術實現方面，也包括業務設計方面）。架構師不能輕信資深經理在實現意見上的看法，應該更加關注資深經理想要得到什麼。
   
準則3：架構潛在知識的傳播
   
優秀的架構可能被很不恰當的使用而問題重重，一般的架構也可能被使用的很好。關鍵在於需要讓架構的使用者明確架構的思想（潛在知識），引導使用者正確的按
照這種思想來使用。
    1. 反模式 惟命是從 Following
Orders
   
指團隊成員只把精力專註在自己的任務和職責上，不原意作為架構思想的傳播者，不考慮自己的成果他人是如何使用的。
    2. 模式 輪轉工作
Rotation
   
關鍵要實現螺旋式上升而非平面環的工作輪轉。作用：避免地方保護主義者的離開造成的空缺以及潛在知識的丟失；改善潛在知識的傳播；提升團隊成員能力。負
面：新的具有挑戰性的工作可能給部分人造成壓力、威脅感；工作輪轉的成本代價；空降兵從螺旋的中間插入，可能引起老員工的不滿等等。

   
節奏
   
在速度（進度）、內容（包含的功能特性）、品質之間平衡，維持一種正常的節奏。打破這個平衡就意味著不正常，可能造成一系列交叉影響的風險變成現實。俠義
的理解可以是一系列主發布、次發布、缺陷修改等活動。
   
準則1：經理們週期性再評估、同步和調整架構
    1. 反模式 殺手特性 Killer
Feature
   
指管理層認為至關重要的一些功能特性。它打破正常的節奏，使各方的關注點高度集中在這上面，Team Dev疲於應對，甚至可能影響架構發展方向。慌亂的應付經常
導致諸多問題的出現。殺手特性可以添加到架構中，但要做詳盡的評估分析論證，不要打破既定的節奏。
 
  2. 模式 發布委員會 Release Committee
   
從各團隊挑選人選成立，週期性為節奏中的各個Release評估風險，制定解決方案。 
避免成為爭吵、發牢騷的會議。
   
變體：發布代表委員會。當發布委員會成員比較多，分歧又比較大時，週期性會議必將成為爭吵的焦點。這時可以從發布委員會中抽取代表成立發布代表委員會，代
替發布委員會，這樣某些分歧可以讓代表先在內部評估，達成一致。
   
準則2：架構團隊對架構Release的進度和內容具有高度信心
   
1. 反模式 短路 Shortcut
   
指架構團隊感覺無法維持節奏時，在流程上做裁減以求彌補，容易造成將一些問題遺留到後續階段才暴露出來，增加修正成本。
    2. 模式 棄球前進 Drop
Pass
   
抱著橄欖球會影響奔跑速度，而前方又無自己隊員，此時可以將球丟給後方隊友放手狂奔。有的時候為了不影響其它團隊，可能確實需要放棄某些功能特性、缺陷修
補，而按照節奏進行Release。
   
準則3：通過節奏協調明確的活動
    1. 反模式 破裂載入
Broken Loads
   
例如在整合前夕各個要整合的部分都存在不少問題，破裂載入是節奏已經被破壞的訊號。將存在問題的各個部分整合起來，比預期的代價要大。例如Daily
Build，偶爾失敗可能不是一件大事，但如果反覆出現就是一個必須解決的問題。
  
  2. 模式 同步發布 Synchronize
Releases
   
在各個協作部分之間保證、加速Release的措施。

...未完