聽說“全?！边@個(gè)詞，還是 2013 年的夏天，在 Coursera 的一門叫“Startup”的課程里見到的。那時(shí)樸靈的《深入淺出 Node.js》才出版兩年，全世界都在追求能跨所有端的開發(fā)能力，前端、后端、iOS、Android，甚至數(shù)據(jù)庫(kù)，國(guó)內(nèi)甚至還未起步。

如果說一個(gè)人完成所有開發(fā)任務(wù)可被稱為全棧，那么早在單機(jī)時(shí)代、Java 時(shí)代，一切都不是問題。所以這不是新概念。全棧的出現(xiàn)處于 App 時(shí)代的末期。也許很多人都讀過這樣一本書，《App創(chuàng)富傳奇》(Appillionaires)，是那個(gè)時(shí)代非常棒的縮影：臥室創(chuàng)業(yè)，一兩個(gè)獨(dú)立開發(fā)者每?jī)扇齻€(gè)月創(chuàng)作一款 App，只要其中一款火了，瞬間成了百萬(wàn)富翁！可是 App 的技術(shù)體系已經(jīng)遠(yuǎn)比曾經(jīng)的單機(jī)應(yīng)用復(fù)雜，在那樣的背景下，市場(chǎng)迫切需要支持一兩個(gè)人獨(dú)立構(gòu)建完整應(yīng)用系統(tǒng)的技術(shù)方案，也迫切需要具備獨(dú)立構(gòu)建完整應(yīng)用系統(tǒng)能力的人才，也就是傳說中的“全棧工程師”。

全棧所用的技術(shù)并不一定等于“H5 + Node.js”。有些工程師自學(xué) iOS、Android、Win Phone、H5，以及 Java、PHP、Python 中的一種，也能形成全棧開發(fā)能力。其實(shí)對(duì)于絕大部分市場(chǎng)需求而言，任何技術(shù)的入門教材足以應(yīng)付，畢竟能形成規(guī)模的產(chǎn)品少之又少。一時(shí)之間“全棧工程師”遍地開花，學(xué)習(xí)新語(yǔ)言、新技術(shù)框架的潮流不可阻擋。哪怕跟一個(gè)剛畢業(yè)兩三年的新手聊天，如果聊不出 Rust 和 Go 的區(qū)別，似乎都是一件很沒面子的事情！

然而，也就火了那么兩三年。

技術(shù)這件事，關(guān)鍵不在于能不能，而在于好不好，技術(shù)的品質(zhì)是通過產(chǎn)品體現(xiàn)的。做垃圾產(chǎn)品的不一定是垃圾技術(shù)，但絕大部分技術(shù)確實(shí)只能做出垃圾產(chǎn)品。如果一個(gè)工程師在過往的技術(shù)生涯中沒有做出過精品，可能是因?yàn)檫\(yùn)氣差；但如果連追求卓越的努力都看不到，那真的是沒有未來。所以我在面試中非常看中“追求卓越”的經(jīng)歷和心態(tài)。對(duì)于全棧也是如此，遍地開花的結(jié)果是嚴(yán)重拉低了下限，以至于讓很多人失去了信心。

不被主流務(wù)實(shí)團(tuán)隊(duì)采納的主要原因，更多的源于自身。全棧方案缺乏標(biāo)準(zhǔn)、工程師水平難以評(píng)價(jià)、費(fèi)力不討好，人效的提升建立在損失用戶體驗(yàn)的基礎(chǔ)上、通過擴(kuò)大單位工程師職責(zé)范圍和工作量來實(shí)現(xiàn)的。即便全棧團(tuán)隊(duì)在各方面都能達(dá)到與傳統(tǒng)團(tuán)隊(duì)比擬的技術(shù)標(biāo)準(zhǔn)，那樣的團(tuán)隊(duì)個(gè)個(gè)都是會(huì)寫代碼的技術(shù)總監(jiān)，團(tuán)隊(duì)的管理、可持續(xù)發(fā)展、規(guī)模擴(kuò)張都很成問題，現(xiàn)實(shí)中幾乎不存在。

技術(shù)圈一切的偏見與傲慢都源自一個(gè)簡(jiǎn)單的公式：ROI = 收益 / 成本。全棧要擠進(jìn)主流技術(shù)圈，必須解決這個(gè)公式衍生出的所有問題。

首當(dāng)其沖的就是系統(tǒng)復(fù)雜度。全棧是由于系統(tǒng)復(fù)雜度過高而催生的市場(chǎng)需求，卻并沒有很好的解決這個(gè)問題。系統(tǒng)復(fù)雜度大致可表示為：O(核心業(yè)務(wù)數(shù)量 x 技術(shù)棧深度)。 如果誰(shuí)還迷戀 20 年前的 BS 架構(gòu)，希望“瀏覽器、Web 服務(wù)器、中間件、數(shù)據(jù)庫(kù)”這種分層架構(gòu)能滿足互聯(lián)網(wǎng)業(yè)務(wù)需求，還是醒醒吧！如今的分布式系統(tǒng)技術(shù)棧已經(jīng)深得令人發(fā)指！全棧方案并沒有減少這些環(huán)節(jié)，要想構(gòu)建多復(fù)雜的系統(tǒng)就得做相應(yīng)多的事，這對(duì)于完全依靠自身力量從零構(gòu)建服務(wù)的團(tuán)隊(duì)來說是很難跨越的坎。所幸市場(chǎng)給出了一種解決思路，那就是把實(shí)現(xiàn)業(yè)務(wù)所需的技術(shù)棧盡可能擠壓到業(yè)務(wù)邏輯層，其他的一切技術(shù)環(huán)節(jié)都由基礎(chǔ)設(shè)施或者第三方服務(wù)商來提供，也就是 IaaS 和 PaaS。但是市場(chǎng)只是解決了各技術(shù)環(huán)節(jié)自身的復(fù)雜度，長(zhǎng)業(yè)務(wù)鏈條所面臨的復(fù)雜度問題依然維持原有的量級(jí)：每增加一條覆蓋全技術(shù)棧的核心業(yè)務(wù)鏈路，系統(tǒng)的配置項(xiàng)、測(cè)試項(xiàng)、監(jiān)控項(xiàng)等方面因素都會(huì)成倍增加。在這樣的情況下壓縮人力成本不太現(xiàn)實(shí)。

進(jìn)而衍生出系統(tǒng)可用性問題。業(yè)內(nèi)讓分布式系統(tǒng)長(zhǎng)鏈條業(yè)務(wù)可用性每提升一個(gè) 9 要付出的代價(jià)，堪比再創(chuàng)建一套等量的系統(tǒng)，甚至還要多。全棧方案縮減的成本反而很可能威脅到可用性。為什么這么說呢？可用性的提升一般分為故障感知和故障處理兩大部分。故障感知一般分這幾種境界：全靠用戶吼、基礎(chǔ)設(shè)施監(jiān)控、核心服務(wù)監(jiān)控、全鏈路監(jiān)控、終端用戶體驗(yàn)監(jiān)控；故障處理方式又分為被動(dòng)響應(yīng)式處理、主動(dòng)干預(yù)、自動(dòng)處理，故障處理手段根據(jù)影響的用戶范圍大小而定，從全局服務(wù)重啟，到局部服務(wù)重啟，乃至精確故障處理。從“全靠用戶吼的被動(dòng)全局重啟”到“基于全鏈路及終端用戶體驗(yàn)監(jiān)控的自動(dòng)化精確故障處理”，這中間所需投入的資源與系統(tǒng)復(fù)雜度成等比甚至指數(shù)級(jí)關(guān)系。全棧方案對(duì)此沒有應(yīng)對(duì)措施。好在 IaaS 和 PaaS 也能解決所負(fù)責(zé)技術(shù)環(huán)節(jié)的可用性問題，但是只是相對(duì)縮小了問題空間。

以及系統(tǒng)設(shè)計(jì)和終端用戶體驗(yàn)在業(yè)內(nèi)是一對(duì)互斥的技術(shù)能力，簡(jiǎn)稱前后端思維矛盾，然而在全棧里要做到面面兼顧，往往卻是顧此失彼。這些問題讓全棧方案在收益上大打折扣，成本的縮減并不能帶來 ROI 的提升，甚至很難滿足復(fù)雜系統(tǒng)高可用的基本需求。所以在滿足臥室創(chuàng)業(yè)的獨(dú)立開發(fā)者打造可演示的 Demo 之外，在創(chuàng)造不要求質(zhì)量的非關(guān)鍵系統(tǒng)之外，全棧幾乎沒有用武之地，注定邊緣化。

這篇文章不是為了給全棧致悼詞。任何困難都阻擋不住市場(chǎng)需求，全棧應(yīng)需求而生，也會(huì)有時(shí)來運(yùn)轉(zhuǎn)的機(jī)會(huì)。是的，時(shí)機(jī)很重要。人工智能幾十年來一直停留在實(shí)驗(yàn)室里，直到大數(shù)據(jù)時(shí)代讓深度學(xué)習(xí)成為可能。相信在不久的將來，一定出現(xiàn)新的技術(shù)體系來解決系統(tǒng)復(fù)雜度和可用性問題，從而消除其進(jìn)入主流技術(shù)圈的障礙。屆時(shí)全棧開發(fā)的主力很可能來自于現(xiàn)在的前端行業(yè)，因?yàn)橄到y(tǒng)問題終究是技術(shù)能解決的，而端的多樣性和環(huán)境復(fù)雜性，卻會(huì)持續(xù)相對(duì)更長(zhǎng)的時(shí)間，說不定會(huì)一直持續(xù)下去。