在SDCC2016的架構師進階之路主題，我分享了《老曹眼中的全棧架構師》話題，會后在csdn博客發布了同名文字，在我的公眾號（wireless_com）發了《全棧的技術棧設想》。然后，有幸得到了中生代技術（freshmanTechnology）和多人的轉載，中生代技術還專門開通了全棧架構師深度討論群,引起了很多的爭論和爭議。

主要分為以下三種觀點：
1）根本沒有意義，純屬忽悠
如網友回復：“鬼都知道說的什么 數據 緩存 業務 性能 消息隊列 操作系統 產品 云存儲 大數據這些高大上的名次，天天聊天就討論這些高大上的名稱， 然而并沒有什么卵用。”

2）有可能，但參考意義不大
有網友回復：“個人覺得不值得推崇，很多程序員為了全棧，東一榔頭西一棒子，結果啥都沒搞好”

3）表示贊同，具體實踐待推敲
如網友@張真Alex 的說法：“比較認同全棧架構師，從前ibm把架構師分為六大類，是六脈神劍各使一劍，而如今，不管是工程師還是架構師都應該有全棧的思維（不一定全棧的技能），特別是架構師的職能，需要從業務，技術體系，端到端都具備相當的戰斗力才行”

如此多的爭議并不意外，事情越辯越明，在此分享一下那篇文字的初衷和自己的重新思考。本著科學的態度，討論的前提應該是對問題明確，基本概念的定義是一致的，對不同邏輯推理得到的結果進行討論。針對全棧架構師這一命題，個人覺得先要明確幾個概念。

什么是架構？什么是架構師？
架構的定義業界一般有三種方法，一個定義為決策過程，一個定義為體系結構，還有就是兩者兼而有之。 Simon Brown 在《software architect for Developers》一書中嘗試給出了架構一詞作為名詞和動詞的定義，并嘗試給出了架構的分類。好友@溫昱在《一線架構師實踐指南中》嘗試給出了軟件架構的方法論ADMEMS即所謂的5視圖方法。然而，Len Bass 在《軟件架構實踐（第2版）》中談到“軟件架構在不斷發展，但它仍然是一個尚不成熟的學科”。

    歷史是任人打扮的小姑娘，類似的， 每個人對架構和架構師都有著不同的理解。螞蟻金服@右軍（公眾號：流浪部署我的初衷）有一篇文章《談架構》有著自己對架構的看法： ''' 架構是一種思維模式。架構師是一個title。為什么說架構是一種思維模式呢，小到一個模塊，大到一個平臺，都是一樣樣的。 軟件架構的作用包括:

軟件架構能夠滿足系統的品質

架構設計使受益人達成一致的目標

架構設計能夠支持計劃編制過程

架構設計對系統開發的指導性

架構設計能夠有效地管理復雜性

架構設計為復用奠定了基礎

架構設計能夠降低維護費用

架構設計能夠支持沖突分析

...
'''
其中有很多有價值的觀點，感興趣可以參考這篇文章。

在前當當架構部總監@史海峰看來，架構師首先是一個工程師，就如同在一些傳統行業里，有總工程師、總設計師的說法。他把架構師的定義總結為七句話：
NO.1 以工程思維全面理解業務需求
NO.2 基于模型和基礎模式抽象簡化
NO.3 提出恰當可行的整體解決方案
NO.4 在限定資源范圍完成明確目標
NO.5 滿足業務需求且保證系統質量
NO.6 在可預見的周期內具備擴展性
NO.7 并在系統生命周期內持續演進
在@史海峰看來，不同架構師擅長的技術領域或有不同，但大家有共通的拿手絕活，那就是“快速切入、解構拆分系統模塊和代碼、有技術話語權”。這些絕活并非一蹴而就，而是架構師們日常工作中，不斷地去發現問題、思考解決、設計取舍、重構迭代、協作傳道、響應支持，持續學習進步達成的。并非所有公司都需要招架構師，只有當系統復雜達到某個程度，幾個高級工程師一起難以很快說清楚的時候，就需要架構師加入了。架構師有兩忌兩宜。兩忌分別是不應過于追求高大上，否則可能會和現有團隊脫節，難以落地；技術上不應過于求全面，以能解決當前問題為主。兩宜則是團隊協助溝通能力要好和適應性強。

    對于架構師，不同公司有不同的定義和解讀，我覺得我們是幸運的，因為我們在實踐著一種動態且沒有成熟的技術，可能創造著一個新的團隊角色甚至工種。

什么是全棧工程師？什么是全棧架構師？
對于全棧工程師，引用一個不權威的說法，百度百科中對全棧的描述是這樣的：

全棧工程師，也叫全端工程師(同時具備前端和后臺能力)，英文Full Stack developer。是指掌握多種技能，并能利用多種技能獨立完成產品的人。

根據自己的經驗體會，全棧工程師在很多時候， 是為了夢想的苦命碼農的無奈選擇。其實，大公司也需要全棧的。我最早了解這個詞，是從一個facebook那里的朋友知道的。
全棧，不是全能，和所選擇的技術棧甚至業務棧相關。例如以LNMP（Linux ＋ Nignx ＋ MySQl＋ PHP），那么掌握了這四種技能，算不算一個全棧工程師呢？個人覺得可以的。但是隨著技術棧的變化，例如引入了緩存Memcache乃至其他分布式緩存，那原來的全棧工程師還是全棧么？全棧是否要隨之變化呢？
隨著業務和技術棧選擇的動態性變化，能否在團隊中有一角色能夠相對系統地對架構有個動態的設計，使我想到了“全棧架構師”這個詞，這就是我引入全棧架構師的一個原因。同架構師和全棧一樣，全棧架構師更不好定義，甚至可能錯誤地導致全棧就是全能的說法。
網友@張真Alex 認為全棧架構師最好是T型人才。
一豎的部分包括：
專業知識（應用，系統，安全，運維等），

戰略分解（抽象，分類，算法），

調研選型（目標識別，快速學習，調查方法，可行研究）

hands on（精通1-2語言，大量代碼實踐，設計方法等）

一橫的部分包括：
leadership（號召力，決斷力，mentorship）

項目管理（項目計劃，風險控制，取舍權衡）

領域知識（行業知識，行業生態）

創新思維（應用創新，跨界思維）

突破能力（經驗沉淀，覺一反三）

溝通協調（主動溝通，靈活協調）

這一橫一豎才構成了架構師（技術專家）的能力圖譜，他認為可算全棧架構師。我覺得這是非常有益的探討，很遺憾，我還沒有能力給出全棧架構師的完整而又清晰的定義，邊界也不好界定，但是，我覺得我們都在探索的路上。

為什么需要全棧架構師？
大家普遍認為，團隊需要深入業務，理解業務的發展，搭建核心架構，理清技術架構的細節和門檻，實現架構的迭代資源，掃清技術疑點和難點的人；需要把握好非功能需求的6種類型(功能性、可靠性、易用性、效率、維護性、可移植性)的人；....
那么，全棧架構師能夠滿足我們的哪些需求呢？我在《老曹眼中的全棧架構師》中談到了4個自己認為的典型場景：

1） 性能瓶頸，業務系統是很復雜的，不管是什么量級的業務系統，當出現性能瓶頸的時候可能一個人解決不了，如果你能夠貫穿所有被使用的技術棧，就能相對很容易地知道哪一點出現了問題。
2）溝通，前后端工程師，尤其是、各個跨語言前后端工程師之間的溝通是存在障礙的，全棧能夠做好溝通的橋梁。
3）救火，比如突然間夜里給你一個短信告訴你系統出問題，你可能當時找不到那個開發此模塊的工程師，怎么辦？系統還能不能運行？業務會不會崩潰？如果崩潰，公司會遭受什么損失？這個時候就需要有全棧，他能夠在要在第一時間解決系統中的問題。
4）資源緊張，資源緊張更多存在于創業公司，我也在一些創業公司里做過事情。比如說我們想搭一個系統出來，沒錢、沒資源，這個時候，很多想法要訴諸實踐，一定要有全棧。
肯定還有其他的需求存在的，只是我可能沒有經歷過，或者是大家沒有關注過而已。

如果對全棧架構師的需求是存在，那么，如何才有可能成為一名全棧架構師呢？我試圖從技術棧，性能棧，和效率棧三個方面進行了探討，在《老曹眼中的全棧架構師》中有所描述，這里不再贅述。

我說過全棧架構師可能是自己的杜撰， 但是，全棧思維優先還是被大多數朋友認可的，實際上是一種大局觀，一個功能既可以前端又可以后端實現，利弊和方案的選擇是需要有全棧架構師的，至少要有全棧的思維。全棧的思維，簡單地可以理解成系統的思維方式。

全棧架構師是不是一個偽命題呢，是一個上帝類嗎？ 我不知道，我只是想說那篇文字，試圖明確：
什么是架構？什么是架構師？
什么是全棧？什么是全棧架構師？
為什么需要全棧／架構師？ 如何可能成為一個全棧架構師？

如果問題分為：已知的已知，已知的未知，未知的未知 的話，即便是將全棧架構師這一角色，從未知的未知變成已知的未知，我想也是一件好事情，能力所限，隨筆如上。

歡迎關注本公眾號：wireless_com

微信掃一掃關注該公眾號