開(kāi)篇寄語(yǔ) —— 彎道超車，為時(shí)未晚

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

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

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

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

細(xì)說(shuō)從頭

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

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

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

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

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

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

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

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

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

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

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

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

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

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

客戶端渲染

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

單頁(yè)面

客戶端渲染技術(shù)衍生出的一個(gè)主要特征是單頁(yè)面應(yīng)用。因?yàn)椴恍枰儆煞?wù)器發(fā)回新頁(yè)面，所以前端程序在理論上就具備了獨(dú)自渲染內(nèi)容并全權(quán)處理用戶交互的能力，只在必要時(shí)，才會(huì)通過(guò)Web API尋求服務(wù)器的幫助。

實(shí)時(shí)反饋

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

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

前端時(shí)代！

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

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

確實(shí)，這沒(méi)什么新鮮的，你早就用過(guò)Spring或asp.net了，不是嗎？從這一點(diǎn)上來(lái)說(shuō)，前端框架與后端框架大同小異。不過(guò)，前端框架還是有自己的鮮明特色的：

它們是……用JS寫的。

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

它們是弱類型的。

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

它們是靈活的。

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

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

Hello， Angular！

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

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

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

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

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

Hello， Angular 2！

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

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

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

雖然TS已經(jīng)誕生了很久，但卻一直沒(méi)有流行起來(lái)，這主要是因?yàn)樗€缺少一個(gè)“殺手級(jí)應(yīng)用”。現(xiàn)在，Angular 2來(lái)了！

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

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

Angular 2，后端之友

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

服務(wù)與依賴注入

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

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

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

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

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

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

可選強(qiáng)類型

強(qiáng)類型是很多Java程序員信心的保障，但同時(shí)也因?yàn)檫^(guò)于繁瑣而飽受抨擊。

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

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

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

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

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

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

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

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

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

分工，1+1 》 2

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

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

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

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

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

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

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

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

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

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

責(zé)任編輯：wv