從什么時候起，技術(shù)角色的提升就意味著脫離技術(shù)與交付？CTO 不寫代碼已經(jīng)引起諸多爭議了，架構(gòu)師也不寫代碼，能行嗎？

當(dāng)我面試架構(gòu)師職位的候選人時，我通常會問一個這樣的問題：“你認(rèn)為架構(gòu)師是否應(yīng)該做一些編碼工作？”而通常會得到下面兩個反饋之一：

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

“我喜歡繼續(xù)編碼，至少是少量的編碼，但可能不會有時間這樣做。”

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

“有一段時間沒有編碼了。”

這些回應(yīng)總是讓人感到不安。從何時開始一個技術(shù)角色的提升開始意味著脫離技術(shù)和交付？

如果不能深入到實現(xiàn)這些技術(shù)的團隊中，架構(gòu)師又怎能期望在規(guī)模龐大的技術(shù)選擇中指引方向，并理解這些技術(shù)如何在企業(yè)中發(fā)揮作用？或者更好的是，親自實施這些技術(shù)？

在沒有與交付團隊保持緊密聯(lián)系的前提下，架構(gòu)師如何能夠期望在應(yīng)對持續(xù)變化的項目需求時，保持靈活？

優(yōu)秀的架構(gòu)師必須與交付團隊緊密合作。這對發(fā)展成功的系統(tǒng)架構(gòu)，進而成功交付是十分必要的。

收集反饋并展現(xiàn)領(lǐng)導(dǎo)力是保持與交付團隊緊密合作的兩個核心利益。

1 反饋

深度參與的架構(gòu)師會見證第一手反饋信息并且與團隊緊密合作以緩解各種缺陷。反饋可能源自于各處，如企業(yè)標(biāo)準(zhǔn)的變化，持續(xù)變化或發(fā)展的功能性 / 非功能性需求以及在實施和測試過程中所發(fā)現(xiàn)的各種挑戰(zhàn)。

能夠越早識別這些缺陷，架構(gòu)師就能夠越快改進系統(tǒng)架構(gòu)。如果架構(gòu)師沒有積極參與到交付團隊中，那么這個反饋可能會花費數(shù)周甚至數(shù)月才能夠上報給架構(gòu)師，這時通常已經(jīng)處于交付周期的晚期了。

鑒于架構(gòu)決策通常會包含一些非常重要或者難以改變的內(nèi)容，如果需要重大的架構(gòu)性調(diào)整，這一反饋方面的延遲只會加重。

在交付周期的晚期發(fā)現(xiàn)架構(gòu)性缺陷通常會采取變通方案以“暫時熬過這一版本”，與此同時也會留下技術(shù)債務(wù)。然而，越早捕獲和評估這一反饋的架構(gòu)性影響，整個項目就會越敏捷，風(fēng)險累積也會更少。

2 領(lǐng)導(dǎo)力

架構(gòu)師所承擔(dān)的另一主要職責(zé)就是領(lǐng)導(dǎo)力。領(lǐng)導(dǎo)力有多種形式，所有這些形式對于成果及其底層架構(gòu)的成功實現(xiàn)來說都是至關(guān)重要的。

為了團隊的成功實現(xiàn)，架構(gòu)領(lǐng)導(dǎo)力要求架構(gòu)師能夠有效地與團隊溝通“大局觀”。傳遞這一信息的最佳方案就是與交付團隊緊密合作并進行若干次相關(guān)討論，而不是僅僅通過一篇文檔、一次會議或一場演講。架構(gòu)方向必須在工作過程中反復(fù)調(diào)整。太過于陷入交付的熱情中，很容易忽視整體目標(biāo)。一個持續(xù)參與的架構(gòu)師可以幫助維系愿景的一致性。

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

導(dǎo)師是架構(gòu)師可以向團隊傳遞的非技術(shù)領(lǐng)導(dǎo)力的一種形式。如何與非技術(shù)人群合作，擁抱敏捷原則，定義架構(gòu)以及架構(gòu)建模等話題都是對開發(fā)人員和潛在架構(gòu)師成長十分重要的技能。與更加正式的，課堂式的教育機會相比，架構(gòu)師這一角色的訓(xùn)練和知識多數(shù)都源于在職經(jīng)驗。架構(gòu)師應(yīng)該擁抱這一趨勢并讓架構(gòu)學(xué)習(xí)更加主動而非被動。

3 提高參與度的策略

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

結(jié)對

Martin Fowler 在 2015 年 O’Reilly 的一次軟件架構(gòu)研討會上發(fā)表的講話中曾經(jīng)提到結(jié)對可能是讓架構(gòu)師更有參與感的一種很好的選擇。結(jié)對或結(jié)對編程是一種敏捷軟件開發(fā)技術(shù)，隨著極限編程方法而逐漸流行，在結(jié)對編程技術(shù)中，兩個團隊成員共同工作于一個工作站以完成一個共同的目標(biāo)。在這一場景下，架構(gòu)師永遠不會獨立地負責(zé)一個故事，而是與團隊中的其他成員結(jié)對完成必須的設(shè)計、開發(fā)和 / 或測試工作。這一方法的優(yōu)點在于能夠讓架構(gòu)師保持對交付所負有的責(zé)任并且與所發(fā)現(xiàn)的架構(gòu)性反饋保持緊密聯(lián)系，同時又避免在架構(gòu)師必須要擔(dān)負外部責(zé)任的情況下團隊資源的流失。

同行評審

這一方法與結(jié)對類似，不過反饋回路相對較慢。同行評審指的是一名同行從質(zhì)量的角度評審另外一名同行的工作，通常是在大部分工作已經(jīng)完成之后。在這里，架構(gòu)師與開發(fā)者一起同行評審代碼，定期的或者在故事完成之前評審一次。通過這種方法，架構(gòu)師能夠獲得對架構(gòu)一致性或問題預(yù)防一致性的深度洞察并且有機會通過開發(fā)諫言的形式建立領(lǐng)導(dǎo)力。

開發(fā)尖兵

架構(gòu)師可以帶領(lǐng)一個專注于架構(gòu)探索或交付的開發(fā)尖兵團隊。尖兵通過探索某項新技術(shù)，用于識別或降低風(fēng)險架構(gòu)某一方面的功能性概念驗證的實現(xiàn)。尖兵提供了絕佳的機會以了解已經(jīng)實現(xiàn)的架構(gòu)決策，致力于交付目標(biāo)并促進更多的針對架構(gòu)瑕疵或限制的即刻視野。他們還鼓勵架構(gòu)師直接參與到實現(xiàn)中，與團隊合作，共享架構(gòu)愿景，并直接從過去的經(jīng)驗中獲益。

故事開發(fā)

架構(gòu)師也可以成為團隊成員并完成實際的故事交付。這可能是聯(lián)系最緊密的反饋回路。這種方法的缺點在于架構(gòu)師可能太過于專注在個別的故事之上（只見樹木不見森林）。必須保持維系架構(gòu)愿景和長遠規(guī)劃與詳細設(shè)計和具體實現(xiàn)之間的平衡。此外，需要注意的是，這種方法可能會破壞團隊速度的一致性。舉例來說，如果架構(gòu)師在進行實際的故事開發(fā)三周后，被抽調(diào)出去兩周完成一些更高層級的工作（如路線圖），這可能會對團隊的整體速度造成一定影響。首先，盡管我同意短期可能會影響速度；但長期來看由于平均法則的緣故，對速度的影響會顯著降低。其次，如果架構(gòu)師要進行高層級的項目相關(guān)工作，那么應(yīng)該為其安排與待交付故事相關(guān)的故事任務(wù)，這樣可以減少架構(gòu)師必須管理的高層級與低層級任務(wù)之間的轉(zhuǎn)換次數(shù)。

輪轉(zhuǎn)

在這一策略中，一段時間內(nèi)，架構(gòu)師這一角色會在團隊成員之間輪轉(zhuǎn)。在每個成員擔(dān)任架構(gòu)師這一角色的期間，他們需要承擔(dān)作出架構(gòu)決策、維系架構(gòu)一致性以及提供總體架構(gòu)指導(dǎo)的職責(zé)。在不同的團隊成員之間輪轉(zhuǎn)架構(gòu)師角色所帶來的收益是能夠提升團隊整體的工作架構(gòu)知識。團隊成員能夠?qū)⑴c到交付中的各個角色均有更好的理解，這會促進團隊角色之間的共鳴，提升團隊內(nèi)部的交互，以及通過應(yīng)用于每個角色之上的多樣化視角所帶來的更好的整體產(chǎn)品。我會建議謹(jǐn)慎地使用輪轉(zhuǎn)策略，因為輪轉(zhuǎn)所產(chǎn)生的不一致性導(dǎo)致的混亂可能會比所得到的收益更多。取決于團隊的組成和發(fā)布周期的長度，在主要發(fā)布版本（3-6 個月）時間線上的某個時點進行輪轉(zhuǎn)可能會比較合適。

4 需要避免的參與方式

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

只處理難題

架構(gòu)師可能會有只處理難題的傾向，無論這一工作是否包含在故事當(dāng)中。考慮到架構(gòu)師的資歷和經(jīng)驗，這看起來像是顯而易見的；然而，長期來看這可能會有損團隊健康發(fā)展。首先，由于未參與其中，團隊可能不會完全理解也無法支持系統(tǒng)中這些復(fù)雜的細微差別。其次，軟件開發(fā)人員享受有挑戰(zhàn)的工作。架構(gòu)師解決了所有的難題的同時也就剝奪了其他人挖掘和學(xué)習(xí)新知識的機會。

接管

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

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

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

難以處理更大的交付規(guī)模。

驅(qū)動細節(jié) 而非本質(zhì)

在進行結(jié)對編程或者同行評審時，架構(gòu)師應(yīng)該驅(qū)動需求的本質(zhì)，而非細節(jié)。即使是最簡單的邏輯也有許多種編碼方式，而且其中有許多都能夠完美地實現(xiàn)功能，盡管并非完全照搬架構(gòu)師的思路。架構(gòu)師必須要在架構(gòu)方向上加以指引，并強制實施本地代碼標(biāo)準(zhǔn)，與此同時也要允許一些例外。

5 總結(jié)

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

?英文原文

https://www.infoq.com/articles/architects-should-code-bryson

總結(jié)

以上是生活随笔為你收集整理的CTO不写代码就算了，架构师也不写？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。