近，每當我談論起全棧開發時，很多人都深表懷疑，他們說世界上并不存在全棧工程師，而且大多數開發人員只適合后端或前端的工作。
針對全棧開發的大多數批判都可以歸結為以下兩點：
沒有人可以同時成為前端和后端的專家，所以好還是術業有專攻。
大多數人只適合前端或后端的工作。
然而，這些批判都未能切中全棧的要點。
全棧指的不是代碼，而是責任
全棧指的不是你所熟悉的編程語言或掌握的技術，而是指你能夠利用工具和相應的權限，克服所有困難，負責某項任務的始末。
將一個任務拆分成不同的職責，然后交給不同的人員處理，這中間會造成不必要的斷層，此外還需要額外的協調，而且通常很難實現跨層的解決方案。
假設我們有一個非常簡單的Web開發任務，需要后端開發人員提供新API，同時還有部分前端的開發工作，比如顯示某些指標或活動的圖表。
開發這類功能的時間表通常如下所示：
如果范圍發生變化，或有關該任務的新技術出現了，那么就需要對原來的架構進行調整，這時兩位開發人員會成為彼此的瓶頸——他們會牽制彼此的連續工作，會給彼此施壓，而且在切換思路時也很痛苦，終有可能在兩位開發人員之間引起怨恨和沖突。
由于大多數工作本質上都是有順序的(如上圖所示，前端開發人員需要API)，而且在前一個任務完成之前，后一個開發人員必須等待，或者想變通的方法(如上圖所示，使用模擬API)。
重要的是，很多時候某一層中遇到的難題可以在其他層簡單地解決。而當開發人員只負責前端或后端時，通常他們不會考慮自己職責范圍之外的解決方案。
全棧開發的優點
沒有瓶頸：你不需要等待另外一個人即可連續工作。
更快的迭代：你可以隨時修改API，并在客戶端查看修改后的結果，然后通過修改UI來處理新的API，而且你可以連續推進這種迭代。
與利益相關者拉近距離：你可以利用應用程序的可視化部分，為利益相關者展示你的工作進度，并與他們進行交流，這有助于拉近你與利益相關者之間的距離。
所有權：直接與各方人士(利益相關者、質量保證、產品、管理)聯系，更為順暢地溝通和管理，肩負起一定的責任。
任何人都可以勝任全棧開發
為了回應“并非每個人都可以勝任全棧開發”的批評，我想指出，如今的前端放到幾年前就是后端，特別是困難的部分—— 路由、狀態管理、緩存、甚至業務邏輯現在常常放到前端完成。
大多數前端問題不需要詳細了解語言的設計、UI性能或瀏覽器兼容性，通常只需添加幾個div，然后修改一些CSS值(假設你的客戶端是Web的話)。
同理，大多數后端問題也不需要詳細了解并發模型、字節碼操作或ORM的內部機制，通常只需向數據庫或API模型添加新字段。
成為一名全棧工程師并不意味著你需要成為掌握所有技術的專家，也不意味著你需要以一己之力承擔起所有的工作。如果你需要在不太熟悉的領域開發某個功能，也并不意味著你不可以求助于他人。你應該向那些專注于該領域且經驗豐富的專家尋求指導和幫助。
全棧開發人員也可以專攻某項技術
成為一名全棧開發并不意味著你不可以專攻某項技術，或成為某個方面的專家。
有人說你無法同時掌握前端和后端，那么這是否暗示了如果你潛心研究某一層，就可以深入掌握這方面的技術?這很荒謬，前端和后端也分很多區域，任何人都不可能成為全面掌握了某一層的專家。
你可以成為一名全棧開發，同時還可以成為圖形庫的專家。
你可以成為一名全棧開發，同時還可以成為ORM的專家。
就像其他開發人員一樣，全棧開發終會深入某些領域的專業開發知識，因此將這些領域中較為復雜的任務分配給專門研究這些領域的開發人員是很自然的事情。
不要按照前后端劃分開發人員。
全棧不僅僅是后端和前端
全棧不僅僅是后端和前端，全棧代表了一種工作方式，采用這種方式的開發人員全權負責自己的代碼，他們能夠克服所有的困難，完成自己的任務。
相同的工作方式適用于整個技術棧，例如后端開發人員不必等待DBA批準數據庫上的SQL腳本，也不必等待運維將新功能添加到CI。而在進行前端工作時，你也不必等待UI設計師為你修圖。
全棧開發普遍適用
在軟件開發的世界里，沒有任何流程是靈丹妙藥。多年來，人們總是按照不同的層次劃分開發，這其中有一定的價值。
如果你的開發過程涉及大量規劃，而且你的需求規格絕不會更改，那么就可以讓不同的人承擔不同的開發層。
有些行業有嚴格的法規或認證流程，所以很難在所有團隊中實施全棧開發。
此外，也不一定要在整個組織內實施全棧開發，但是，如果你采用了敏捷流程進行Web開發，那么采用面向全棧開發的流程會更有效。
這篇文章很可能會引發很多爭議，因此我在此先聲明一些事項：
雖然本文中的很多例子都側重于前端，但是全棧開發的好處并不僅限于為前端工作減壓。后端開發也會遇到同樣的問題，而且后端也可以受益于全棧開發。
這篇文章可能會給你一種錯覺：我們永遠不應該分割任務。然而，這并非我的本意，你應該合理地分割任務，但是應該按照功能分割，而不是按層分割。
