后端程序員的成長指南

開篇寄語 —— 彎道超車，為時未晚

前端領(lǐng)域如火如荼，工資水平也水漲船高。作為后端程序員的你，羨慕嗎？但羨慕是沒用的，更別提嫉妒恨了。古人曰：與其臨淵羨魚，不如退而結(jié)網(wǎng)。

接下來，我不但要教你結(jié)網(wǎng)，還要教你后端程序員彎道超車的秘訣。我將對前端領(lǐng)域的概念進(jìn)行簡要說明，并盡量用后端領(lǐng)域的概念來作類比，受到筆者個人背景的限制，可能會更多使用Java世界的概念來進(jìn)行類比，不過.net等世界也大同小異。

筆者就是從后端程序員轉(zhuǎn)型而來，深知阻撓后端程序員轉(zhuǎn)型的那些攔路虎。比如：陌生的工具鏈、陌生的語言、龐雜的W3C標(biāo)準(zhǔn)、不一樣的設(shè)計風(fēng)格、不一樣的編碼風(fēng)格等等，不過最大的攔路虎是……框架太多！每套框架都號稱自己有一系列優(yōu)點，讓人眼花繚亂，無從抉擇。

事實上，對于前端程序員來說，在這些框架之間進(jìn)行選擇確實很困難，因為有時候前端程序員會過于沉迷細(xì)節(jié)。比如，他/她可能在50毫秒和100毫秒的響應(yīng)時間之間舉棋不定，可能會為了實現(xiàn)細(xì)節(jié)上的優(yōu)點，而影響項目管理和可維護(hù)性。最嚴(yán)重的問題可能還在于：誤判了前端需求的增長速度和工程化開發(fā)的重要性，而這正是后端程序員們彎道超車的好時機(jī)。

細(xì)說從頭

以2004年Gmail的推出為起點，前端領(lǐng)域已經(jīng)呈現(xiàn)出爆炸性增長的趨勢，經(jīng)過十多年的成長，它是否即將進(jìn)入停滯期？我只能說“Too young， too naive！”。在Web初興的時候，同樣有編寫傳統(tǒng)桌面應(yīng)用的程序員覺得它會很快成長到停滯期，不過結(jié)果大家都已經(jīng)看到了。在我看來，并不是什么“前端編程技術(shù)”橫空出世了，而是它的需求一直都存在，卻由于技術(shù)條件不足而被壓抑著 —— 直到Web技術(shù)成熟到能把它釋放出來，這才導(dǎo)致了前端橫空出世并急速膨脹的假象。

回憶一下，在“前端”的概念誕生之前，我們是怎樣實現(xiàn)一個Web應(yīng)用的？我們會先在服務(wù)器上合成一段HTML，把它發(fā)回給瀏覽器；之后，幾乎任何操作都會向服務(wù)器發(fā)送一個請求，服務(wù)器再渲染一個完整的新頁面發(fā)回來。

跳出習(xí)慣性思維，反思一下：這是自然的嗎？我們?yōu)槭裁磿枰绱藦?fù)雜的過程？這其實是被迫做出的妥協(xié)：在從Netscape誕生開始的很長時間內(nèi)，瀏覽器中的JS都是一個“玩具語言（這是JS之父說的）”：語法繁雜、坑多、解釋器性能低下、無模塊化機(jī)制、無成熟的工具鏈，無成熟的第三方庫等等，JS程序員（如果當(dāng)時有的話）也毫無懸念的占據(jù)了鄙視鏈的底端。

面對JS這樣一位“豬隊友”，程序員們還能怎么辦？只能求助于萬能的服務(wù)端語言了：它幾乎不會受到瀏覽器的制約，可以自由使用所需的一切編程資源。幸運(yùn)的是，Web技術(shù)的標(biāo)準(zhǔn)化工作在這個過程中得以蹣跚前行，而JS的標(biāo)準(zhǔn)化工作也在三大瀏覽器巨頭的博弈中艱難的前進(jìn)著。

Chrome，特別是V8引擎的誕生，終于結(jié)束了JS解釋器的性能問題，更重要的是，基于V8引擎，誕生了偉大的NodeJS。NodeJS就是前端世界的JRE或.net CLR。它主要有三大貢獻(xiàn)：

讓JS語言“入侵”了后端世界和桌面世界。

這在前端開發(fā)的襁褓期有效擴(kuò)大了JS語言的適用范圍，積累了大量第三方庫，很多第三方庫只要在合適的工具支持下也能在前端領(lǐng)域正常使用。

為前端開發(fā)提供了工具鏈。

如今的前端世界，其工具鏈的復(fù)雜度和完善度已經(jīng)逐漸逼近后端世界，比如：類似于gradle的構(gòu)建工具gulp、grunt，類似于maven的包管理工具npm，類似于junit的測試框架karma等等，它們無一例外，都是基于NodeJS的。

提供了標(biāo)準(zhǔn)化的模塊化方案CommonJS。

在NodeJS誕生之前，模塊化一直是JS世界的短板，雖然也有不少相互競爭的JS模塊化方案，卻都沒能一統(tǒng)江湖，這主要是因為當(dāng)時的很多前端應(yīng)用都過于簡單，對模塊化并沒有迫切需求。而隨著NodeJS入侵到后端世界和桌面世界，模塊化成了不得不做的事情，于是NodeJS內(nèi)置的CommonJS就成為了事實性的標(biāo)準(zhǔn)。JS的最新版本ES6中內(nèi)置的模塊化機(jī)制就是類似于CommonJS的。

與此同時，在另一條戰(zhàn)線上，還有一些技術(shù)在平行推進(jìn)，那就是前端DOM庫與前端框架。在2006年，一個名叫jQuery的DOM庫橫空出世，它封裝了復(fù)雜的、特定于瀏覽器的DOM操縱類API，讓程序員可以不必處理一些繁瑣的細(xì)節(jié)差異，從而簡化了瀏覽器中的DOM編程。

在那個時代，雖然尚未正式提出“前端”的概念，不過已經(jīng)出現(xiàn)了不少事實上的前端程序。但這些前端程序相對于如今包羅萬象的前端還是過于原始了，很多前端代碼都只是嵌入在后端頁面中的龍?zhí)住?/p>

不過，這些程序就像最早爬到岸上的魚一樣，帶人們發(fā)現(xiàn)了一個新世界，對前端程序的需求也隨之井噴。什么是“前端程序”呢？在我看來主要有如下幾個特征：

客戶端渲染

與傳統(tǒng)上借助后端生成新頁面的方式不同，前端程序借助瀏覽器的API來呈現(xiàn)內(nèi)容（也就是“渲染”）并處理用戶動作，在這個過程中，并不需要借助服務(wù)端的運(yùn)算能力，也不需要網(wǎng)絡(luò)。

單頁面

客戶端渲染技術(shù)衍生出的一個主要特征是單頁面應(yīng)用。因為不需要再由服務(wù)器發(fā)回新頁面，所以前端程序在理論上就具備了獨自渲染內(nèi)容并全權(quán)處理用戶交互的能力，只在必要時，才會通過Web API尋求服務(wù)器的幫助。

實時反饋

客戶端渲染技術(shù)衍生出的另一個主要特征是實時反饋。在傳統(tǒng)的應(yīng)用中，除非內(nèi)嵌JS代碼，否則任何反饋都需要由服務(wù)端代碼生成并發(fā)回，而且編程相對復(fù)雜。這導(dǎo)致很少有程序能夠給出實時反饋，即使做到了實時反饋的，也會因為網(wǎng)絡(luò)延遲等問題而損害用戶體驗，而專業(yè)的前端程序則可以借助客戶端運(yùn)算輕松實現(xiàn)實時反饋。

隨著技術(shù)的進(jìn)步，前端終于具備了擺脫“石器時代”的條件，于是，前端的時代終于要開始了。

前端時代！

以jQuery為代表的DOM庫在使用中逐漸暴露出了很多缺點，特別是混雜邏輯代碼和操縱DOM的代碼導(dǎo)致難以維護(hù)。于是一大批新的前端MV*框架悄然出現(xiàn)了。

框架不同于庫：庫是一組被動式的代碼，如果你不調(diào)用它，它就什么都不做；而框架不同，框架提供了啟動、事件處理等各種通用性代碼，你按照框架規(guī)約寫自己的代碼，并把它“告訴”框架，框架會在合適的時機(jī)用合適的方式調(diào)用它們。

確實，這沒什么新鮮的，你早就用過Spring或asp.net了，不是嗎？從這一點上來說，前端框架與后端框架大同小異。不過，前端框架還是有自己的鮮明特色的：

它們是……用JS寫的。

毫無疑問，JS盡管并不完善，但它目前是并且仍將是前端世界的霸主，我認(rèn)為其中最重要的原因是：它是各大瀏覽器廠商利益的最大公約數(shù)。Google曾孵化了一個在瀏覽器和后端共用的語言Dart，不過現(xiàn)在連自己的瀏覽器都不打算直接支持它了。從技術(shù)上講，Dart無疑是相當(dāng)先進(jìn)的，但現(xiàn)實卻更加殘酷。

它們是弱類型的。

受限于JS的能力，前端框架無法訪問運(yùn)行時類型（就像Java或.net中的反射機(jī)制），也就無法像后端框架那樣大量借助接口來定義擴(kuò)展方式。因此，框架只能借助一些復(fù)雜的技巧來達(dá)成目標(biāo)。當(dāng)然，后續(xù)的技術(shù)發(fā)展在一定程度上改變了這一點，那就是微軟的新語言TypeScript的誕生，我們稍后再展開這個話題。

它們是靈活的。

得益于JS的動態(tài)特性和弱類型特性，前端框架也非常靈活，比如你可以把任意對象傳給調(diào)用者，只要這個對象有調(diào)用者所需的屬性或方法即可，而不用像Java那樣明確定義接口。靈活，是優(yōu)點，也是缺點 —— 在小規(guī)模、需求穩(wěn)定的程序中，它可以極大的提高開發(fā)速度，用過Ruby或者Python的程序員大概深有體會；但在大規(guī)模、需求頻繁變化的程序中，它將是BUG之源，用過Ruby或Python的程序員大概深有體會。

那些年，前端MV*庫的競爭，其激烈程度幾乎不下于各種語言的競爭。2009年，一個注定要名聲大噪的框架加入了這場前端MV*大戰(zhàn)，它叫Angular。

Hello， Angular！

Angular的英文原意是“角”，也就是“銳角、直角”的“角”。它的主要開發(fā)者是Adobe Flex的開發(fā)者M(jìn)isko以及很多來自Google的后端程序員，因此它有很多理念和概念來自于Flex和后端編程領(lǐng)域，如聲明式界面（Declarative UI）、服務(wù)（Service）、依賴注入（Dependency Injection）等，并為單元測試提供了優(yōu)秀的支持?？梢哉f，它天生就有后端基因，其設(shè)計目標(biāo)也是處理像傳統(tǒng)后端一樣復(fù)雜的需求。幸運(yùn)或者不幸的是，它仍然是一個前端框架。它具有高度的靈活性 —— 既可以寫得很規(guī)整，也可以寫得很爛。當(dāng)然，在某種意義上，這不應(yīng)該算作Angular的問題，而是JS的“原罪”。

這種情況意味著，如果有成熟的最佳實踐和優(yōu)秀的開發(fā)規(guī)范，Angular程序可以寫得很漂亮：簡潔明了、模塊清晰、分層明確、關(guān)注點分離。但在開發(fā)組意識到社區(qū)需要一份來自官方的開發(fā)規(guī)范之前，Angular 0.x和1.x版本的爛代碼和壞習(xí)慣已經(jīng)泛濫成災(zāi)了。

幸運(yùn)的是，Angular有一個繁榮、強(qiáng)大的社區(qū)，社區(qū)在行動。無論是英文社區(qū)還是中文社區(qū)，都出現(xiàn)了一些優(yōu)秀的Angular工程師，他們總結(jié)出了一些經(jīng)驗和教訓(xùn)，并給出了自己的解決之道，全憑自己的力量與熱情在社區(qū)中傳播。如果你是一個后端程序員，會發(fā)現(xiàn)這些最佳實踐和開發(fā)規(guī)范似曾相識。沒錯，很多優(yōu)秀的Angular工程師本來就是后端工程師出身。這并不奇怪，前端歲月尚淺，優(yōu)秀的前端工程師當(dāng)然會有很多是從優(yōu)秀的后端工程師轉(zhuǎn)型而來的。

但這還不是根本原因。在有些人的思維中，前端和后端好像是兩個截然不同的世界。并非如此！編程之道本來就是互通的，并不存在前端的編程之道和后端的編程之道。主導(dǎo)這兩個開發(fā)領(lǐng)域的設(shè)計原則不外乎就是SOLID等少數(shù)幾個，無論是前端的編程規(guī)范還是后端的編程規(guī)范，都是對這些原則的實例化。

社區(qū)的努力，在一定程度上彌補(bǔ)了Angular早期版本的缺憾，但，這還不夠。我們需要一份官方的開發(fā)規(guī)范，甚至，一個更好的Angular。后者才是重點！

Hello， Angular 2！

優(yōu)秀的框架特性、繁榮的社區(qū)、廣泛的應(yīng)用，但都被ES5（JS的早期版本）這個豬隊友給拖累了，另一個豬隊友則是老版本瀏覽器 —— 特別是IE8及更低的版本。于是，就在Angular 1.x如日中天的時候，Angular開發(fā)組高調(diào)開始了新版本的開發(fā)工作，它就是Angular 2！這里還有很多小插曲按下不表，等我有時間開雜談時再慢慢說。

Angular 2本身不再是用ES5寫成的，而是TypeScript，簡稱TS。TS是微軟開發(fā)的一個新語言，它是ES6的超集，這意味著，凡是有效的ES6代碼都同樣是有效的TS代碼；另一方面，ES6是ES5的超集，所以凡是有效的ES5代碼也同樣是有效的TS代碼。但是在ES6的基礎(chǔ)上，TS增加了可選的類型系統(tǒng)以及在未來ES8中才會出現(xiàn)的裝飾器等特性。

你想知道TS為什么這么牛？很簡單，因為他爸是 —— 不，不，不是李剛，他爸是Anders Hejlsberg，如果Java程序員沒聽說過他還情有可原，如果是.net程序員，那就自己去面壁思過吧 —— 他是微軟.net的總架構(gòu)師，C#語言之父，更資深的程序員可能還用過Delphi，那是Anders的“長子”。一個人設(shè)計了三個流行的工業(yè)級語言，也真是夠了。

雖然TS已經(jīng)誕生了很久，但卻一直沒有流行起來，這主要是因為它還缺少一個“殺手級應(yīng)用”?，F(xiàn)在，Angular 2來了！

在擺脫了一個豬隊友之后，Angular 2終于可以隨心所欲的展示自己的風(fēng)采了，比如：基于類型的依賴注入、強(qiáng)類型的庫文件、更加便捷的語法、標(biāo)準(zhǔn)化的模塊化機(jī)制等等，無法一一列舉。

但還有另一個豬隊友在拖后腿，那就是老式瀏覽器，對，說的就是你 —— IE 8！Angular從1.3開始就徹底拋棄了它，2.x就更不用說了。有一陣子，曾經(jīng)傳言Angular 2不支持IE 11以下所有版本的IE，不過幸好，Angular開發(fā)組終于對現(xiàn)實做出了妥協(xié)，否則這又會是一個重大的公關(guān)危機(jī)了。能與IE 8說再見，真好。不過，這也意味著，當(dāng)你準(zhǔn)備開始用Angular 2做項目的時候，務(wù)必先跟客戶或產(chǎn)品經(jīng)理敲定不需要支持IE 8，否則還是老老實實用Angular 1.2吧。

Angular 2，后端之友

在Angular 1中就從后端借鑒過很多概念，到Angular 2自然就更進(jìn)一步了。這些概念對沒有做過后端開發(fā)的新前端來說會有一定的難度，不過對后端程序員來說這不過是小菜一碟。接下來我們就逐個講講。

服務(wù)與依賴注入

沒錯，它們跟后端的服務(wù)與依賴注入是同一個概念，只是在實現(xiàn)細(xì)節(jié)上略有不同：

后端的服務(wù)是一個單例，在Angular 2中同樣如此；

后端的服務(wù)是使用類型來注入的，在Angular 2中同樣如此，不過由于TS的限制，Angular 2中通常會根據(jù)類進(jìn)行注入，而不是像傳統(tǒng)的后端程序那樣優(yōu)先使用接口；

后端的依賴注入器是由框架提供的，Angular 2中同樣如此；

后端的依賴可以進(jìn)行配置，Angular 2中同樣如此，不過它的配置方式更加靈活，它不需要單獨的配置文件（該死的XML），而是直接用程序代碼，這賦予了它額外的靈活性，卻幾乎沒有損失（這讓我想起了Grails）。

不過Angular 2的依賴注入體系比傳統(tǒng)的后端更加靈活，它是一棵由多個注入器組成的樹，這棵樹跟組件樹平行存在。你可以把局部使用的服務(wù)放在中下層節(jié)點上，來限制它的作用范圍，減小耦合度；你可以預(yù)留一些占位（Placeholder）服務(wù)，等待調(diào)用方實現(xiàn)它，以達(dá)到“用組合代替繼承”的效果（要了解詳情，請自行分析LocationStrategy的設(shè)計）；可以在不同的層級上配置同一個類的不同依賴實例，這樣它就可以覆蓋掉上層的配置，在必要時臨時建立一個“獨立王國”。

可選強(qiáng)類型

強(qiáng)類型是很多Java程序員信心的保障，但同時也因為過于繁瑣而飽受抨擊。

現(xiàn)在，它隨著TS又來到了前端世界。不過不用害怕Java世界中的悲劇重演，因為TS中的強(qiáng)類型是“可選”強(qiáng)類型。這意味著你可以完全不定義變量、屬性、參數(shù)等的數(shù)據(jù)類型，TS編譯器也會照樣放行。當(dāng)你需要快速建立一個原型時，這種特性會非常有用，因為你不用現(xiàn)在就做很多決策。但當(dāng)有一天你的原型經(jīng)歷了從產(chǎn)品經(jīng)理到CEO的重重考驗，終于修成正果的時候，你會發(fā)現(xiàn)它“太爛”了。

這是好事，這說明你在開發(fā)過程中沒有浪費精力。但如果你想繼續(xù)像這樣把它發(fā)展成一個產(chǎn)品級應(yīng)用，那就要悲劇了。因為代碼中有太多只有你自己知道的約定和隱式接口，但新過來和你進(jìn)行合作開發(fā)的人是無法和你心靈相通的。用不了多久，本來就是一團(tuán)面條的代碼就變成了一坨漿糊，然后你就開始了無止境的加班歲月。沒錯，“福兮禍之所依”，現(xiàn)實就是這么殘酷。

為了走得更遠(yuǎn)，你先得為代碼中的變量、屬性、參數(shù)等標(biāo)上數(shù)據(jù)類型、抽象出接口，并且基于它們建立相應(yīng)的開發(fā)規(guī)范（最好能用持續(xù)集成（CI）工具進(jìn)行保障）。有了這些，即使是兩個負(fù)情商的大老爺們兒也能輕松做到“心靈相通”了。

加完類型之后，你仿佛回到了自己所熟悉的后端領(lǐng)域?，F(xiàn)在，你的地盤兒，你做主！

測試驅(qū)動開發(fā)

如果測試驅(qū)動開發(fā)還不是你的基本功，那可能說明你在后端開發(fā)方面還有短板。即使你不是想做全棧，而是想完全轉(zhuǎn)型成前端，也應(yīng)該補(bǔ)習(xí)一下測試驅(qū)動開發(fā)的技能。因為未來的前端開發(fā)，即使在純邏輯類代碼的復(fù)雜度上都可能會趕上后端。

在1.x的時代，Angular就以其優(yōu)秀的“可測試性”而著稱了，Angular 2當(dāng)然不會放棄這個傳統(tǒng)優(yōu)勢。Angular 2的單元測試更加簡單，我還是直說吧：Angular 2中單元測試的方式更像后端。在Angular 1.x的時代，單元測試中不得不使用諸如$controller（如果你不懂，請忽略它）等框架內(nèi)部API，而Angular 2測試框架的設(shè)計中完全封裝了它們，當(dāng)你測試一個組件時，大部分時候幾乎就是在測試一個普通的類。

傳統(tǒng)的前端程序員可能不太容易理解測試驅(qū)動開發(fā)的思維方式，特別是對于沒有什么后端經(jīng)驗的資深前端。這也同樣是后端程序員實現(xiàn)彎道超車的好機(jī)會。隨著前端職責(zé)的加重，在前端代碼中，會出現(xiàn)越來越多的復(fù)雜邏輯，這些復(fù)雜邏輯如果沒有測試驅(qū)動開發(fā)的保障，將被迫用“寫代碼、切換到瀏覽器、界面上點點看看、切換回IDE”的低效循環(huán)進(jìn)行開發(fā)。

更重要的是，它很容易誕生高度耦合、恰好能用的爛代碼。但在測試驅(qū)動開發(fā)的保障下，可以先從最簡單的規(guī)約開始，逐步補(bǔ)充更多規(guī)約。在開發(fā)過程中，你只要不時瞥一眼IDE的測試控制臺就可以了。這樣不但開發(fā)起來更快，而且可以收獲良好的代碼結(jié)構(gòu)，因為容易測試的代碼通常也都是松耦合的。

分工，1+1 》 2

后端程序員學(xué)習(xí)前端技術(shù)時，往往會為HTML/CSS等頭疼不已，這些都是相對陌生甚至完全陌生的領(lǐng)域，如果急于為團(tuán)隊貢獻(xiàn)生產(chǎn)力，那么請把這些“后背”交給你的隊友。

延續(xù)Angular的一貫傳統(tǒng)，Angular 2對團(tuán)隊分工提供了卓越的支持，它通常會把一個界面分成模板（*.html、*.jade）、樣式（*.css、*.scss、*.less、*.styl）、組件（*.js、*.ts）和組件單元測試（*.spec.ts、*.spec.js）等幾個基本名（base name）相同的文件，它們被放在獨立文件中但能很好的相互協(xié)作。

當(dāng)你的前端技能還在蹣跚學(xué)步的時候，請放心的寫下一些粗糙的HTML/CSS代碼，比如用div搭建出丑陋但能與你所寫的組件順暢協(xié)作的html文件。然后，提交它，等你的隊友幫你把它修成漂亮的產(chǎn)品級界面。同樣的，如果你的前端隊友還不太清楚該如何干凈漂亮的從組件中抽取出服務(wù)，那么你就可以放心的幫他/她修改組件代碼，而不用擔(dān)心無意間破壞了模板和樣式。

一個團(tuán)隊中，如果能有謙遜的super star當(dāng)然好，但這種團(tuán)隊是可遇而不可求的，更現(xiàn)實的期望是一個能相互信任、各盡所能的團(tuán)隊。而Angular在設(shè)計時就充分考慮了團(tuán)隊分工的需求，要想建設(shè)這樣一個團(tuán)隊，毫無疑問，Angular將是你的首選平臺！

結(jié)束語 —— Angular 2，全棧養(yǎng)成計劃

好吧，我承認(rèn)我可恥的做了一次標(biāo)題黨。本文并非在煽動后端程序員去革前端程序員的命，而是希望無論是前端程序員還是后端程序員，都能成長為優(yōu)秀的全棧程序員（是的，前端程序員如果理解了Angular 2中的這些概念也會更容易向后端發(fā)展）。全棧程序員由于能有效節(jié)省溝通成本（比如不用頻繁協(xié)商API）而被很多開發(fā)組織寄予厚望，但真正培養(yǎng)起來可沒那么容易。

有一陣子，培養(yǎng)全棧程序員的期望被放在了Fullstack JavaScript上 —— 它既能寫前端程序又能寫后端程序還能寫桌面程序。不過事實證明，這種期望落空了。即使經(jīng)過了大爆發(fā)，NodeJS在企業(yè)應(yīng)用開發(fā)、大數(shù)據(jù)等領(lǐng)域的資源積累也遠(yuǎn)遠(yuǎn)不及Java、C#、Python，甚至將來還有被新崛起的Scala和Go超越的危險。

或許我們應(yīng)該換一種思路了：全棧一定要用同一種語言寫前端和后端嗎？

并非如此。事實上，我們更應(yīng)該看重的是編程模型、思維方式和協(xié)作模式等方面的復(fù)用，而語言層面只是細(xì)枝末節(jié)而已。所以，Java或C#，加上TS與Angular 2，給了培養(yǎng)全棧的新曙光。相似的概念模型、相似的思維方式、相似的協(xié)作模式，這才是全棧程序員真正的核心技能，與語言無關(guān)。

這些，才是Angular 2給專業(yè)開發(fā)團(tuán)隊帶來的，最珍貴的禮物！

責(zé)任編輯：wv