架構(gòu)是一種能力，它不是頭銜。換句話說，我們需要具備架構(gòu)能力，但不一定要成為架構(gòu)師。

?[[331339]]?

圖片來自 Pexels

既然這樣，那我們還需要架構(gòu)師嗎?還需要架構(gòu)部門嗎?我給出的答案是：不需要，因為每個人都應(yīng)該是架構(gòu)師。

為什么架構(gòu)師不 Work?

在來阿里之前，我是在 eBay 的 payments 部門工作，當(dāng)時有一個架構(gòu)師叫 Scott，所有的設(shè)計和方案都需要獲得他的 approve 才能通過，結(jié)果他成了整個團隊的 bottleneck，很多事情都 block 在他那個地方。

工程師很難受，光是給他介紹業(yè)務(wù)和系統(tǒng)設(shè)計，就需要花費了大量的時間討論(因為時差原因，經(jīng)常一個討論要一個星期才會有定論)。

他也不容易，要去理解每個系統(tǒng)的結(jié)構(gòu)和業(yè)務(wù)細節(jié)，已經(jīng)累成狗。效率低下尚且不說，這樣的折騰最后帶來了什么益處呢?

說實話，我現(xiàn)在回想起來，除了幾個變量命名我覺得 Scott 說的比較有道理以外，其他還真沒什么更有價值的東西了。

這里我想主要問題是因為 Scott 不在執(zhí)行團隊內(nèi)部，他不了解細節(jié)，所以也很難給出有價值的輸入。

很多東西，我們認為“他不懂”，也就是他的方案不能讓我們信服，自然，合作起來就很困難。

很多人喜歡拿建筑架構(gòu)和軟件架構(gòu)做類比，認為既然建筑需要建造師，那么軟件也應(yīng)該需要架構(gòu)師。Too simple，too naive!

其實，二者除了都需要有圖紙，都有藝術(shù)的成分之外，并沒有多少共同之處。

首先，建筑和軟件不同。

建筑的標(biāo)準(zhǔn)性、確定性要比軟件高的多，而軟件的靈活性簡直是沒有邊界的，任何一個 function 都可以有無數(shù)的實現(xiàn)方式，沒有定式。

因此，軟件架構(gòu)圖的約束力，要遠遠低于建筑圖紙的約束力。建筑如果不按照設(shè)計來，你就不能實現(xiàn)其功能。而軟件設(shè)計文檔和代碼，完全可以是兩個平行宇宙。

其次，建筑工人和程序員不同。

程序員的工作絕對不僅僅是“搬磚”這么簡單，軟件設(shè)計是一個充滿挑戰(zhàn)的創(chuàng)造性工作。

它需要對各種微妙之處進行權(quán)衡，只有深入其中，hands-on coding，才能真正的發(fā)現(xiàn)問題。

因此，飄在開發(fā)團隊之上，指手畫腳的 PPT 架構(gòu)師，注定是很難成功的。

為什么架構(gòu)部門不 Work?

如果說架構(gòu)師是輕量級解決方案的話，那么，還有一個“大規(guī)模殺傷性武器”就是設(shè)立一個專門的架構(gòu)組織。

幾年前的 B2B 就有一個這樣的架構(gòu)組織。我記得在當(dāng)年的“架構(gòu)圖”KO 會議上，當(dāng)時的負責(zé)人要求我們畫架構(gòu)圖，我就質(zhì)問他這個架構(gòu)組存在的意義是什么?

如果只是畫架構(gòu)圖，給老板當(dāng) PPT 用的話，這個圖我不愿意畫。我當(dāng)時還嚴厲的說了句名言——KO 不一定要 Kick Off，也可以是 Kick Out。

不止于此，而后我又“上書”到當(dāng)時 B2B 的 CTO，再然后，隨著 CTO 的調(diào)離，架構(gòu)負責(zé)人的離職，也就沒有然后了......

實際上，“架構(gòu)圖”這種務(wù)虛活動還好，雖然無用，但也構(gòu)不成殺傷。真正構(gòu)成殺傷的是架構(gòu)組織不甘無為，挖空心思要“做事情”。

可以說，在業(yè)務(wù)技術(shù)部門，架構(gòu)組這種“想做事”的行為是很危險的，事情越大，殺傷力越大。

何出此言?我們不妨先來看一下，在業(yè)務(wù)技術(shù)部門，架構(gòu)組織能做什么?

①業(yè)務(wù)架構(gòu)?

我是營銷域的，是訂單域的，是商品域的，是供應(yīng)鏈域的... 你架構(gòu)組告訴我，你對業(yè)務(wù)領(lǐng)域，業(yè)務(wù)流程，業(yè)務(wù)細節(jié)的理解比 PD、運營、工程師更懂?

恐怕難，一個合格的 PD 應(yīng)該能做好業(yè)務(wù)領(lǐng)域的抽象和業(yè)務(wù)流程的抽象，至于細節(jié)，好像沒有人比一線開發(fā)更懂。架構(gòu)組，卒!

②應(yīng)用架構(gòu)?

需求相對清晰之后，我一個在應(yīng)用架構(gòu)領(lǐng)域尚且有一些影響力的 TL 在和團隊討論邊界劃分，設(shè)計方案的時候，時常會爭論不休。

你一個架構(gòu)組的“外人”想來指手畫腳?呵呵，你這是有多低估程序員的自尊心啊。架構(gòu)組，卒!

③技術(shù)架構(gòu)?

好吧，那我們架構(gòu)組回歸技術(shù)本身，做點純技術(shù)的事情總可以吧。對不起，但凡有點價值的技術(shù)中間件，已經(jīng)有中間件團隊在做了。

還記得，ICBU 架構(gòu)組搞的 Hilton 容器和 AE 架構(gòu)組(中間件團隊)的“我行我素”使用 Spring Boot 嗎?

這種重復(fù)造輪子完全沒有必要。在云原生成熟之前，PandoraBoot 就是最好的解決方案。架構(gòu)組，帶著整個 BU 一起——卒!

在此我想稍微提一下支付寶的中間件團隊(架構(gòu)部門?)，我不知道歷史，也許 TecFin 的確是有其特殊性。

但是，從整個集團角度來說，我認為統(tǒng)一的技術(shù)中臺，應(yīng)該是更好的做法。

對一個企業(yè)來說，也許在某個特殊階段，的確需要實體架構(gòu)組織去保障落實架構(gòu)工作。

但大部分情況下，特別是在技術(shù)體系已經(jīng)相對完備的情況下。比如在阿里，業(yè)務(wù)技術(shù)部門，最好是不要在 BU 內(nèi)設(shè)立專門的架構(gòu)組織。

相信我，在我的職業(yè)生涯中，看到過很多業(yè)務(wù)技術(shù)部門設(shè)立的技術(shù)架構(gòu)組織案例，基本都是以失敗而告終。

人人都是架構(gòu)師

架構(gòu)師不行，架構(gòu)部門也不行。那架構(gòu)的事情誰來做呢?看一下你座位左邊的，再看一下你座位右邊的，再看一下你主管.... 別看了，他們是要做，你自己也要做，人人都是架構(gòu)師。

首先，讓我們來看一下什么是架構(gòu)能力，我認為廣義的架構(gòu)能力，應(yīng)該是一套分析問題、解決問題的方法論。

它需要你具備洞察問題本質(zhì)要素，理清要素之間的關(guān)系，以及制定相應(yīng)策略的能力。

??

從這個視角出發(fā)，我認為架構(gòu)能力就是核心競爭力，每個工程師都應(yīng)該具備一定的架構(gòu)能力，人人都應(yīng)該是架構(gòu)師。

怎么理解?我認為有如下三點：

①作為技術(shù)一線員工，也許你的工作時間并不長，架構(gòu)能力相對較弱，沒有捷徑，學(xué)習(xí)學(xué)習(xí)再學(xué)習(xí)，成長成長再成長，架構(gòu)作為能力是可以習(xí)得的，沒那么高深。

②作為技術(shù)團隊 Leader，你必須要具備一定的架構(gòu)能力了，不管是業(yè)務(wù)架構(gòu)還是應(yīng)用架構(gòu)。

TL 都應(yīng)該具備能發(fā)現(xiàn)問題里的本質(zhì)要素，以及理清要素之間關(guān)系的能力。如果你已經(jīng)是一名 TL，然而架構(gòu)能力還比較欠缺，則需要盡快去補足。

不足沒有關(guān)系，有關(guān)系的是停止了學(xué)習(xí)和成長。就像懷素說的，很多后勁不足的人主要是過早的停止了學(xué)習(xí)和成長，你的能力應(yīng)該是圍繞著你的層級震蕩的，這個震蕩范圍偏差不會太大，遲早會歸于一個相對合理的區(qū)間。

③作為 CTO(沒吃過豬肉，但看過豬跑)，CTO 沒得選了，必須是一個非常、非常優(yōu)秀的架構(gòu)師才行。你不僅要熟悉業(yè)務(wù)架構(gòu)，精通技術(shù)架構(gòu)。

更重要的是因為屁股問題(康威定律)，你還要去設(shè)計組織架構(gòu)，讓生產(chǎn)關(guān)系適應(yīng)生產(chǎn)力的發(fā)展。唯有如此，技術(shù)才能穩(wěn)定高效的支撐業(yè)務(wù)發(fā)展。

聽說，騰訊沒有 CTO，所以他們每個 BU 都有一套自己的技術(shù)棧和中間件，大家各自為政。

??

如果上圖對騰訊的架構(gòu)描述屬實的話，我覺得最好他們還是要有一個 CTO 比較好。

因為很明顯，對于通用的技術(shù)解決方案，比如大數(shù)據(jù)處理，技術(shù)中間件。沒必要重復(fù)造輪子，復(fù)用很明顯是更加科學(xué)的做法。

在這一點上，如下圖所示，我認為阿里無疑是走在騰訊前面的。其中，數(shù)據(jù)中臺和技術(shù)中臺，我認為是阿里做的最好，也是最 NB 的地方。

至于業(yè)務(wù)中臺為什么旁邊飄著一朵小烏云呢，這是因為業(yè)務(wù)的抽象復(fù)用要比技術(shù)的抽象復(fù)用難的多的多的多，不同業(yè)務(wù)面臨的業(yè)務(wù)問題的差異是巨大的，而不同業(yè)務(wù)面臨的技術(shù)問題相對業(yè)務(wù)問題，要穩(wěn)定的多。

我想，這也是為什么技術(shù)中臺已經(jīng)成功，業(yè)務(wù)中臺還在探索的原因吧。

??

如何踐行

最后，分享一下我是如何在團隊做“架構(gòu)師”的。

一方面，我會不遺余力的培養(yǎng)團隊成員的架構(gòu)能力，我會不斷的和他們探討系統(tǒng)的邊界是否合理，模型抽象是否合理，流程抽象是否合理，模塊設(shè)計是否合理。

并要求他們說清楚設(shè)計背后的思考和理念是什么，然后用我自己的方法論、思考和他們?nèi)ヅ鲎玻@樣反復(fù)進行，我和團隊都會有所成長。

另一方面，我會 hands-on coding，參與核心業(yè)務(wù)邏輯的編碼工作，這點很重要。

一定要深入代碼細節(jié)中去做架構(gòu)，因為很多問題只有在 Coding 的過程中才會暴露出來。

另外，無謂的討論是低效的，驗證架構(gòu)是否合理的方式，就是結(jié)合業(yè)務(wù)場景，寫代碼去驗證。

設(shè)計是否合理，是否優(yōu)雅，在 Coding 的過程中，便能獲得很好的反饋。我不止一次，在寫代碼的過程中，去重構(gòu)原來的設(shè)計，甚至是完全推翻重來。

總而言之，架構(gòu)作為一種能力，作為我們工程師的核心成長目標(biāo)，值得我們?nèi)プ巫尾痪氲淖非?。而架?gòu)師作為一個職位，在大部分情況下，它就是個“呵呵”。

作者：從碼農(nóng)到工匠

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號從碼農(nóng)到工匠(ID：craftsman_frank)

??