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