?作者 | 云昭

在這樣一個(gè)時(shí)代，不光老板們，即便是工程師們，也巴不得個(gè)個(gè)都能全?！鮿?chuàng)公司或科技前沿行業(yè)在招聘時(shí)，往往會希望候選者是一名全棧工程師。一份工資，兩份成果，老板們面對這樣的人才，當(dāng)然都會“幸甚至哉”！

同樣地，相當(dāng)一部分開發(fā)者，在達(dá)到職業(yè)生涯的某個(gè)時(shí)刻，也會開始尋求“全?！蓖黄疲碛蓜t通常是：可以加快自己的成長速度，恨不能以兩倍的速度快速突破職場瓶頸，晉升高一級的職位。

你看，如果說全棧的誕生是因?yàn)榈谝淮夹g(shù)?！癓AMP”太過強(qiáng)大，不用不行，那么目前全棧的流行，可以說不外乎這兩個(gè)原因：一，為老板生錢，二，是程序員的歸宿。

1、全棧的雷區(qū)

迷信全棧很危險(xiǎn)，它的雷區(qū)在于：今天所謂的前期節(jié)省，都將演變成日后的成本：“畸形”的數(shù)據(jù)庫、一大堆待補(bǔ)償?shù)募夹g(shù)債務(wù)、用戶難以描述的憤怒表情。

圖源：網(wǎng)絡(luò)

這也是為什么產(chǎn)品、開發(fā)、運(yùn)維在溝通協(xié)作中明明各抒己見，得到的結(jié)果卻往往是“雞零狗碎”：

• “產(chǎn)品這個(gè)需求太變態(tài)了”
• “為什么有這么多安全限制”
• “運(yùn)維要求的服務(wù)器操作規(guī)范實(shí)在看不懂”

因?yàn)橐粋€(gè)人做到全棧，很難！

那些認(rèn)為自己能很好地處理多任務(wù)的人，往往結(jié)果十分糟糕，而全棧工程就成了一個(gè)關(guān)于“長期上下文切換”的生產(chǎn)故事。有這樣一個(gè)多線程的典型問題——設(shè)計(jì)一個(gè)具有適當(dāng)索引的Boyce Codd范式數(shù)據(jù)庫模式，并實(shí)現(xiàn)一個(gè)高度可擴(kuò)展的RESTful調(diào)用，同時(shí)構(gòu)建一個(gè)直觀簡潔的用戶界面，以呈現(xiàn)與相應(yīng)對象模型的交互？然后，支持并維護(hù)完整的實(shí)施以及過程中可能產(chǎn)生的所有問題。

即便是一個(gè)多年經(jīng)驗(yàn)的老兵看到這些，可能都會退避三舍。

原因就在于，前端和后端同樣復(fù)雜，二者都有自己的優(yōu)先級和實(shí)踐。任何一個(gè)“端”的精通都需要多年摸爬滾打，才能勉強(qiáng)做到。別忘了，每個(gè)“端”都在隨著時(shí)代發(fā)生著演進(jìn)。

于經(jīng)驗(yàn)不足的工程師而言，全棧工程并不適合，因?yàn)檎J(rèn)知負(fù)荷過載，會明顯降低開發(fā)速度并導(dǎo)致更多錯(cuò)誤，遺患無窮。而于老兵而言，全棧工程也僅僅能交出一份當(dāng)時(shí)還算湊合得過去的答卷，過不了多久也會爆出種種問題。

因?yàn)?，只要某個(gè)領(lǐng)域在繼續(xù)快速發(fā)展，即使是經(jīng)驗(yàn)豐富的工程師也難以跟上。

盡管我們有很多天賦，但大腦并不是指數(shù)級的。在繁重的認(rèn)知負(fù)荷下，人們多線程處理的能力很差。

2、全棧為什么只適合小項(xiàng)目

如果你去招聘軟件搜索“全?！?，就會發(fā)現(xiàn)要么招聘方是小公司，要么出現(xiàn)在前端工程師的崗位需求里。

這也難怪會讓人產(chǎn)生一種固有的印象：只有小公司才有全棧工程師。

在這些組織內(nèi)，高效的全棧工程是需求所在。同樣，早期創(chuàng)業(yè)公司在尋求資金時(shí)，有時(shí)會滿足于打造一個(gè)“松散”的MVP。（這很可能是建立在服務(wù)器端渲染框架上的。）全棧工程師可以做到這一點(diǎn)，但他們不應(yīng)該因?yàn)槌鮿?chuàng)公司無法聘請更深入的團(tuán)隊(duì)而被利用或受到不公平的壓力。

這里的關(guān)鍵是要睜大眼睛，當(dāng)公司獲得大量資金時(shí)，就需要從頭開始重寫代碼。這不是重構(gòu)或擴(kuò)展?fàn)I養(yǎng)不良MVP的問題。公司很可能會扔掉它，重新開始，用一支合格的專業(yè)工程師團(tuán)隊(duì)更有力地構(gòu)建它。

如果每個(gè)人都能接受全棧工程的局限性，并且愿意接受后果，而不會因?yàn)榇a庫的缺點(diǎn)而懲罰團(tuán)隊(duì)，那么就讓全棧“自由漫游”吧。

對于一部分軟件工程中存在的問題，任何獨(dú)立工作的全棧工程師都可以制定出可行的解決方案。常見的通常有兩種用例：

• 服務(wù)器端渲染框架
• 將MVP或原型進(jìn)行攻擊測試

有些問題很熟悉，而且很簡單，可以用服務(wù)器端渲染框架來解決。Ruby on Rails、Django、Laravel……如果所需的解決方案完全符合這些框架，那么精通這些框架的經(jīng)驗(yàn)豐富的全棧開發(fā)人員團(tuán)隊(duì)完全能夠高效構(gòu)建。

但請記住，雖然這僅僅可以滿足短期需求，其復(fù)雜性和規(guī)模下的生存能力是有上限的。全棧開發(fā)者是致力于為一系列眾所周知的問題，設(shè)計(jì)出某些有限的選擇。

對于所有的工程挑戰(zhàn)來說，全棧并不是最佳選擇。很有可能會在不久的將來，就需要重構(gòu)代碼庫，以便轉(zhuǎn)移到合適大小的服務(wù)，或者實(shí)現(xiàn)一種更創(chuàng)新的方法來解決新問題。

3、大廠不配有全棧工程師？

在大廠，很少看到一位工程師大包大欖的情景。但全棧的人才不在少數(shù)?；蛘哒f，大廠不存在全棧工程，但全棧思維往往是必不可少的。這是因?yàn)橛懈咝У膮f(xié)作機(jī)制。

以前后端溝通協(xié)作為例。

• 后端開發(fā)人員可以專注于數(shù)據(jù)層、設(shè)計(jì)良好的RESTful端點(diǎn)、線程、可伸縮性問題、避免查詢的n+1問題等等。
• 前端開發(fā)人員可以專注于用戶和應(yīng)用程序之間愉快而直觀的交互、高效的UI捆綁包下載以及設(shè)計(jì)良好且可重用的組件。

他們的大部分工作，每個(gè)人都可以獨(dú)自完成，完全專注于自己的專業(yè)，并善意地忽視了對方的顧慮。但是，當(dāng)他們的責(zé)任領(lǐng)域發(fā)生重疊時(shí)，團(tuán)隊(duì)成員協(xié)作確定最佳解決方案。

用戶需要訪問或編輯哪些數(shù)據(jù)？UI將如何調(diào)用API？數(shù)據(jù)合同是什么樣子的？團(tuán)隊(duì)一起圍繞這些問題進(jìn)行協(xié)調(diào)，然后各自著手處理解決方案中各自的部分。  

通過將團(tuán)隊(duì)召集在一起進(jìn)行這些對話，確實(shí)會在短時(shí)間內(nèi)將過程降到一半，但一旦他們再次分離，您就會回到全速狀態(tài)，需要更快的速度并在各自的職責(zé)中正確實(shí)施功能。（同時(shí)，全棧工程師最多只能以一半的速度完成整個(gè)項(xiàng)目，多任務(wù)處理和上下文切換會讓一切陷入困境。）

正如您所期望的，考慮到這些職責(zé)重疊，每個(gè)團(tuán)隊(duì)成員都必須了解對方的專業(yè)領(lǐng)域。但如果這方面的專業(yè)知識不夠深入，特別是對于那些還處于職業(yè)生涯早期的工程師來說，這是可以的。

當(dāng)然并不是說，大廠內(nèi)部不存在全棧人才，相反往往高級別的技術(shù)人，他們的全棧思維更強(qiáng)，在溝通決策中發(fā)揮著關(guān)鍵的作用。

4、全棧需在合作中精心打造

全棧不是萬金油。只有合作才是成長的正確路徑。

在軟件工程師的職業(yè)生涯早期，可能在其他職業(yè)中也有一種傾向，即嘗試一次學(xué)習(xí)所有的東西。但現(xiàn)實(shí)總是啪啪打臉。根據(jù)1萬小時(shí)定律，后端1萬小時(shí)，前端1萬小時(shí)，算法1萬小時(shí)，運(yùn)維1萬小時(shí)……遲早會崩潰掉的。

想象一下，試圖同時(shí)攻讀數(shù)學(xué)和生物學(xué)雙博士學(xué)位，去解決一個(gè)高深的問題。隨著你的注意力和時(shí)間的分散，你甚至需要很多年才能完成其中一個(gè)博士學(xué)位。關(guān)鍵是，到那個(gè)時(shí)候，這個(gè)高深問題已經(jīng)被兩位博士合作解決了，那就尷尬了。但如果兩個(gè)人術(shù)語有專攻，不時(shí)交流各自領(lǐng)域的研究進(jìn)展，即便問題沒有解決，也會發(fā)現(xiàn)解決的方向。

軟件工程也是如此。如果你決定在很長一段時(shí)間內(nèi)專注于前端或后端工程，然后學(xué)會在不同專業(yè)的人的團(tuán)隊(duì)中進(jìn)行良好的合作，就會進(jìn)步得更快。

一個(gè)團(tuán)隊(duì)的成員通常被安排得各有所長，原因就在于此。成員通過合作學(xué)到跨學(xué)科知識，而跨學(xué)科知識將幫助成員解決更多難題。

久而久之的積累，團(tuán)隊(duì)的成員就會變成“有主有輔”的全棧人才。

5、寫在最后

在大多數(shù)情況下，于企業(yè)而言，全棧只是一種選擇，可以讓工程師資源有限的情況下，實(shí)現(xiàn)一個(gè)次優(yōu)方案。當(dāng)然，有一些例外，比如：特定用例中的特定工具，全棧工程師可以交付完美的功能代碼。

而于擁有多年經(jīng)驗(yàn)的高級工程師來說，全面的專業(yè)知識可以合理地成為一種最終選擇。但不要把全棧當(dāng)成萬金油，它不是為了解決全部問題，相反，而是為了解決某一領(lǐng)域的確定問題。所以，全棧思考問題的方式是值得肯定的。

技術(shù)棧的各層發(fā)展十分迅速，沒有人可以掌握一切。職責(zé)多樣化和專業(yè)化是很自然的結(jié)果。所謂的全棧往往通過合作能夠更快更有效的達(dá)成，而不是一味單干單學(xué)。

真正的全棧工程師，技術(shù)工作只是故事的一半。另一個(gè)關(guān)鍵部分是與其他團(tuán)隊(duì)建立一致的合作，以確保編寫的代碼符合他們系統(tǒng)的標(biāo)準(zhǔn)，完成一致的目標(biāo)。

參考鏈接：https://www.infoworld.com/article/3681896/full-stack-engineering-is-one-third-as-good.html