聽說“全椕撸”這個詞枫耳，還是 2013 年的夏天乏矾，在 Coursera 的一門叫“Startup”的課程里見到的。那時樸靈的《深入淺出 Node.js》才出版兩年迁杨，全世界都在追求能跨所有端的開發(fā)能力钻心，前端、后端铅协、iOS扔役、Android，甚至數(shù)據(jù)庫警医，國內(nèi)甚至還未起步亿胸。

如果說一個人完成所有開發(fā)任務(wù)可被稱為全棧坯钦，那么早在單機(jī)時代、Java 時代侈玄，一切都不是問題婉刀。所以這不是新概念。全棧的出現(xiàn)處于 App 時代的末期序仙。也許很多人都讀過這樣一本書突颊，《App創(chuàng)富傳奇》(Appillionaires)，是那個時代非常棒的縮影：臥室創(chuàng)業(yè)潘悼，一兩個獨(dú)立開發(fā)者每兩三個月創(chuàng)作一款 App律秃，只要其中一款火了，瞬間成了百萬富翁治唤！可是 App 的技術(shù)體系已經(jīng)遠(yuǎn)比曾經(jīng)的單機(jī)應(yīng)用復(fù)雜棒动，在那樣的背景下，市場迫切需要支持一兩個人獨(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í)對于絕大部分市場需求而言舱殿，任何技術(shù)的入門教材足以應(yīng)付奥裸，畢竟能形成規(guī)模的產(chǎn)品少之又少。一時之間“全棧工程師”遍地開花沪袭，學(xué)習(xí)新語言湾宙、新技術(shù)框架的潮流不可阻擋。哪怕跟一個剛畢業(yè)兩三年的新手聊天冈绊，如果聊不出 Rust 和 Go 的區(qū)別侠鳄，似乎都是一件很沒面子的事情！

然而死宣，也就火了那么兩三年伟恶。

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

不被主流務(wù)實(shí)團(tuán)隊(duì)采納的主要原因师倔，更多的源于自身。全棧方案缺乏標(biāo)準(zhǔn)施绎、工程師水平難以評價溯革、費(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ì)個個都是會寫代碼的技術(shù)總監(jiān)俱尼，團(tuán)隊(duì)的管理、可持續(xù)發(fā)展萎攒、規(guī)模擴(kuò)張都很成問題遇八，現(xiàn)實(shí)中幾乎不存在。

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

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

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

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

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