爲何將來是全棧project師的世界？

謹以此文獻給每一個爲成爲優秀全棧project師奮鬥的人。

節選自《Growth: 全棧增加project師指南》

技術在過去的幾十年裏進步很是快，也將在將來的幾十年裏發展得更快。

今天技術的門檻降低得愈來愈快，本來需要一個團隊作出來的Web應用。現在僅僅需要一兩我的就可以了。

同一時候，因爲公司組織結構的變遷，以及到變化的適應度，也決定了賦予每一個人的職責將會愈來愈多。雖然咱們看到工廠化生產帶來的優點。但是咱們也看到了精益思想帶來的變革。正是這種變革讓愈來愈多的專家走向全棧，讓組織內部有更好的交流。

你還將看到專家和全棧的兩種不一樣的學習模式，以及全棧project師的將來。

技術的革新史

從開始的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等等。固然，這也不是一篇關於怎樣實踐敏捷的文章。

敏捷與瀑布式開發在很是大的差異就是：溝通問題。傳統的軟件開發在調研完畢後就是分析、開發等等。

而敏捷開發則會強調這個過程當中的溝通問題：

在整個過程當中都不斷地強調溝通問題，然而這時還存在一個問題：組織結構自己的問題。

這種組織結構，例如如下圖所看到的：

假設市場部門/產品經理沒有與研發團隊坐一塊兒來分析問題，那麼問題就多了。當一個需求在實現的過程當中遇到問題，到底是哪一個部門的問題？

相同的假設咱們的研發部門是這樣子的結構：

那麼在研發、上線的過程當中仍然會遇到各類的溝通問題。

現在，讓咱們回過頭來看看大公司的專家與小公司的全棧。

大公司的專家與小公司的全棧

假設你經常看一些關於全棧和專家的技術文章的時候。你就會發現不一樣的人在強調不一樣的方向。

大公司的文章喜歡強調成爲某個領域的專家。小公司喜歡小而美的團隊——全棧project師。

如咱們所見的：大公司和小公司都在解決不一樣類型的問題。大公司要解決性能問題，小公司都活下去需要依賴於近乎全能的人。並且，大公司和小公司都在加班。

假設從這種意義上來講。咱們可以發現事實上大公司是在剝削勞動力。

專家

咱們所見到的那些關於技術人員應該成爲專家的文章，多數是已經成爲某個技術領域裏的專家寫的文章。並且咱們可以發現很是有意思的一點是：他們都是管理者。

管理者出於招聘的動機。所以更需要細分領域的專家來幫助他們解決這個問題。

全棧

相似的，咱們所看到的那些關於成爲全棧project師的文章，多數是初創公司的CTO寫的。而這些初創公司的CTO也多數是全棧project師，他們需要招聘全棧project師來幫助他們解決這個問題。

兩種不一樣的學習模型

而不知你是否也注意到一點：專家們也在強調「一專多長」。因爲單純依靠於一個領域的技術而存在的專家已經很是少了，技術專家們不得不根據於公司的需求去開拓不一樣的領域。畢竟「公司是指所有資本由股東出資構成。以營利爲目的而依法設立的一種企業組織形式；」。管理人們假設技術自己是相通的，既然你在技術領域裏有至關高的長板，那麼進入一個新的技術也不是一件難的事。

做爲一個技術人員，咱們是這個領域中的某個子領域專家。

而做爲這樣一個專家。咱們要擴展向另一個領域的學習也不是一件很是難的事。

借鑑於咱們先前的學習經驗，咱們可以很是快的掌握這個新子域的知識。

如咱們所見，咱們可以很是快地補齊圖中的短板：

在近來的探索中發現有一點很是有意思：假設依賴於20/80法則的話，那麼成爲專家和全棧的學習時間是至關的。在最開始的時候。咱們要在咱們的全棧project和專家都在某個技術領域達到80分的水平。

那麼專家。還需要80%的時間去深刻這個技術領域。而全棧project師，則可以依賴於這80%的時候去開拓四個新的領域：

雖然理論上是如此，但是專家存在跨領域的學習障礙——套用現有模式。

而全棧也存在學習障礙——怎樣成爲專家，但是懂得怎樣學習新的領域。

解決這個問題的思路：不一樣的方式

有意思的是——成爲專家仍是成爲全棧，取決於人的天性，這也是兩種不一樣的性格決定的。成爲管理者仍是技術人員看上去就像一種簡單的劃分，而在技術人員裏成爲專家仍是全棧就是第二種劃分。這取決於人們對於一個問題的思考方式：這件事情是藉由外部來解決，仍是由內部解決。如下這張圖恰好可以表達個人想法：

而這種思惟根據於不一樣的事情可能會發生一些差別。但是總體上來講是相似的。當遇到一個需要創輪子的問題時，咱們就會看到兩種不一樣的方式。

對於全棧project師來講，他們喜歡依賴於外部的思惟。用於產生顛覆式思惟。

如Angular.js這種框架即是樣例，前端結合後端開發語言Java的思惟而產生。

而專家則依賴於內部的條件，創造出不同的適應式創新。如以前流行的Backbone框架，適應當時的狀況而產生。

全棧project師的將來：無棧

全棧project師自己不該該僅僅侷限於前端和後臺的開發。而可以嘗試去開拓更普遍的領域——因爲全棧自己是依賴於project師自己的學習能力。正是這種優秀的學習能力可以讓他們可以接觸更普遍的知識。

全棧的短板

假設你也嘗試過面試過全棧project師。你會怎麼去面試他們呢？把你知道的所有的不一樣領域的問題都拿出來問一遍。

是的，這就是那些招聘全棧project師的公司會問你的問題。

人們覺得全棧project師什麼都會，這是一個明顯的誤區——然而要改變這個誤區很是難。最後。致使的結果是你們認爲全棧project師的水平也就那樣。

換句來講。人們根本不知道什麼是全棧project師。

在平時的工做裏，你的隊伍都知道你在不一樣領域有豐富的知識。而在那些不瞭解你的人的印象裏，就是推測你什麼都會。

所以。這就會變成一個罵名，也是一個在眼下看來很是難改變的問題。

在這方面僅僅能儘量地去了解一些通用的問題，並不能去了解所有的問題。

在一次被面試全棧project師的過程當中，有一個面試官準備了幾個不一樣語言（Javascript、Java、Python、Ruby)的問題來問我，我僅僅想說Ciao——意大利語：你好！

除了這個問題——人們不瞭解什麼是全棧project師。另外一個問題，就是剛纔咱們說的成爲專家的老大難問題。

無棧

讓我絕不猶豫地選擇當全棧project師有兩個緣由：

1. 這個世界充滿了未解的迷，但是我僅僅想解開我感興趣的部分。

2. 沒有探索，哪來的真愛？你都沒有探索過世界。你就說這是你最喜歡的領域。

當我第一次看到全棧project師這個名字的時候，我發現我已然是一個全棧project師。

因爲個人學習路線比較獨特：

中小學：編程語言 -> 高中：操做系統、內核、遊戲編程 -> 大學： 硬件、Web開發 -> 工做：後端 + 前端

而在當時我對SEO很是感興趣。我發現這分析和Marketing彷佛作得還可以。而後便往Growth Hacking發展了：

而這就是全棧學習帶來的優點，學過的東西多，學習能力就變強。學習能力往上提的同一時候，你就更easy進入一個新的領域。

參考書籍

• 《精益企業： 高效能組織怎樣規模化創新》
• 《企業應用架構模式》
• 《敏捷軟件開發》
• 《技術的本質》

不少其它內容歡迎關注個人微信公衆號(搜索Phodal)：