原文:https://blog.csdn.net/tTU1EvLDeLFq5btqiK/a...
大廈新搬進來一家創業公司，老闆紅光滿面地提著果籃上樓拜訪，說是剛拿到了投資人的錢，正準備擴充團隊大幹一場。那個時候的他躊躇滿志，顧盼生輝。當時我想，能在這個大環境下拿到投資的公司，做的產品應該是有前景的。
沒想到幾天後在電梯遇見時，卻發現這位老闆已經沒有了往昔的風采，整天愁容滿面。他在電梯看到我以後問道：“我記得你們是做技術媒體的吧，有個問題想請教一下。”
原來他煩心的癥結在於：
我們公司拿到投資以後，人員配置到位還算及時，業務擴張的速度還是挺快的。沒過多久我們技術團隊的人就跟我說，現在業務發展勢頭比較好，現有的技術架構快扛不住了，得招些技術牛人來團隊負責整體架構規劃、升級。
我不是搞技術出身的，以前總是在各種論壇上聽說阿里巴巴的 P8、P9 多牛逼，技術多厲害，我就想這種級別的程式設計師應該可以滿足我們的需求吧。於是我用年薪百萬的 offer 砸了個阿里新升的 P8 來我們團隊做 CTO，可是現在問題不僅沒得到解決，反而更復雜了。技術團隊的人覺得他名不副實，他覺得我們找他來是打雜的，幹得也不開心，兩頭亂
我問他，你們覺得他哪裡不好？
他只會寫 Java，我們用 Go；
他只會搞後端，前端基本不懂；
他演算法不太行，我們要做推薦；
他只會寫 Web，我們要做 App；
他只曉得用開源工具，我們要造自己的輪子；
…
“那等於是他哪哪都不如你們意唄？”我問他。
對啊，我也沒想到阿里 P8 這麼水。
“可你一開始要招的不是可以給你們重構系統架構、償還技術債的 CTO 嗎？”
這……有啥區別嗎？
“區別大了。你這又是要讓前端後端都會，又是要精通各種程式語言，還要能搞移動開發，你這想要的是個全棧，而不是 CTO。哪有 CTO 幹這些活兒的，你這是想讓一個在大廠流水線上擰螺絲的人來給你把每個窟窿都堵上，不可能啊。”
合著我錢白花了唄？
“倒也不是白花了，BAT 這些大廠都有一套流程化的線上線下、開發管理機制，一般能升到 P8 的，碰到水貨的可能性相對較小。你的問題是需求跟招聘方向不匹配，你要招的這是全棧工程師，人家大廠的技術專家是流水線作業，差別大著呢。你聽我跟你分析分析。”
軟體工程作為一個行業，發展至今已經有超過 50 年的歷史。軟體開發在網際網路的數次浪潮沖刷下，已經是一個非常完備的成熟行業。在一線網際網路公司，比如矽谷的 Google、Facebook、Amazon，比如中國的阿里巴巴、百度、騰訊等，其軟體開發已經是一個成體系的流水線式作業。
就以前文提到的阿里巴巴為例，作為國內最有代表性的網際網路企業之一，阿里巴巴的軟體開發已經形成規模化的效應，直接體現在軟體開發的模式上就是一條完備的流水線式作業。
流程化、規範化是大廠軟體開發最大的特點。一次完整的需求開發流程是這樣的：
- 需求預審、評審；
- 概要設計與評審；
- 測試用例撰寫與評審；
- 開發；
- 測試與 bug 修復；
- 釋出；
- 版本總結 / 專案過程總結。
在這個過程中，每個開發人員都各司其職，擰著各自負責的螺絲。
很多新人在加入技術團隊後，通常會有一個資深的員工作為師兄幫助其更快地融入工作、掌握相應的技術。一般而言，在開始階段新人的任務都是從簡單的程式開始寫起，比如遷移部分系統程式碼（從上游系統遷移到下游系統），做一些簡單的小需求（如修改 bug，增加某一個欄位等）。
這些需求看似簡單，實則不然。因為哪怕涉及一行的改動，都需要進行大量的測試進行覆蓋，很多人以為這些都該是測試去做，但實際上，測試往往只能進行黑盒測試，而且測試對於程式碼的瞭解程度一定不如開發，所以在這些細節上的測試都是由開發自己自測完成。因此，往往改動一行程式碼，開發就可能都會花上半天的時間用各種方法進行測試。
不僅是測試，阿里技術團隊在 2016 年左右開始了一次大的組織架構調整，即把日常的運維工作交給研發做。原來的 PE（Production Engineer）要麼轉崗去做工具平臺開發，要麼作為運維專家做產品規劃和設計，還有一部分無法適應的只能黯然離開。這是阿里運維從工具化到自動化最重要的一個過程。
規模化、流程化、自動化，這幾個關鍵字放在一起，你第一眼可能想到的是生產車間，但在阿里巴巴，這是其技術團隊多年沉澱下的一個行之有效的軟體開發模式。
阿里巴巴相對而言是一家業務驅動的公司，專案以業務優先，對於團隊來說其重要性不言而喻。在阿里巴巴，這是一個需要多人開發，團隊協作的事情。對於那些研發人數動輒超萬人的大型網際網路公司，要前端就找前端，要後端就找後端，規模化以後要求的不是全才，而是專才。
規模越大的網際網路公司，程式設計師乾的事情反而越機械，在軟體開發的流水線上做著增刪查改的擰螺絲活兒，但這些人，在入職前可是透過了“面試造核彈”般的篩選才進來的。越是高階別的技術專家，出現水貨的可能性也越小，同樣，他也不可能成為一個小公司需要的全棧開發。什麼都會一點的結果，就是什麼都不精。
產品規模上去以後，各個模組複雜度都很大，全棧未必適合，規模上去以後勢必也要拆分一些專案出來，由專人維護，全棧存在的意義不大。大公司講究專人專崗，你就做好自己那點事就得了，就算你離職，找到替代你的人相對也比較容易。
“所以你想挖一個阿里的 P8 做你公司需要的全棧是不現實的，你就是把行癲挖過來這問題也解決不了啊。”
那小公司的技術咋整？
“人們一提起‘全棧開發工程師’，大家的印象肯定是：這號人啊，堪稱大神！會很多技術，前端後端都精通，不掌握七八種語言都不好意思出來打招呼，熱點技術名詞全都知道，也都會點兒，跟誰都能談笑風生。”
對對對，我們要的就是這樣的人！
“但是呢，全棧工程師更像是一個神話。每個人的精力都是有限的，你需要人家精通前後端，自己能寫程式碼還能做測試搞運維，能寫網站還要能寫 App，你咋不上天呢？”
以上是一個全棧工程師應該掌握的並不詳盡的技術棧，各位可以對照著看看自己離全棧有多遠，再想想全棧工程師是夢想還是現實。這還是在不考慮技術更新換代就像智慧手機的更換週期一樣的現在，上圖所示的技能表每年每層都會增加新的元件，每隔幾年又會增加新的層。全棧，你全得過來嗎？
全棧工程師，一定程度上更像金庸小說裡的慕容復，剛出場時牛逼哄哄，什麼都會，自帶光環。可後來隨著劇情（業務）的展開，逼格直線下降，被武林同道所笑話。
事實上，創業公司一般比較喜歡招全棧，這和創業公司的需求有關係，因為創業初期的公司可能需要一個人做幾個人的活。另外，可能老闆是技術出身，瞭解部門之間銜接所需要付出的巨大溝通成本，所以傾向於更少的溝通單位。
對於個人和公司，全棧的定義是不一樣的，初期公司肯定是希望全棧的技術廣度和深度剛好能滿足公司業務要求，本質上只是想要個全乾。但對於個人來說，大多數普通人的時間精力有限，很難真正在廣度和深度都做到專業，如果只是為了滿足公司需求點技能點的後果就是——專案發展起來之後公司有錢了，全棧差不多就該掃地出門了。
對於創業公司而言，為了壓制成本，需要全棧完全能夠理解。畢竟一個優秀的程式設計師也不便宜，能讓一個人幹兩人甚至三人的活兒好像對於成本控制是個好辦法。然而，顯性的成本控制住了，隱性的成本呢？
“你想沒想過，當你的專案到了關鍵時刻，比如要上線了，或者上線出 bug 了，這時候分分鐘就是幾十上百萬的流水，而你的技術團隊因為缺乏專人出問題了。你急急忙忙地去找你的全棧 CTO，他卻說：稍等，我上 Stack Overflow 查下這是什麼故障。你崩潰嗎？”
呃……
”會上 Stack Overflow 的還算好的，他要是個面向百度程式設計的全棧，你就只有哭的份了。“
再進一步，一個比較複雜的專案，如果一個全棧走了，專案受到的影響會很大，你很難再招到一個完全匹配該專案的另一個全棧。我們見過太多創業公司因為技術團隊關鍵人物離職直接導致專案失敗的案例，你越是想省錢，越是省不下錢。
聽你這麼說，怎麼覺得全棧就這麼不堪入目呢？
”非也非也。你們這些當老闆的，總是認為都是寫程式碼，前端後端沒什麼區別，Java、Go 沒什麼兩樣，這本身就是最大的誤解。全棧工程師一定是有其存在的意義的，但你如果想讓全棧工程師把什麼事兒都全乾了，996 都沒你這麼狠的。全棧工程師也許是未來的一個發展趨勢，但現在那些簡歷上寫著全棧的程式設計師，大機率才是你們認為的水貨。“
所以總結下來，他不是個水貨 P8，我是個水貨 CEO 嘍？
“佛曰，不可說。”
注：原文源自網路
END
本作品採用《CC 協議》，轉載必須註明作者和本文連結