謹以此文獻給每個爲成爲優秀全棧工程師奮鬥的人。前端
節選自《Growth: 全棧增加工程師指南》git
技術在過去的幾十年裏進步很快,也將在將來的幾十年裏發展得更快。今天技術的門檻降低得愈來愈快,本來須要一個團隊作出來的Web應用,如今只須要一兩我的就能夠了。github
同時,因爲公司組織結構的變遷,以及到變化的適應度,也決定了賦予每一個人的職責將會愈來愈多。儘管咱們看到工廠化生產帶來的優點,可是咱們也看到了精益思想帶來的變革。正是這種變革讓愈來愈多的專家走向全棧,讓組織內部有更好的交流。面試
你還將看到專家和全棧的兩種不一樣的學習模式,以及全棧工程師的將來。編程
技術的革新史後端
從開始的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發展了:
而這就是全棧學習帶來的優點,學過的東西多,學習能力就變強。學習能力往上提的同時,你就更容易進入一個新的領域。
參考書籍
更多內容歡迎關注個人微信公衆號(搜索Phodal):