【文章來源微信公衆號：每天學編程】
技術在過去的幾十年裏進步很快，也將在未來的幾十年裏發展得更快。今天技術的門檻下降得越來越快，原本需要一個團隊做出來的 Web 應用，現在只需要一兩個人就可以了。
同時，由於公司組織結構的變遷，以及到變化的適應度，也決定了賦予每個人的職責將會越來越多。儘管我們看到工廠化生產帶來的優勢，但是我們也看到了精益思想帶來的變革。正是這種變革讓越來越多的專家走向全棧，讓組織內部有更好的交流。
你還將看到專家和全棧的兩種不同的學習模式，以及全棧工程師的未來。
技術的革新史
從開始的 CGI 到 MVC 模式，再到前後端分離的架構模式，都在不斷地降低技術的門檻。而這些門檻的降低，已經足以讓一兩個人來完成大部分的工作了。
CGI
二十年前的網站以靜態的形式出現，這樣的網站並不需要太多的人去維護、管理。接着，人們發明了 CGI (通用網關接口，英語：Common Gateway Interface)來實現動態的網站。下圖是一個早期網站的架構圖：
當時這種網站的 URL 類似於： https://www.phodal.com/cgi-bin/getblog
(PS：這個鏈接是爲了講解而存在的，並沒有真實存在。)
用戶訪問上面的網頁的時候就會訪問，cgi-bin 的路徑下對應的 getblog 腳本。你可以用 Shell 返回這個網頁：
#!/bin/sh
echo Content-type: text/plain
echo hello,world
Blabla，各種代碼混亂地夾雜在一起。不得不說一句：這樣的代碼在 2012 年，我也看了有一些。簡單地來說，這個時代的代碼結構就是這樣的：
這簡直就是一場惡夢。不過，在今天好似那些 PHP 新手也是這樣寫代碼的。
好了，這時候我們就可以討論討論 MVC 模式了。
MVC 架構
我有理由相信 Martin Fowler 的《企業應用架構模式》在當時一定非常受歡迎。代碼從上面的耦合狀態變成了：
相似大家也已經對這樣的架構很熟悉了，我們就不多解釋了。如果你還不是非常瞭解的話，可以看看這本書後面的部分。
後臺服務化與前端一致化架構
在今天看來，我們可以看到如下圖所示的架構：
後臺在不知不覺中已經被服務化了，即只提供 API 接口和服務。前端在這時已經儘量地和 APP 端在結合，使得他們可以保持一致。
軟件開發的核心難題：溝通
軟件開發在過去的幾十年裏都是大公司的專利，小公司根本沒有足夠的能力去做這樣的事。在計算機發明後的幾十年裏，開發軟件是大公司才能做得起的。一般的非技術公司無法定製自己的軟件系統，只能去購買現有的軟件。而隨着技術成本的下降，到了今天一般的小公司也可以僱傭一兩個人來做同樣的事。這樣的演進過程還真是有意思：
在這其中的每一個過程實質上都是爲了解決溝通的問題。從瀑布到敏捷是爲了解決組織內溝通的問題，從敏捷到精益不僅僅優化了組織內的溝通問題，還強化了與外部的關係。換句話說，精益結合了一部分的互聯網思維。
瀑布式
在最開始的時候，我們預先設計好我們的功能，然後編碼，在適當的時候發佈我們的軟件：
然而這種開發方式很難應對市場的變化——當我們花費了幾年的時間開發出了一個軟件，而這個軟件是幾年前人們才需要的。同時，由於軟件開發本身的複雜度的限制，複製的系統在後期需要大量的系統集成工作。這樣的集成工作可能要花費上大量的時間——幾星期、幾個月。
當人們意識到這個問題的時候，開始改進工作流程。出現了敏捷軟件開發，這可以解釋爲什麼產品經理會經常改需求。如果一個功能本身是沒必要出現的話，那麼爲什麼要花功夫去開發。但是如果一個功能在設計的初期就沒有好好設計，那麼改需求也是必然的。
敏捷式
現有的互聯網公司的工作流程和敏捷軟件開發在很多部分上是相似的，都有迭代、分析等等的過程：
但是據我的所知：國內的多數互聯網公司是不寫測試的、沒有 Code Review 等等。當然，這也不是一篇關於如何實踐敏捷的文章。敏捷與瀑布式開發在很大的區別就是：溝通問題。傳統的軟件開發在調研完畢後就是分析、開發等等。而敏捷開發則會強調這個過程中的溝通問題：
在整個過程中都不斷地強調溝通問題，然而這時還存在一個問題：組織結構本身的問題。這樣的組織結構，如下圖所示：
如果市場部門/產品經理沒有與研發團隊坐一起來分析問題，那麼問題就多了。當一個需求在實現的過程中遇到問題，到底是哪個部門的問題？
同樣的如果我們的研發部門是這樣子的結構：
那麼在研發、上線的過程中仍然會遇到各種的溝通問題。
現在，讓我們回過頭來看看大公司的專家與小公司的全棧。
大公司的專家與小公司的全棧
如果你經常看一些關於全棧和專家的技術文章的時候，你就會發現不同的人在強調不同的方向。大公司的文章喜歡強調成爲某個領域的專家，小公司喜歡小而美的團隊——全棧工程師。
如我們所見的：大公司和小公司都在解決不同類型的問題。大公司要解決性能問題，小公司都活下去需要依賴於近乎全能的人。並且，大公司和小公司都在加班。如果從這種意義上來說，我們可以發現其實大公司是在剝削勞動力。
專家
我們所見到的那些關於技術人員應該成爲專家的文章，多數是已經成爲某個技術領域裏的專家寫的文章。並且我們可以發現很有意思的一點是：他們都是管理者。管理者出於招聘的動機，因此更需要細分領域的專家來幫助他們解決問題。
全棧
相似的，我們所看到的那些關於成爲全棧工程師的文章，多數是初創公司的 CTO 寫的。而這些初創公司的 CTO 也多數是全棧工程師，他們需要招聘全棧工程師來幫助他們解決問題。
兩種不同的學習模型
而不知你是否也注意到一點：專家們也在強調**“一專多長”**。因爲單純依靠於一個領域的技術而存在的專家已經很少了，技術專家們不得不依據於公司的需求去開拓不同的領域。畢竟“公司是指全部資本由股東出資構成，以營利爲目的而依法設立的一種企業組織形式；”，管理人們假設技術本身是相通的，既然你在技術領域裏有相當高的長板，那麼進入一個新的技術也不是一件難的事。
作爲一個技術人員，我們是這個領域中的某個子領域專家。而作爲這樣一個專家，我們要擴展向另外一個領域的學習也不是一件很難的事。借鑑於我們先前的學習經驗，我們可以很快的掌握這個新子域的知識。如我們所見，我們可以很快地補齊圖中的短板：
在近來的探索中發現有一點非常有意思：如果依賴於 20/80 法則的話，那麼成爲專家和全棧的學習時間是相當的。在最開始的時候，我們要在我們的全棧工程和專家都在某個技術領域達到 80 分的水平。
那麼專家，還需要 80% 的時間去深入這個技術領域。而全棧工程師，則可以依賴於這 80% 的時候去開拓四個新的領域：
儘管理論上是如此，但是專家存在跨領域的學習障礙——套用現有模式。而全棧也存在學習障礙——如何成爲專家，但是懂得如何學習新的領域。
解決問題的思路：不同的方式
有意思的是——成爲專家還是成爲全棧，取決於人的天性，這也是兩種不同的性格決定的。成爲管理者還是技術人員看上去就像一種簡單的劃分，而在技術人員裏成爲專家還是全棧就是另外一種劃分。這取決於人們對於一個問題的思考方式：這件事情是藉由外部來解決，還是由內部解決。下面這張圖剛好可以表達我的想法：
而這種思維依據於不同的事情可能會發生一些差異，但是總體上來說是相似的。當遇到一個需要創輪子的問題時，我們就會看到兩種不同的方式。
對於全棧工程師來說，他們喜歡依賴於外部的思維，用於產生顛覆式思維。如 Angular.js 這樣的框架便是例子，前端結合後端開發語言 Java 的思維而產生。而專家則依賴於內部的條件，創造出不一樣的適應式創新。如之前流行的 Backbone 框架，適應當時的情況而產生。
全棧工程師的未來：無棧
全棧工程師本身不應該僅僅侷限於前端和後臺的開發，而可以嘗試去開拓更廣泛的領域——因爲全棧本身是依賴於工程師本身的學習能力，正是這種優秀的學習能力可以讓他們可以接觸更廣泛的知識。
全棧的短板
如果你也嘗試過面試過全棧工程師，你會怎麼去面試他們呢？把你知道的所有的不同領域的問題都拿出來問一遍。是的，這就是那些招聘全棧工程師的公司會問你的問題。
人們以爲全棧工程師什麼都會，這是一個明顯的誤區——然而要改變這個誤區很難。最後，導致的結果是大家覺得全棧工程師的水平也就那樣。換句來說，人們根本不知道什麼是全棧工程師。在平時的工作裏，你的隊伍都知道你在不同領域有豐富的知識。而在那些不瞭解你的人的印象裏，就是猜測你什麼都會。
因此，這就會變成一個罵名，也是一個在目前看來很難改變的問題。在這方面只能儘可能地去了解一些通用的問題，並不能去了解所有的問題。在一次被面試全棧工程師的過程中，有一個面試官準備了幾個不同語言（Javascript、Java、Python、Ruby)的問題來問我，我只想說 Ciao——意大利語：你好！
除了這個問題——人們不瞭解什麼是全棧工程師。還有一個問題，就是剛纔我們說的成爲專家的老大難問題。
無棧
讓我毫不猶豫地選擇當全棧工程師有兩個原因：
- 這個世界充滿了未解的迷，但是我只想解開我感興趣的部分。
- 沒有探索，哪來的真愛？你都沒有探索過世界，你就說這是你最喜歡的領域。
當我第一次看到全棧工程師這個名字的時候，我發現我已然是一個全棧工程師。因爲我的學習路線比較獨特：
中小學：編程語言 -> 高中：操作系統、內核、遊戲編程 -> 大學： 硬件、Web 開發 -> 工作：後端 + 前端
而在當時我對 SEO 非常感興趣，我發現這分析和 Marketing 似乎做得還可以。然後便往 Growth Hacking 發展了：
而這就是全棧學習帶來的優勢，學過的東西多，學習能力就變強。學習能力往上提的同時，你就更容易進入一個新的領域。
從事全棧6年，專門建立的學習Q-q-u-n ⑦⑧④-⑦⑧③-零①② 分享學習方法和需要注意的小細節，互相交流學習，不停更新最新的教程和學習技巧（從零基礎開始到WEB前端項目實戰教程，學習工具，全棧開發學習路線以及規劃）點：學習前端，我們是認真的