【干貨】誤解、狂妄、荒誕，全棧編程完全就是一場騙局？

  似乎在一夜之間，“全?！蓖蝗痪统蔀榱烁呷藲庠掝}，技術領域中的一切從業者似乎也對此坦然接受，不少程序員在面試時也會稱“我是個全棧程序員”來包裝自己，即便很多時候，他們并沒有完全搞清楚全棧到底是什么。 曾有多年CTO經驗的技術專家 Ted Gross 對于時下很火“全?！备拍畋磉_了自己截然相反的觀點：如果一家企業的目標是獲得商業成功，那么將“全?！睆娂釉诔绦騿T身上，將是一種可怕的誤解與愚蠢的錯誤;而有些程序員宣稱自己擁有全棧能力，這也是一種狂妄的表現。 Gross認為，全棧是荒誕不經的期望，甚至完全是個騙局，最終通向的也只有慘烈的失敗?！叭珬！备拍畹目焖佼惢c市場需求不無關聯，目前的行業傾向，正迫使一切不愿自稱“全?！背绦騿T的技術人難以找到理想的工作，而程序員們又需要這份工作。Gross呼吁企業和程序員以理智的方式認清并接受現實與局限，隨著企業在編程方面的需求越來越迫切，大家必須正視且明確自己對于程序員的期望。

  如果大家本身就是“全棧程序員”這種新式新詞匯所指代的群體中的一員;或者說雖然頭銜不這么說(你可以身為CTO、研發副總裁或者技術負責人等)，但確實在負責多種技術方案的管理工作，那我強烈建議各位拿點時間替自己、也替你所在的單位認真讀讀本文。另外，在這里我要強調一點，如果大家覺得這篇文章冒犯了你的專業，我首先表示誠摯的歉意。但在你憤而離席、甚至已經準備“問候”我個人之前，真的請你先按捺怒火，結合標題以及你自己對“全?！钡膽B度讀完整篇文章。這里，咱們先來點不那么刺激的，就從與全棧編程愿景相關的定義與認知開始談起。

  我也記不清“全?！边@個術語是從什么時候廣泛出現在編程社區當中的。不過在我看來，全棧這東西也會像其他很多曾經流行的術語那樣，隨著時間推移而很快淡出人們的視野。大家對“DevOps”這字眼肯定非常熟悉，它代表的是對不斷開發、籌劃以及生產周期的基本形式的概括。最近，“CI/CD”也開始流行起來。第一次看到它時，我感覺自己像個傻子，弄不清這到底是在說些啥。沒辦法，在查詢之后，我意識到它代表的是“持續集成/持續部署”…好吧，這個縮寫真的有種很搞笑的感覺。真的，這不就是DevOps嗎，為什么非得整個單獨的術語呢?除此之外，還有敏捷、Scrum以及Kanban之類，在我看來都是形式大于實質的典型案例?？偠灾?，全棧突然就成了高人氣話題，技術領域中的一切從業者似乎也對此坦然接受。

  反正一夜之間，我在采訪或者交流時，不少程序員開始認真地盯著我，然后說“我是個全棧程序員”。跟第一次聽到CI/CD時一樣，我會反問，“全棧是啥意思?”，之后就是他們對自己全棧能力的描(吹)述(噓)。不過，我發現很多“全?！背绦騿T其實弄不清下面這些問題：

  你說的“全?！笔鞘裁礂?你的公司正在或者打算使用的技術棧有哪些?

  你真的在實踐中同時使用Angular、Vue、HTML以及React，而且稱得上完全了解嗎?

  你能夠使用NodeJS、Java/Scala、C++、PHP、Python以及Golang進行后端編程嗎?你了解并且精通(請注意，不是簡歷上的那種“精通”)這些語言嗎?

  你了解JSON嗎?知道如何在深度嵌套時加以使用嗎?

  你了解AWS、Azure以及其他組件選項嗎?你又是否了解EC2、NAT網關乃至AWS提供的其他超過1000種可選模塊?

  你是Redis及Memcached領域的專家，并很清楚如何設置并正確使用Redis系統嗎?你知道Redis最適合應用于哪些場景嗎?

  你同時了解iOS與Android原生開發，而且能夠通過React實現非原生開發嗎?

  你了解SQL與NoSQL嗎?你知道二者之間的區別，以及如何進行操作嗎?你了解MySQL、Postgre/Postgres SQL、MongoDB、Hadoop、Cassandra以及Apache Spark嗎?

  更重要的是，你知道如何保護自己的數據——包括靜態數據與傳輸數據——嗎?

  我可能確實有點刻薄，反正交流的時候我就這樣不停地提問，完全不需要等待答案。而且相信大家也完全能夠輕松把這些問題擴展到幾十上百個。任何敢于全面給出肯定答案的家伙，要么是傻子，要么就是騙子。即使如此，我們到底在聊什么“全?！?首先，請先給出關于全棧的明確定義。反正我是不知道這幫人說的“全?！钡降子卸嗳?。

  為了理解什么是真正的技術棧，我們先以技術領域當中常見的兩個簡單相關縮寫詞說起。技術人員都聽說過“LAMP”棧與相對較新的“MEAN”棧。其中LAMP代表的是Linux、Apache、MySQL以及PHP。而MEAN代表的則是MongoDB、Express、Angular以及NodeJS?？梢钥吹?，MEAN棧當中包含負責前端開發的Angular，LAMP棧中則沒有。

  毫無疑問，如果從這個角度來講，目前存在的堆?？赡苡袛蛋賯€之多。所有這一切，都是為了識別并闡述特定項目所需要的技術方案而建立。這些詞匯只負責定義技術，而沒有特別的意圖，也決不應該利用他們來定義某一名程序員在特定工作中的實際資質。到這里，我就要正式拋出本文的核心觀點了：如果你的目標是獲得成功，那么將“全?！睆娂釉诔绦騿T身上，將是一種可怕的誤解與愚蠢的錯誤。

  誤解

  我覺得我們很難把“全?！本幊踢@種說法的出現，歸結于某一個具體的原因。在這里，我只能提出一些理論與假設，盡可能把它們混合起來，然后做出更合理的猜測。我認為最有可能的原因，就是全棧這一理念始于良好的愿望。以程序員為載體將一種專業同另一種專業結合起來，確實是種合乎邏輯的思路，而且也有不少優秀的程序員確實有能力勝任多種技術處理方式。然而，正如其他很多事物一樣，“全?！备拍钜部焖佼惢?，如今成了一個籠統的術語，指在廣泛的技術層面當中擁有大量專業知識。這是一種誤解，但卻稀里糊涂成了最近不少人看待編程工作時的一種預期與要求。下面，我將提出幾點背景驅動因素：

  **1. 資金有限 。**實際上，預算是有的。畢竟無論是在初創企業中還是大型公司內，預算都會有一個具體的數額。只有明確了預算，我們才能確保燒錢的速度不會讓整個組織失控，而且公司能夠在全周期之內逐步消化可承受的成本。這是一項基本的經濟學原理，所有不尊重這項原理的家伙都已經在現實中受到了殘酷的懲罰。因此，既然一個編程團隊當中，每個人都只是一到兩個方面的專家，為什么我們不干脆只請一位能夠搞定一切的大拿呢?聽起來有道理吧，所以“全?！本瓦@么誕生了。畢竟，很多企業都要求其CTO親自動手參與工作——或者說是兩份工作，一份是管理技術人員，另一份是實際編程。在這樣的背景，將各種“專業知識”整合到同一個崗位當中也將順理成章。這確實能夠節約資金，并且通過團隊的小型化與緊密化帶來其它一些優勢。

  2. 給編程團隊當替補 。 我要強調的另一個重點在于，如果某位程序員生病或者離職，在真正的“全?！杯h境中，其他程序員應該能夠輕松接替，直到公司找到合適的新員工。畢竟，既然每個人都擁有“全?！蹦芰?，那他們就都應該掌握其他人掌握的知識。換言之，每個人都是全方位的專家，那也就不需要針對某一方位聘用專家了。

  **3. 對需要多少知識一無所知 。**最近，我跟一位新晉研發副總裁進行了一場開誠布公的交流(面試)，他讓我談談對于“全?！背绦騿T團隊的想法。我回以一個問題，“棧是什么?”他說，大概就是MongoDB、React、NodeJS堆棧，其中包括對微服務、Lambda以及其他AWS技術的使用。我想了一秒，意識到直話直說很可能會毀了我的這次面試機會。但對我來說，殘酷的真話總比甜蜜的謊言要好。所以我問這位副總裁，他自己是否真的知道自己對程序員提出了怎樣的要求。 展開來談，他提出的要求可以分為以下幾個部分：

  **a. 他們必須了解并精通NodeJS。**雖然目前人氣極高，但NodeJS并不只是JavaScript的一種擴展，而是一種具有眾多可能性與中間件的新語言，要求程序員對同步與異步編程擁有深入的理解。而正確實現微服務這一要求的存在，又把門檻提升到了新的高度——程序員必須真正理解NodeJS的工作原理及其在編程結構中的作用，同時非常明確應該做什么、不應該做什么。

  **b. MongoDB并不只是一套NoSQL數據存儲系統。**很多人可能沒有意識到，單是MongoDB自身就包含超過200種可行的語言調用。它還要求程序員深刻理解數據結構，因為其并不屬于傳統的關系數據庫。(即使是在SQL系統當中，也需要一名嚴肅的數據管理者專門負責數據結構問題。)另外，MongoDB以及任何其他NoSQL系統也對非結構化數據的相關知識提出嚴格要求。這本身就是一門科學。復制和分片呢?索引使用呢?何時使用map reduce以及其他技術概念?這些都是非?，F實的問題。

  **c. 接下來是AWS。AWS當中包含大量技術成果，Lambda正是其中之一。**Lambda目前已經相當流行，但如果未能正確實施，它很快就會成為企業面臨的一場噩夢(特別是在成本層面)。更重要的是，AWS由無數此類即服務選項組成，目前簡單的AWS堆棧就包括實例、NAT網關、S3的使用以及其他AWS服務。單是這一點就是一項艱巨的任務，而且極易陷入失控。

  **d. **我還在回答中加入了其他一些重要，但對方并沒有提到的元素。何時何處使用Redis?如何使用?如何專業地操作Redis本身及其數據?

  **e. 由誰來負責數據安全?**數據安全本身又是另一項重要的全職工作，而且在開發周期中經常遭到忽視，這非?？膳?。

  f. 如果這還不足以說明問題，或者說不足以證明一個要求程序員掌握上述一切技能的招聘者本身已經精神錯亂，那我們再來聊聊前端。這樣的招聘要求，其實就是認定會有人熟練掌握了所有這些技能，同時還能夠使用標準的UI與UX方案構建起像樣的前端。即使不使用難度相對較高的React，換成Angular或者Vue，我仍然覺得這事沒戲——完全沒戲。我不在乎大家去吹什么全能大神，我就是不信。

  說到這里，相信大家應該已經很清楚，任何“堆?！倍伎梢苑纸獬蓭讉€相關度最高的明確部分。一旦認真完成了堆棧拆分，我們就會意識到其中需要什么知識、不需要什么知識。期望一到兩名“全?！背绦騿T能夠吃透這一切，或者至少對其擁有全面的了解，根本就不切實際。

  g. 完全就是狂妄的表現 。沒錯，我承認某些堆棧(例如WordPress以及Wix等)可以由一個人搞定。但是，就個人經歷來看，任何宣稱自己擁有全棧能力的程序員或者CTO，至少都強調過自己精通多種編程語言、前端以及數據庫結構(SQL與NoSQL混合使用)。這完全就是狂妄的表現。

  現實

  現實情況非常簡單。俗話說“獨木難支”，好吧，這應該是個成語。反正有些事情一個人就是干不了，這跟業務能力無關。當然，跨界人才是客觀存在的，也確實有極少數的從業者能夠同時做好幾個方面的工作，但這些人開出的薪酬要求，絕對高于企業愿意支付的水平。

  同樣是現實情況，在討論“全?！敝?，大家首先得定義堆棧里到底包含哪些內容。如果我們繼續聊之前的這個示例，如果NodeJS程序員需要同時負責MongoDB設置工作，他們了解安全需求嗎?我在現實生活中乃至網上看到過無數完全沒有安全性可言的MongoDB設置結果。另外，這些程序員知道該如何在數據傳輸過程中采取必要的安全措施嗎?他們會理解bCrypt與crypto之間的區別嗎?這樣的問題還可以無限延展，而且我們姑且假設有人能夠做到。那前端呢?他們還得開發出一套完整的前端(移動與Web)，且同時符合以上要求——這可能嗎?

  現實情況是，成功的團隊當中，每個人都應各司其職?？v觀所有堆棧，大家可以按照主要功能將其劃分成三大類：

  前端

  后端

  數據庫

  現實情況是，專業知識之間彼此交叉。我們需要定義某些參數(特別是與JSON相關的參數)，需要發送哪些參數，以及在必要時應在哪一側執行計算。

  現實情況是，隨著企業在編程方面的需求越來越迫切，大家必須進一步明確自己對于程序員的期望。簡單上傳一份招聘啟事，在其中列出一長串語言、技術與要求，然后將職位描述成“全棧程序員”根本就無濟于事——也有點作用，證明企業本身根本就不知道自己在說什么。這是種危險的跡象，大家應該將其視為警報，意識到公司并不清楚自己需要哪些專業知識以及如何借此實現商業成功。

  現實情況是，你和你的企業需要準確定義所需要的技能內容，需要向其他程序員提供哪些支持，以及如何在可行的預算范圍之內開展工作。不管怎么做，我可以向大家保證，請一位能夠身兼編程工作的CTO再加兩名“全?！背绦騿T，不可能幫你實現這個目標。

  現實情況是——請以理智的方式認清并接受現實與局限。

  荒誕

  你會聘請一位了解Python的程序員擔任數據科學家嗎?我真心希望大家給出的答案是“否”。為什么?很簡單，我們都知道數據科學家擁有自己的一套特殊技能組合，而Python或者Java/Scala只是其中的一小部分。那么，為什么你會考慮一位只能說對NodeJS稍有了解的程序員來構建整個前端、后端以及數據庫系統?這顯然不是錯誤，而是荒誕了。

  但是……但是……我們還要測試呢!沒錯，肯定會測試。面試人員通過了Python測試、NodeJS測試、數據庫測試甚至是一些簡單的前端系統測試。這一個表單、那一道試題、再加個響應站點——當然，最后的結果就是你找到了一名出色的“全?！背绦騿T。他們如此出色，即使你在測試中改用Golang或者Java，他們也能順利通過。

  那么iOS原生程序員呢?如果他們既能開發iOS應用，又能開發Android應用，那不是更好?當然更好嘍!他們肯定能夠弄清兩套系統中的所有細微差別，包括往來于后端當中的數據，這還能有多難，對吧?

  順著這個思路，負責管理后端的程序員肯定也能夠搞定整個數據與安全系統。畢竟這也是他們工作中的一部分嘛。

  簡單的算術結果告訴我們，只需要兩名程序員就能完全五份工作。這樣，預算空間就顯得更充裕啦，公司也絕對會因此而快速發展、騰飛?！叭珬！钡恼T惑其實就是這么來的。但是，在實踐當中，各位會慢慢體會到，這只是一種荒誕不經的期望，通向的也只有慘烈的失敗。如今，憑借著令人難以置信的IDE與其他開發工具，程序員應該能完成一切拋來的任務了吧?錯!動動腦子，這現實嗎?

  打個比方，這就好像指望出任CTO的技術管理者同時身兼COO與CFO職務一樣。任何腦袋還正常的人都不會想出這樣的主意。那為什么一到了開發層面，程序員就得面對這樣的要求?一言以蔽之，永遠不要指望“全?！背绦騿T能夠了解一切并精通一切。

  失敗的序幕

  致屏幕前的所有“全?！背绦騿T：

  在對本文表示憤怒、反感或者漠視之前，請先閱讀以下部分。我把我的觀點表達明確，接下來我會虛心接受大家的反饋。

  問題不在大家身上。目前的行業傾向，正迫使一切不愿自稱“全?！背绦騿T的技術人難以找到理想的工作。市場對“全棧程序員”的需求正在迅猛增長，而我們又需要這份工作……還能怎么辦?大家別無選擇，只能宣稱自己擁有“全?！奔寄懿⒃诒车乩飷貉a那些自己還不熟悉的知識。

  然而，這種期望本身必然帶來失敗的結局。我們只能在某些方面成為專家，而不可能在所有領域都有所建樹。被迫鉆研自己較為薄弱的技術方向，會給我們帶來巨大且不必要的負擔，同時擠占自己在真正擅長的領域投入的學習時間。技術系統每3個月更迭一次，對于任何從業者來說，我們都幾乎不可能跟上所有語言的發展變化。再結合“全?！边@個玩笑一樣的背景，死定了，不可能有別的結果。

  但是，有些朋友還是要堅持：“我就是全棧程序員。這些我全都懂，我全都能搞定。醒醒吧，全棧是一種歷史趨勢，不承認也沒有用?！?

  老哥，我勸你醒醒才對。這里我就是要把難聽的話說出來——全棧編程完全是個騙局。最后，你只會什么都懂一點，什么都不精通。這時候，如果你的數據庫無法返回正確結果，你的后端無法執行正確的計算，或者你的前端沒有顯示正確的數據，或者你的系統遭到黑客入侵甚至破壞，猜猜鍋會甩到誰的身上?畢竟你可是全棧程序員啊，全棧背鍋是跑不掉的!

  至于業務價值，有些企業為什么能獲得成功?就是因為他們很清楚，堆棧中的每個部分都需要專業知識與掌握這些知識的專業人士。而某些企業之所以陷入困境甚至是惹火上身，正是因為他們指望自己的程序員精通一切并能夠處理整個堆棧中的所有組成部分。

  前端程序員就不應該在數據庫結構和信息層面硬摻一腳。后端程序員也不要胡亂插手前端開發的事。在當今時代，也只有真正了解完整背景信息的專家，才能有效解決安全問題。

  誠然，某些技術確實可能或者可以合并在同一個工作崗位當中，但這并不代表這個崗位需要的就是一名所謂全棧程序員。這只能代表大家擴展了自己的專業知識，因此能夠在更大的專業背景之下更好地完成工作。

  請遠離“全?！闭T惑。知道自己知道什么，也應該知道自己不知道什么。我很喜歡這句話，也在這里把它送給大家?！拔也恢馈?，這是一句很有力量的話語。別再形勢的壓力下自欺欺人，否則最終的代價仍將落在我們自己身上。