什么是全棧工程師 做全棧工程師真的好嗎

最近參加一個技術(shù)社區(qū)活動，在討論到“CTO的技術(shù)深度和廣度哪個更重要”的話題時，我想起社區(qū)里面常常提到的“全棧工程師”的事情，于是表達了一些觀點。臨場未必能夠清晰表達，所以下筆，希望能夠引起一些討論，避免年輕工程師誤入歧途。

長期以來，社區(qū)就有人在提“全棧工程師”，還有一些公司直接掛出名為“全棧工程師”的招聘職位。那什么是全棧工程師？

百度百科的解釋是：全棧工程師，英文叫Full Stack Developer，是指掌握多種技能，并能利用多種技能獨立完成產(chǎn)品的人。說白了就是啥都懂的人，左青龍右白虎老牛在腰間，人擋殺人佛擋殺佛。想想，一個項目從前到后要包含多少技術(shù)？就拿TalkingData來說，就至少有H5、JavaScript、CSS、Java、Kafka、MongoDB、Redis、MySQL/MariaDB、Vertica、Hadoop、Spark、Tychron等等，這些研發(fā)目前需要數(shù)據(jù)可視化團隊、計算平臺團隊、存儲平臺團隊、數(shù)據(jù)挖掘團隊和運維團隊來共同完成。要是出現(xiàn)這么一個全能王，把活一攬子全部接下來，那要省掉多少溝通代價和薪資成本？——這簡直就是救世主！

想到這里，我頓覺慚愧，十幾年的技術(shù)算是白搞了，要是剛畢業(yè)即以此為目標(biāo)，每個月學(xué)一門，學(xué)完一門換一門，那用不了兩年就能轉(zhuǎn)職“全棧工程師”這個終極職業(yè)，站上技術(shù)巔峰，俯瞰蕓蕓眾生——是不是有一種游戲開掛的快感？想想做個架構(gòu)師都需要四五年的辛苦積累，現(xiàn)在能兩三年速成，豈不是很爽？

終于，在這樣自我催眠，加上一些輿論的刻意引導(dǎo)下，大批有志青年開始走上全棧工程師的自我修煉之路。沒有多少人愿意腳踏實地積累自己的技術(shù)經(jīng)驗，或者潛心去研究開源技術(shù)的底層代碼，或者做更深入的性能對比分析。很多人閃電般的在不同公司之間跳來跳去，走馬觀花，狂熱浮躁。

這幾年，因為大數(shù)據(jù)需求的不斷成熟和數(shù)據(jù)業(yè)務(wù)的持續(xù)發(fā)展，TalkingData研發(fā)團隊一直保持高密度的招聘，我們對這個現(xiàn)象的感覺是比較明顯的。因為我們在面試中越來越多的發(fā)現(xiàn)，年輕人的簡歷寫得愈發(fā)琳瑯滿目，這也“精通”，那也“擅長”，數(shù)量不等的“多年經(jīng)驗”或“長期從事”……恨不得2年工作經(jīng)驗比干10年的簡歷還要長，幾乎稱得上當(dāng)代常用技術(shù)巡展。不要太強！只看簡歷就想趕緊招進來，再開掉現(xiàn)在這些“尸位素餐”的非全棧員工，世界肯定清凈了吧？

但是情況真的是這么好嗎？

在面試中，我們會通過問答，檢驗候選人在技術(shù)上思考的深度、理解能力、學(xué)習(xí)能力和解決問題的能力。所以研發(fā)人員面試一般會遵循以下流程：

1. 介紹一下背景和職業(yè)經(jīng)歷。

2. 選擇一個你最熟悉或擅長的項目，詳細(xì)描述一下整體架構(gòu)和你做的工作。

3. 討論一下你遇到的挑戰(zhàn)以及怎么去解決的。

4. 然后從這一步開始，我們就會不斷地挑戰(zhàn)，不斷追問“為什么”，直到通關(guān)或者回答不出來為止。

在這個流程中，每一步都有大批候選人失敗，比較典型的失敗原因包括：

1. 跳槽頻繁

最常見的理由是“我想學(xué)習(xí)新的東西”。想學(xué)新東西是值得贊賞的，但是我很難想到正常人在短時間就能把一門新的技術(shù)學(xué)通。尤其是開源技術(shù)，基本屬于入門容易精通難，很容易找到一些教程101，幫你5分鐘學(xué)會安裝部署，但是一旦用上生產(chǎn)系統(tǒng)，就很容易出現(xiàn)各種各樣的突發(fā)問題，配置的、架構(gòu)的、網(wǎng)絡(luò)的、代碼的、甚至還可能有硬件的——逼迫你絞盡腦汁上各種論壇找各種谷哥度娘去解決。經(jīng)驗就是從不斷填坑的過程中積累起來的。只會安裝部署，距離真正掌握還差八千里。

最夸張的見過2年換了6個公司。所以到后來，只要一看到簡歷中最近3次工作經(jīng)驗中沒有超過2年的，直接就略過了。

2. 缺乏對架構(gòu)的感覺

先不說一個技術(shù)人員（尤其是大數(shù)據(jù)技術(shù)人員）必備的好奇心或邏輯性，也只有對整體架構(gòu)有清晰的認(rèn)識，才能更加準(zhǔn)確的了解自己要實現(xiàn)的需求對整個業(yè)務(wù)線的意義，從而在功能邊界定義和技術(shù)選型上有相對合理的判斷。如果對于自己熟悉項目的整體架構(gòu)缺乏了解或者描述不清晰，我們認(rèn)為這樣的研發(fā)人員比較缺乏整體感和全局觀，成長一般都會比較有限。

實際上畫不出整個產(chǎn)品線技術(shù)架構(gòu)圖的大有人在，能畫出來但是各個模塊畫的稀里糊涂的也不在少數(shù)。

3. 技術(shù)浮于表面

說起遇到的挑戰(zhàn)時，很容易能夠看出候選人對于技術(shù)掌握的深度。說不出挑戰(zhàn)的情況，要么是任何技術(shù)都擋不住的大牛，要么就是沒有經(jīng)歷過比如計算瓶頸、數(shù)據(jù)淤積、磁盤爆滿、內(nèi)存不足、架構(gòu)調(diào)優(yōu)這樣的戰(zhàn)斗洗禮。對于后者，面試官辨就一定要小心，因為這樣的人即使用過的技術(shù)和框架再多，為你帶來的坑也可能比填的坑還多。

想起一個印象比較深的例子，一個候選人簡歷上充滿了說自己長于各種大數(shù)據(jù)技術(shù)的明示，然后在面試中請他找個最擅長的項目深入聊聊的時候，他說，呃…這個…那我們來聊聊之前做過的一個網(wǎng)站項目吧，我在里面做web前端……當(dāng)時我就無語了。

4. 細(xì)節(jié)禁不住挑戰(zhàn)

為什么要選擇這個方案？和別的方案對比有什么優(yōu)勢？這個方案有什么問題？如果讓你來研發(fā)這個方案的新版本，你準(zhǔn)備做什么樣的優(yōu)化，為什么？數(shù)據(jù)量如果增大一個數(shù)量級，你覺得這個方案會出現(xiàn)瓶頸嗎？再增大一個數(shù)量級呢？BlaBlaBla……這些都是例行問題，如果沒有對技術(shù)熟悉并研究到一定程度，是很難有條理的說清楚的。

曾經(jīng)遇到過一個牛氣哄哄的年輕人，剛畢業(yè)工作1年就找親戚投資創(chuàng)業(yè)擔(dān)任CTO，瞎折騰了一年公司黃了，然后出來找工作。第一年的薪資算正常，擔(dān)任CTO的時候就給自己工資翻倍，然后在翻倍的基礎(chǔ)上期望我們再漲50%。也就是說，經(jīng)過這一年創(chuàng)業(yè)過程，他覺得自己做了CTO，接觸了好多技術(shù)，增值了，“我什么都能干”，理應(yīng)比第一年漲3倍。實際問起來，每項技術(shù)都是泛泛，沒什么細(xì)節(jié)，自然就fail了。

作家格拉德威爾在《異類》一書中指出，“人們眼中的天才之所以卓越非凡，并非天資超人一等，而是付出了持續(xù)不斷的努力。1萬小時的錘煉是任何人從平凡變成超凡的必要條件。”他將此稱為“一萬小時定律”。

要成為某個領(lǐng)域的專家，需要至少10000小時。如果每天工作八個小時，一周工作五天，那么成為一個領(lǐng)域的專家至少需要五年。就算是一直搞“996”，也差不多需要3年。這符合任何一個有經(jīng)驗的技術(shù)人員的認(rèn)知：一門技術(shù)，沒有兩三年以上的熟悉和研究，是根本談不上精通的。尤其是大數(shù)據(jù)行業(yè)是一個比較新的行業(yè)，很多技術(shù)和方法都在摸索階段，需要更多的時間來積累。TalkingData也是經(jīng)過了4年多和海量數(shù)據(jù)以及各種大數(shù)據(jù)技術(shù)的斗爭，趟過了無數(shù)的地雷陣，到今天才可以說是有了一些積累，培養(yǎng)出一批在大數(shù)據(jù)領(lǐng)域比較有經(jīng)驗的技術(shù)專家。即使這樣，我們從來也不認(rèn)為我們研發(fā)團隊里面有“全棧工程師”。

大數(shù)據(jù)行業(yè)一定是靠經(jīng)驗靠積累，沒有任何速成的做法，所以我們始終控制研發(fā)團隊能夠更加聚焦一些而不是更發(fā)散一些，做的更深而不是更廣一些。

那說回來，到底有沒有全棧工程師存在？肯定是有的。但是我見過的能稱得上“全棧”的工程師，基本都在某一個領(lǐng)域?qū)戇^大量代碼，或者解決過大量問題，積累了非常深厚的功底，然后在精深之后，把知識轉(zhuǎn)化成為常識，才能真正觸類旁通。這時候看起來應(yīng)該就是大家說的“全?！卑伞５沁@顯然不適合經(jīng)驗較少的菜鳥工程師。

所以，希望年輕的技術(shù)人員能夠更加踏實一些，不要輕信“全棧工程師”的美麗神話。只有為自己打好技術(shù)基礎(chǔ)，才能飛得更高。