?作者 | 云昭

在這樣一個時代，不光老板們，即便是工程師們，也巴不得個個都能全棧——初創公司或科技前沿行業在招聘時，往往會希望候選者是一名全棧工程師。一份工資，兩份成果，老板們面對這樣的人才，當然都會“幸甚至哉”！

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

你看，如果說全棧的誕生是因為第一代技術棧“LAMP”太過強大，不用不行，那么目前全棧的流行，可以說不外乎這兩個原因：一，為老板生錢，二，是程序員的歸宿。

1、全棧的雷區

迷信全棧很危險，它的雷區在于：今天所謂的前期節省，都將演變成日后的成本：“畸形”的數據庫、一大堆待補償的技術債務、用戶難以描述的憤怒表情。

圖源：網絡

這也是為什么產品、開發、運維在溝通協作中明明各抒己見，得到的結果卻往往是“雞零狗碎”：

• “產品這個需求太變態了”
• “為什么有這么多安全限制”
• “運維要求的服務器操作規范實在看不懂”

因為一個人做到全棧，很難！

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

即便是一個多年經驗的老兵看到這些，可能都會退避三舍。

原因就在于，前端和后端同樣復雜，二者都有自己的優先級和實踐。任何一個“端”的精通都需要多年摸爬滾打，才能勉強做到。別忘了，每個“端”都在隨著時代發生著演進。

于經驗不足的工程師而言，全棧工程并不適合，因為認知負荷過載，會明顯降低開發速度并導致更多錯誤，遺患無窮。而于老兵而言，全棧工程也僅僅能交出一份當時還算湊合得過去的答卷，過不了多久也會爆出種種問題。

因為，只要某個領域在繼續快速發展，即使是經驗豐富的工程師也難以跟上。

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

2、全棧為什么只適合小項目

如果你去招聘軟件搜索“全棧”，就會發現要么招聘方是小公司，要么出現在前端工程師的崗位需求里。

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

在這些組織內，高效的全棧工程是需求所在。同樣，早期創業公司在尋求資金時，有時會滿足于打造一個“松散”的MVP。（這很可能是建立在服務器端渲染框架上的。）全棧工程師可以做到這一點，但他們不應該因為初創公司無法聘請更深入的團隊而被利用或受到不公平的壓力。

這里的關鍵是要睜大眼睛，當公司獲得大量資金時，就需要從頭開始重寫代碼。這不是重構或擴展營養不良MVP的問題。公司很可能會扔掉它，重新開始，用一支合格的專業工程師團隊更有力地構建它。

如果每個人都能接受全棧工程的局限性，并且愿意接受后果，而不會因為代碼庫的缺點而懲罰團隊，那么就讓全?！白杂陕巍卑?。

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

• 服務器端渲染框架
• 將MVP或原型進行攻擊測試

有些問題很熟悉，而且很簡單，可以用服務器端渲染框架來解決。Ruby on Rails、Django、Laravel……如果所需的解決方案完全符合這些框架，那么精通這些框架的經驗豐富的全棧開發人員團隊完全能夠高效構建。

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

對于所有的工程挑戰來說，全棧并不是最佳選擇。很有可能會在不久的將來，就需要重構代碼庫，以便轉移到合適大小的服務，或者實現一種更創新的方法來解決新問題。

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

在大廠，很少看到一位工程師大包大欖的情景。但全棧的人才不在少數?；蛘哒f，大廠不存在全棧工程，但全棧思維往往是必不可少的。這是因為有高效的協作機制。

以前后端溝通協作為例。

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

他們的大部分工作，每個人都可以獨自完成，完全專注于自己的專業，并善意地忽視了對方的顧慮。但是，當他們的責任領域發生重疊時，團隊成員協作確定最佳解決方案。

用戶需要訪問或編輯哪些數據？UI將如何調用API？數據合同是什么樣子的？團隊一起圍繞這些問題進行協調，然后各自著手處理解決方案中各自的部分。  

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

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

當然并不是說，大廠內部不存在全棧人才，相反往往高級別的技術人，他們的全棧思維更強，在溝通決策中發揮著關鍵的作用。

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

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

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

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

軟件工程也是如此。如果你決定在很長一段時間內專注于前端或后端工程，然后學會在不同專業的人的團隊中進行良好的合作，就會進步得更快。

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

久而久之的積累，團隊的成員就會變成“有主有輔”的全棧人才。

5、寫在最后

在大多數情況下，于企業而言，全棧只是一種選擇，可以讓工程師資源有限的情況下，實現一個次優方案。當然，有一些例外，比如：特定用例中的特定工具，全棧工程師可以交付完美的功能代碼。

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

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

真正的全棧工程師，技術工作只是故事的一半。另一個關鍵部分是與其他團隊建立一致的合作，以確保編寫的代碼符合他們系統的標準，完成一致的目標。

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