如果整個團隊全是全棧開發人員，不區分前端和後端，似乎是一個不錯的主意。 但是在這個新時代，沒有人能夠掌握開發的所有技術。

作者 | Joe Honton

譯者 | 彎月，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

全棧的起源

在新千年來臨之際，Web工具已發展得極為成熟，創建網站所需的一切都可以通過開源軟體組建。 我們可以仿照OSI網路模型，簡單地將應用程式開發的各種技術分層，而整個開發所需的技術集合稱為棧。

LAMP棧就是第一個棧，它包含四層：L表示Linux操作系統，A表示Apache HTTP伺服器，M表示MySQL資料庫伺服器，而P表示PHP腳本語言。 隨著時間的推移，我們看到了分層概念的優勢，因此衍生出了許多其他棧：WAMP、MAMP、XAMPP、LEMP、LEPP、MEAN、JAMStack等等。

有了這些技術棧，我們就相當於免費獲得了軟體開發復興的鑰匙，對於有興趣創建網站的人來說，如今的門檻更低了。 只要你有毅力和學習新工具、語言和協定的慾望就夠了。 你不需要使用微軟、Oracle、IBM或其他商業軟體。 這是一個公平的領域，吸引了很多人的目光，以至於90年代後期出現了互聯網的泡沫時代。

不久后，瀏覽器（XMLHTTPRequest）引入了 AJAX，從而引領了Web 2.0時代和Web應用程式。 但是，開發這些應用程式需要大量的工作，因此開發人員無法僅憑一己之力滿足業務的需求。

後來，開發人員開始分工專業化。 由前端開發人員處理HTML、CSS和JAVAScript。 後端開發人員處理主機操作系統、HTTP伺服器和資料庫。 而同時精通前後端的開發人員則稱之為全棧開發人員。

全棧時代

專業化是一件好事。 但並不會永久。 一方面，這意味著團隊可以並行工作以縮短開發週期。 另一方面，這也意味著我們必須付出更多的努力來傳達最初的要求和變更的規範，否則我們就會失去並行工作所帶來的優勢。

因此，整個團隊全是全棧開發人員，不區分前端和後端，似乎是一個不錯的主意。

最重要的好處是，團隊中的每個開發人員都充分瞭解每一處代碼變更帶來的後果。 他們每個人都可以正確地評估影響和風險，讓管理層清楚地瞭解成本和延誤狀況。 此外，每當有工作人員離職時，團隊可以立即換人，而且新人也可以很快地熟悉工作。 然而，隨著基礎技術的提升，這種美好的景象也失去了原有的魅力。 技術棧不再局限於最初的四層：操作系統、HTTP伺服器、資料庫和腳本語言。

• 隨著應用程式開始處理越來越多的併發使用者，複雜度也開始加劇。 於是，我們添加了負載平衡器。
• 我們需要更快地配置新伺服器，同時降低災難性故障的風險。 於是，我們開始使用雲計算。
• 我們開始構建面向全球用戶的產品。 於是，我們開始將部署複製到各個區域的數據中心。
• 我們發現，擁有大量模式的資料庫和複雜的聯結不太好用了。 於是，我們開始使用鍵值存儲。
• 我們需要更好的品質控制。 因此，我們聘請了專門的測試工程師來編寫回歸測試套件。
• 我們想讓瀏覽器控制渲染和合成。 於是，伺服器端的腳本換成了REST API。
• 我們瞭解到良好的代碼管理對團隊的效率至關重要。 於是，我們開始利用 Github 創建工作流程。

隨著開發能力的增強，我們開始更加密切地傾聽用戶的意見：

• 我們的使用者希望應用程式減少提交表單，更為流暢、更加一致、更易於使用。 於是，我們聘請了注重藝術技巧和人性的用戶界面專家。
• 我們的使用者要求降低完成工作的困難。 於是，我們聘請了用戶體驗專家來研究我們的缺點並設計更好的交互方式。
• 我們的用戶覺得手機更加方便，於是我們為他們提供移動版的大型SaaS應用。

此外，貫穿所有這些需求的基本技術也在不斷發展：

• HTML5逐漸成熟，開始支援有語義的Web頁面、可訪問性、service worker以及Web元件。
• CSS也在發展，已遠遠超出了選擇器和級聯，開始支援動畫過度、變數、新的佈局模型和分頁媒體。
• JavaScript呈現了爆炸式的增長，如今發展出了模組化、面向物件類、異步函數，還可以在任何地方執行——可以在瀏覽器的DOM中、在伺服器上，在桌面上也可以。
• HTTP發展出了更好的緩存、安全策略、持久會話、多路複用流，頭部壓縮以及優先順序等功能。

全棧時代並沒有完全死亡。 技術棧的各層迅速發展，沒有人可以成為掌握一切的專家。 職責多樣化和專業化是很自然的結果。

全棧工程師的榮耀已成為傳說。 在這個新時代，沒有人能夠掌握開發的所有技術。

2020棧

我們不得不思考：擁有跨層知識和技術力且才華橫溢的個人仍有優勢嗎？ 我們應該如何對待全棧開發人員帶來的項目經驗多樣化？ 管理如何才能滿足這些需求？ 招聘人員應如何篩選應聘人員？ 求職者又當如何凸顯自己的技術力？

我們應當重新考慮"全棧"這個術語了。

我之所以這樣說，是因為我幫助推廣了這個概念。 早在2009年，我就曾介紹過這個術語。 但可悲的是，時至2019年，這個術語已經成了計算機歷史博物館的紀念物。

奇怪的是，人們對"全棧"這個詞的好奇心在不斷增加。 2009-2019年期間，Google 搜索詞語趨勢快照顯示，在過去五年中，「全棧」這個詞的搜索次數急劇增加，而且年年創新高。

但是，如果人們都在尋找下一個趨勢是什麼，那麼我們就來談一談吧。 為了方便討論期間，讓我們先來給它起一個名字。

我將其稱為2020棧。 新一代的新名稱。

我認為：

• 首先，我很欣賞那些掌握了各種技術力的人。 他們不會陷入"專業化"的陷阱。 我們應該避免構建過於龐大的應用程式，那些帶有秘密咒語的大師，以及那些隨著專業化悄悄滲透的訊息孤島。
• 其次，我們需要瞭解到職業發展意味著人員變動。 各個組織必須把人員變動當成正常的運營。 即便高級職員離職，也不會影響到業務。 "沒有什麼人是必不可少的"。
• 第三，領域術語削弱了專家之間的溝通。 如果專家使用領域特定的術語、首字母縮寫詞和慣用語，那麼他們自身和隊友都將面臨危險（出自電影《歡喜俏冤家》）。 跨領域是保持溝通渠道暢通的關鍵。

2020棧專家的特徵可以總結如下：

沒有人可以掌握所有技術，因此2020棧必須由一個團隊來分擔。 不是一群人，而是一個真正的團隊。 這意味著，當一個人落後時，另一個人就會挺身而出。 當一個人擁有出色的技術力時，就可以通過一種機制來指導其他人。 當團隊的知識庫不足時，他們就會尋找一名更聰明的團隊成員。

每個2020棧團隊成員都必須是跨領域專家。 僅掌握了一兩層技術棧的人都算不上合格的2020棧團隊成員，這類的個人有望成為未來2020棧團隊成員，但也有可能不行。 但是在他們掌握各層技術棧上的深入知識之前，他們只能作為2020棧團隊的候選人。

2020棧團隊成員為專案帶來的各項技術並未嚴格分類。 與我們到目前為止採用的前端/後端分類不同，2020棧的分類是多種多樣的。 2020棧團隊中的某位成員可能熟悉NoSQL、雲配置和持續集成等技術。 同時，另一個2020棧團隊中可能有一位類似的成員，而他熟悉SQL資料庫、Node.js伺服器、容器和容器編排。 如果我們把他們統稱為2020棧團隊的後端開發，就低估了他們的技術力。

最後，這個團隊最關鍵的組成部分：每次交流都應該以針對當前問題做出最佳決策為共同的目標。 這意味著擁有相同技術的成員之間應該以開放的心態進行交流。 成員之間不僅應該互相傳達最新的進展，還應該展開討論。 這可以讓每個人都變得更聰明，而且還可以防止重新步入專業化的漩渦。 團隊成員一起成長。

你好，"2020棧！ ”

下面我們來想想看，如何利用2020棧更好地匹配職位要求與求職者的技術力。 專案經理發佈的招聘廣告可能包含以下內容，他們希望找到適合公司文化的人才：

Rock City Brewing is seeking a “2020 stack” team player with a strong background in testing, documentation, and code management. Applicants should also have cross domain skills in at least two of the following areas: cloud configuration, containers, orchestration, CI/CD, and server-side scripting.

Shape our future by helping us choose the best tools for the job. At RCB, career advancement is part of your job. Share your knowledge with the rest of the RCB 2020 stack each week at Tech Tuesday.

我公司希望招募在測試、文檔和代碼管理方面具有深厚背景的"2020棧"團隊成員。 該職位要求在以下領域中，至少擁有跨兩個領域的技術力：雲配置、容器、容器編排、CI/CD以及伺服器端腳本。

通過幫助我們選擇最佳的工具來塑造我們的未來。 職業發展是每位公司員工工作的一部分。 每週二我們都會舉行內部2020棧學習大會。

同一個職位的另一則招聘廣告則要求應聘者具備不同的技術力：

我們希望尋找一名"2020棧"團隊成員，擔任回歸測試、API文檔、Github工作流管理以及開發運維的工作。

如果你掌握了上述技術，請聯繫我們。

而求職者可以按照如下方式完善LinkedIn訊息：

我擁有多年的"2020棧"團隊工作經驗，擁有豐富的後端開發經驗以及最新的2020開發運維知識，包括Gitlab、Kubernetes 和 Digital Ocean。

我是開源和DRY的忠實擁護者，我認為成功重用的關鍵在於出色的文檔。

通過上述描述，我們看到了一名同時掌握了代碼管理域和開發運維域技術的開發人員。 "2020棧"團隊成員比敏捷團隊更加成熟。

2020棧的分層

那麼，2020棧應該如何分層呢？ 前端和後端等術語是否足以描述各層的特性？ 伺服器和Web、設計和運維呢？ 當然，這些類別足夠廣泛。

同時，我們也不能忽視測試人員，因為我們知道如果沒有他們，我們就無法交付品質勝過競爭對手的產品。 此外，如果沒有行銷人員，我們甚至連客戶都找不到。

所有這些因素我們都需要考慮。 有關我心目中完美的2020棧，請參考這篇文章（https://medium.com/better-programming/2020-002-my-perfect-2020-stack-43be78df37dd）。 說到底，2020棧就是跨領域溝通。 我相信這是一次全新的文藝復興。

原文：https://medium.com/better-programming/2020-001-full-stack-pronounced-dead-355d7f78e733

本文為 CSDN 翻譯，轉載請註明來源出處。