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

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

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

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

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

“有一段時(shí)間沒有編碼了。”

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

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

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

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

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

1 反饋

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

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

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

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

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

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

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

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

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

3 提高參與度的策略

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

結(jié)對(duì)

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

同行評(píng)審

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

開發(fā)尖兵

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

故事開發(fā)

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

輪轉(zhuǎn)

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

4 需要避免的參與方式

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

只處理難題

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

接管

另外一種不推薦的方法就是用命令 - 控制的方式接管交付。架構(gòu)師在架構(gòu)定義上所花費(fèi)的時(shí)間和精力，特別是在架構(gòu)師融為團(tuán)隊(duì)的一部分時(shí)，能夠?yàn)槌晒Φ慕桓短峁┳銐虻膭?dòng)力。架構(gòu)師可能會(huì)產(chǎn)生整體控制整個(gè)交付方方面面的意圖，而不僅僅局限于引導(dǎo)交付向架構(gòu)性目標(biāo)努力。這種方法會(huì)導(dǎo)致如下的消極影響：

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

限制了團(tuán)隊(duì)成員的主人翁意識(shí)和成長的機(jī)會(huì)。

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

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

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

5 總結(jié)

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

?英文原文

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

總結(jié)

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

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