架構師是否應該寫代碼？

當我面試架構師職位的候選人時，我通常會問一個這樣的問題：「你認為架構師是否應該做一些編碼工作？」而通常會得到下面兩個反饋之一：

「不，我正在尋找一個不再需要編碼的職位。」

「我喜歡繼續編碼，至少是少量的編碼，但可能不會有時間這樣做。」

與此類似，當問及其他一些架構師最近做過多少編碼的工作，通常得到的答案是：

「有一段時間沒有編碼了。」

這些回應總是讓人感到不安。從何時開始一個技術角色的提升開始意味著脫離技術和交付？如果不能深入到實現這些技術的團隊中，架構師又怎能期望在規模龐大的技術選擇中指引方向，並理解這些技術如何在企業中發揮作用？或者更好的是，親自實施這些技術？在沒有與交付團隊保持緊密聯繫的前提下，架構師如何能夠期望在應對持續變化的項目需求時，保持靈活？優秀的架構師必須與交付團隊緊密合作。這對發展成功的系統架構，進而成功交付是十分必要的。收集反饋並展現領導力是保持與交付團隊緊密合作的兩個核心利益。

反饋

深度參與的架構師會見證第一手反饋信息並且與團隊緊密合作以緩解各種缺陷。反饋可能源自於各處，如企業標準的變化，持續變化或發展的功能性/非功能性需求以及在實施和測試過程中所發現的各種挑戰。能夠越早識別這些缺陷，架構師就能夠越快改進系統架構。如果架構師沒有積极參与到交付團隊中，那麼這個反饋可能會花費數周甚至數月才能夠上報給架構師，這時通常已經處於交付周期的晚期了。

鑒於架構決策通常會包含一些非常重要或者難以改變的內容，如果需要重大的架構性調整，這一反饋方面的延遲只會加重。在交付周期的晚期發現架構性缺陷通常會採取變通方案以「暫時熬過這一版本」，與此同時也會留下技術債務。然而，越早捕獲和評估這一反饋的架構性影響，整個項目就會越敏捷，風險累積也會更少

領導力

架構師所承擔的另一主要職責就是領導力。領導力有多種形式，所有這些形式對於成果及其底層架構的成功實現來說都是至關重要的。為了團隊的成功實現，架構領導力要求架構師能夠有效地與團隊溝通「大局觀」。傳遞這一信息的最佳方案就是與交付團隊緊密合作並進行若干次相關討論，而不是僅僅通過一篇文檔、一次會議或一場演講。架構方向必須在工作過程中反覆調整。太過於陷入交付的熱情中，很容易忽視整體目標。一個持續參與的架構師可以幫助維繫願景的一致性。

技術領導力源於這樣的事實：架構師通常在開發和交付方面具有豐富的經驗。架構師的目標之一就是教育開發團隊幫助其成長。有些情況下有專門的技術領導人擔當這一角色，但為什麼要讓架構師所獲得的經驗浪費掉？這種交互不僅能夠讓整個團隊受益，也能夠讓架構師更好地了解開發團隊所遭遇的常見問題。

導師是架構師可以向團隊傳遞的非技術領導力的一種形式。如何與非技術人群合作，擁抱敏捷原則，定義架構以及架構建模等話題都是對開發人員和潛在架構師成長十分重要的技能。與更加正式的，課堂式的教育機會相比，架構師這一角色的訓練和知識多數都源於在職經驗。架構師應該擁抱這一趨勢並讓架構學習更加主動而非被動。

提高參與度的策略

參與項目的架構師可能不必親自交付故事。實際上，取決於諸如架構師-開發人員比率或項目的對外承諾等因素，讓架構師獨自負責並交付故事可能並不是一個最優方案。下面是一些可以讓架構師與交付團隊緊密合作並增加架構師與團隊之間交互的一些策略。

結對

結對或結對編程是一種敏捷軟體開發技術，隨著極限編程方法而逐漸流行，在結對編程技術中，兩個團隊成員共同工作於一個工作站以完成一個共同的目標。在這一場景下，架構師永遠不會獨立地負責一個故事，而是與團隊中的其他成員結對完成必須的設計、開發和/或測試工作。這一方法的優點在於能夠讓架構師保持對交付所負有的責任並且與所發現的架構性反饋保持緊密聯繫，同時又避免在架構師必須要擔負外部責任的情況下團隊資源的流失。

同行評審

這一方法與結對類似，不過反饋迴路相對較慢。同行評審指的是一名同行從質量的角度評審另外一名同行的工作，通常是在大部分工作已經完成之後。在這裡，架構師與開發者一起同行評審代碼，定期的或者在故事完成之前評審一次。通過這種方法，架構師能夠獲得對架構一致性或問題預防一致性的深度洞察並且有機會通過開發諫言的形式建立領導力。

開發尖兵

架構師可以帶領一個專註於架構探索或交付的開發尖兵團隊。尖兵通過探索某項新技術，用於識別或降低風險架構某一方面的功能性概念驗證的實現。尖兵提供了絕佳的機會以了解已經實現的架構決策，致力於交付目標並促進更多的針對架構瑕疵或限制的即刻視野。他們還鼓勵架構師直接參与到實現中，與團隊合作，共享架構願景，並直接從過去的經驗中獲益。

故事開發

架構師也可以成為團隊成員並完成實際的故事交付。這可能是聯繫最緊密的反饋迴路。這種方法的缺點在於架構師可能太過於專註在個別的故事之上（只見樹木不見森林）。必須保持維繫架構願景和長遠規劃與詳細設計和具體實現之間的平衡。此外，需要注意的是，這種方法可能會破壞團隊速度的一致性。舉例來說，如果架構師在進行實際的故事開發三周後，被抽調出去兩周完成一些更高層級的工作（如路線圖），這可能會對團隊的整體速度造成一定影響。首先，儘管我同意短期可能會影響速度；但長期來看由於平均法則的緣故，對速度的影響會顯著降低。其次，如果架構師要進行高層級的項目相關工作，那麼應該為其安排與待交付故事相關的故事任務，這樣可以減少架構師必須管理的高層級與低層級任務之間的轉換次數。

輪轉

在這一策略中，一段時間內，架構師這一角色會在團隊成員之間輪轉。在每個成員擔任架構師這一角色的期間，他們需要承擔作出架構決策、維繫架構一致性以及提供總體架構指導的職責。在不同的團隊成員之間輪轉架構師角色所帶來的收益是能夠提升團隊整體的工作架構知識。團隊成員能夠對參與到交付中的各個角色均有更好的理解，這會促進團隊角色之間的共鳴，提升團隊內部的交互，以及通過應用於每個角色之上的多樣化視角所帶來的更好的整體產品。我會建議謹慎地使用輪轉策略，因為輪轉所產生的不一致性導致的混亂可能會比所得到的收益更多。取決於團隊的組成和發布周期的長度，在主要發布版本（3-6個月）時間線上的某個時點進行輪轉可能會比較合適。

需要避免的參與方式

有一些策略可以提升架構師在交付過程中的參與度，同樣也有一些架構師可能也會採取的提升參與度的方法會對整個團隊的健康發展不利，這種嘗試應當盡量避免。

只處理難題

架構師可能會有隻處理難題的傾向，無論這一工作是否包含在故事當中。考慮到架構師的資歷和經驗，這看起來像是顯而易見的；然而，長期來看這可能會有損團隊健康發展。首先，由於未參與其中，團隊可能不會完全理解也無法支持系統中這些複雜的細微差別。其次，軟體開發人員享受有挑戰的工作。架構師解決了所有的難題的同時也就剝奪了其他人挖掘和學習新知識的機會。

接管

另外一種不推薦的方法就是用命令-控制的方式接管交付。架構師在架構定義上所花費的時間和精力，特別是在架構師融為團隊的一部分時，能夠為成功的交付提供足夠的動力。架構師可能會產生整體控制整個交付方方面面的意圖，而不僅僅局限於引導交付向架構性目標努力。這種方法會導致如下的消極影響：

這樣的團隊會對控制型的架構師產生憤怒情緒，而無法形成自組織、高效率和相互合作的團隊。

限制了團隊成員的主人翁意識和成長的機會。

難以處理更大的交付規模。

驅動細節，而非本質

在進行結對編程或者同行評審時，架構師應該驅動需求的本質，而非細節。即使是最簡單的邏輯也有許多種編碼方式，而且其中有許多都能夠完美地實現功能，儘管並非完全照搬架構師的思路。架構師必須要在架構方向上加以指引，並強制實施本地代碼標準，與此同時也要允許一些例外。

總結

要讓一個成功的架構得以實現，架構師必須要在整個生命周期始終保持與交付團隊的緊密合作。保持緊密合作能夠促進架構層面的快速反饋循環。並且還能夠為架構師提供更多的與團隊交流架構願景和領導團隊的機會。正如本文題目所描述的那樣，架構師除了可以參與到實際的編碼工作中之外，還有許多其他的方式可以參與到交付團隊中，例如結對編程和同行評審。相反，某些參與方式有可能會對團隊造成負面影響，例如接管交付、不允許團隊自組織或者採用集體所有制。其中一個關鍵目的是為了避免「象牙塔」架構師的角色——只在項目最初發布架構，然後就再也不見蹤影。謀求與交付團隊的協作關係，共同努力儘早識別和解決架構性缺陷，從而交付成功的架構和最終的產品。

關於作者

Brandon Bryson是MasterCard這家技術公司及支付領域領導者的高級顧問，主要關注應用架構、開發和敏捷交付。他是在技術領導力、架構與設計、敏捷原則以及三者融合方面富有激情的軟體行業15年的老兵。他在包括國防、旅行、供應鏈以及金融等多個行業中的財富500強企業和初創企業中均有任職經歷，並且擁有密蘇里大學的計算機科學學位。

注:本文來源於infoq

原文：Architects Should Code: The Architect』s Misconception

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！