不記得從什么時(shí)候起，“生態(tài)環(huán)境”這個(gè)詞經(jīng)常出現(xiàn)在人們耳邊，而在IT行業(yè)中似乎出現(xiàn)頻率更高——所有的巨頭公司都在建設(shè)或運(yùn)營(yíng)自己的“生態(tài)環(huán) 境”，要形成“閉環(huán)”。那么對(duì)前端開(kāi)發(fā)來(lái)講，是否也需要有一套自己的生態(tài)環(huán)境形成一個(gè)閉環(huán)呢？那前端開(kāi)發(fā)的生態(tài)環(huán)境和閉環(huán)又應(yīng)該是什么樣的呢？

過(guò)去很長(zhǎng)一段時(shí)間，我們都在探索適合自己團(tuán)隊(duì)的發(fā)展之路，建立大家共同認(rèn)可的愿景和發(fā)展目標(biāo)等。這時(shí)，首先要明確的就是，團(tuán)隊(duì)的追求和價(jià)值觀是什么。最初， 每次制定全年或季度的工作計(jì)劃時(shí)，除和具體業(yè)務(wù)相關(guān)的工作外，還會(huì)出現(xiàn)提高工程質(zhì)量、提高開(kāi)發(fā)效率等這樣的任務(wù)。隨著時(shí)間推移，我們發(fā)現(xiàn)如果前端工程師的 工作目標(biāo)是讓前端工程師們能更好地工作，那么就陷入了一個(gè)死循環(huán)，因?yàn)檫@個(gè)目標(biāo)很難被具體化，也很難將前端工程師真正的價(jià)值體現(xiàn)在目標(biāo)中。經(jīng)過(guò)一段時(shí)間的 探索，我們嘗試從所參與的產(chǎn)品本身出發(fā)制定工作目標(biāo)，這樣“提高工程質(zhì)量”、“提高開(kāi)發(fā)效率”就變成了過(guò)程，產(chǎn)品的進(jìn)步就代表前端工程師的工作產(chǎn)生了價(jià)值。

實(shí)踐后發(fā)現(xiàn)這個(gè)方向是正確的，因?yàn)闊o(wú)論團(tuán)隊(duì)內(nèi)部在做什么都只是手段和途徑，而產(chǎn)品本身的改進(jìn)證明目的達(dá)到了。進(jìn)而我們開(kāi)始嘗試將整個(gè)過(guò) 程系統(tǒng)化，于是就提到了開(kāi)頭所說(shuō)的前端開(kāi)發(fā)的生態(tài)環(huán)境和閉環(huán)。如果按照環(huán)境將前端工程師工作的平臺(tái)進(jìn)行劃分，將會(huì)是開(kāi)發(fā)環(huán)境、服務(wù)器和瀏覽器三個(gè)在物理上 互相隔離的點(diǎn)，而通過(guò)一系列工具、平臺(tái)和方法論，就能將這三個(gè)孤立的點(diǎn)串聯(lián)起來(lái)，形成一個(gè)整體（如圖1所示）。

圖1 前端生態(tài)環(huán)境形成的閉環(huán)

通過(guò)這個(gè)閉環(huán)，特別是從瀏覽器回到開(kāi)發(fā)環(huán)境這個(gè)環(huán)節(jié)，前端工程師會(huì)通過(guò)具體產(chǎn)品和終端用戶進(jìn)行頻繁的信息交換，在最終的產(chǎn)品中進(jìn)行信息收集，再將信息轉(zhuǎn)化為指標(biāo)或其他能夠衡量產(chǎn)品質(zhì)量的形式，以此指導(dǎo)工作方向。

打造前端研發(fā)生態(tài)環(huán)境

接下來(lái)，按階段將整個(gè)過(guò)程落實(shí)到具體的工程實(shí)現(xiàn)上，最終的產(chǎn)出是一套完整的工具、平臺(tái)和方法論。

從開(kāi)發(fā)環(huán)境到服務(wù)器

開(kāi) 發(fā)環(huán)境是一切工作的開(kāi)始，每一行代碼都是從這里出發(fā)最終deliver給終端用戶的，并不涉及到具體業(yè)務(wù)或產(chǎn)品。當(dāng)團(tuán)隊(duì)人數(shù)增加、項(xiàng)目規(guī)模和數(shù)量開(kāi)始膨脹 時(shí)，很多日常的開(kāi)發(fā)和發(fā)布操作就會(huì)占用工程師很多的時(shí)間和精力，而這些工作通常又是機(jī)械式重復(fù)的。為了解決效率問(wèn)題，自動(dòng)化是必然的方案。這個(gè)環(huán)節(jié)中大部 分的問(wèn)題抽象后都是工程問(wèn)題，也就是通常所說(shuō)的前端持續(xù)集成（CI）。合理的CI過(guò)程可以有效提高開(kāi)發(fā)效率和工程質(zhì)量，提供快速且可靠的持續(xù)交付能力。目 前，豌豆實(shí)驗(yàn)室的前端CI過(guò)程如圖2所示。

圖2 豌豆實(shí)驗(yàn)室的前端CI過(guò)程

其中包含了以下環(huán)節(jié)：

• 版本管理，保證代碼安全和協(xié)同工作的效率；
• on-save或pre-commit檢查，包括lint和code style檢查；
• Code Review；
• 自動(dòng)化測(cè)試；
• 自動(dòng)化構(gòu)建；
• 自動(dòng)化部署。

工程在開(kāi)發(fā)環(huán)境進(jìn)行簡(jiǎn)單的提交前檢查，如靜態(tài)分析和簡(jiǎn)單的測(cè)試，然后提交到代碼托管服務(wù)，通過(guò)Code Review后合并入庫(kù)，進(jìn)行完整的自動(dòng)測(cè)試，最后根據(jù)需要發(fā)布到測(cè)試或生產(chǎn)環(huán)境。

整 個(gè)流程的核心工具是Grunt。Grunt是一個(gè)基于Node.js的任務(wù)管理和調(diào)度工具，最初是完全按照前端開(kāi)發(fā)的需求打造的，但得益于其強(qiáng)大的擴(kuò)展 性，現(xiàn)在也可以被用于其他類型的工程。Grunt的核心是Gruntfile.js文件，其中預(yù)留了眾多諸如測(cè)試、構(gòu)建、部署等任務(wù)入口，可以在各個(gè)階段 中按需調(diào)用。

對(duì)于中小型團(tuán)隊(duì)來(lái)講，合理利用開(kāi)源項(xiàng)目和第三方服務(wù)可以有效降低在這個(gè)環(huán)節(jié)上的投入。同時(shí)，因?yàn)楣こ套詣?dòng)化要求同種工程的結(jié)構(gòu)等都是相近的，這也是一個(gè)將對(duì)工程進(jìn)行規(guī)范化的契機(jī)，通過(guò)Yeoman或類似的工具可以實(shí)現(xiàn)這個(gè)目的。

服務(wù)器到瀏覽器

經(jīng)過(guò)前面提到的CI，工程就被發(fā)布到了線上服務(wù)器，可以分發(fā)給終端用戶了。服務(wù)器在整個(gè)閉環(huán)中起到的是承上啟下的作用，其中很多工作都是離前端工程師的傳統(tǒng)認(rèn)知比較遠(yuǎn)的內(nèi)容，主要包括：

• 負(fù)載均衡；
• 靜態(tài)資源管理；
• CDN自動(dòng)化管理；
• Cache策略管理；
• 線上服務(wù)性能指標(biāo)監(jiān)控；
• 安全防護(hù)。

從 傳統(tǒng)的技術(shù)團(tuán)隊(duì)合作分工來(lái)看，這一部分內(nèi)容通常是由運(yùn)維工程師來(lái)完成的。但我們發(fā)現(xiàn)由于服務(wù)器和瀏覽器之間的信息交換的暢通和效率將會(huì)直接影響產(chǎn)品在某些 方面的體驗(yàn)，所以其中某些部分也是可以被前端工程師納入到工作內(nèi)容當(dāng)中的，或者是可以基于前端的需求進(jìn)行調(diào)整和優(yōu)化的，主要集中在加載速度和可靠性以及安 全三個(gè)方面。

這個(gè)過(guò)程需要和運(yùn)維團(tuán)隊(duì)緊密配合，要求對(duì)方提供統(tǒng)一、與業(yè)務(wù)無(wú)關(guān)且可編程的配置接口，將服務(wù)規(guī)范化。例如，某工程的靜態(tài)資源在CDN上的過(guò)期規(guī)則，可在工程的配置文件中進(jìn)行描述，在發(fā)布時(shí)自動(dòng)通過(guò)CDN或CDN源站提供的API進(jìn)行操作。

業(yè)務(wù)層的安全防護(hù)也應(yīng)該在這個(gè)環(huán)節(jié)中考慮進(jìn)來(lái)，例如統(tǒng)一的跨站腳本防御策略、API的CORS應(yīng)用策略和CSP規(guī)則等，都應(yīng)該由前端來(lái)驅(qū)動(dòng)進(jìn)行制定和實(shí)施。

瀏覽器到開(kāi)發(fā)環(huán)境

瀏覽器是前端工程師的主場(chǎng)，大部分的工作最終都把瀏覽器當(dāng)作運(yùn)行環(huán)境，因此這個(gè)點(diǎn)也是最重要的。在這個(gè)點(diǎn)上主要包含以下工作內(nèi)容：

• 客戶端性能監(jiān)控；
• 異常捕獲與收集；
• 用戶行為跟蹤與統(tǒng)計(jì)；
• 用戶反饋收集。

可 以概括地分為工程數(shù)據(jù)和用戶數(shù)據(jù)收集兩大部分。工程數(shù)據(jù)是用來(lái)監(jiān)控產(chǎn)品的性能指標(biāo)和異常情況的，進(jìn)而有針對(duì)性地進(jìn)行性能調(diào)優(yōu)和Bug修復(fù)，而產(chǎn)品數(shù)據(jù)則是 用來(lái)分析用戶的需求指導(dǎo)產(chǎn)品功能改進(jìn)的。除了配套的統(tǒng)計(jì)工具外，也要能從這些數(shù)據(jù)當(dāng)中轉(zhuǎn)化有意義的信息，同時(shí)，以這個(gè)點(diǎn)為基礎(chǔ)，不停地改進(jìn)整個(gè)循環(huán)。

響應(yīng)速度也是一個(gè)需要重點(diǎn)考量的目標(biāo)，無(wú)論是線上產(chǎn)品的異常還是性能退化的發(fā)生，或者某個(gè)功能設(shè)計(jì)失誤導(dǎo)致用戶使用出現(xiàn)嚴(yán)重問(wèn)題，都應(yīng)該能在這個(gè)流程中快速反饋回來(lái)進(jìn)行快速響應(yīng)，將損失降到最低。同時(shí)，在正常的開(kāi)發(fā)過(guò)程中，響應(yīng)速度快也能夠提高產(chǎn)品本身的迭代速度。

同 樣，在這個(gè)環(huán)節(jié)也有很多第三方服務(wù)可以使用，最常用的就是Google Analytics了，可以提供性能跟蹤、用戶行為統(tǒng)計(jì)、事件統(tǒng)計(jì)等常見(jiàn)的網(wǎng)站數(shù)據(jù)分析服務(wù)。除此之外，還可以使用SpeedCurve來(lái)對(duì)加載性能進(jìn)行 針對(duì)性的跟蹤和分析，使用Roolba或Appfial服務(wù)來(lái)收集運(yùn)行時(shí)異常。

以工具為基礎(chǔ)，工程師就可以對(duì)產(chǎn)品最終運(yùn)行的情況有更形象和具體的認(rèn)知。例如，當(dāng)我們對(duì)加載速度進(jìn)行優(yōu)化時(shí)，就可以看到點(diǎn)擊率的上升或跳出率的下降，因此這些指標(biāo)就可以坐為我們制定工作目標(biāo)的標(biāo)準(zhǔn)。

閉環(huán)

到這里，一個(gè)完整的前端開(kāi)發(fā)生態(tài)環(huán)境就形成了一個(gè)閉環(huán)。以此為基礎(chǔ)，前端工程師只要將大部分精力放在最后一個(gè)環(huán)節(jié)，就可以快速地改進(jìn)產(chǎn)品，讓工作最終以產(chǎn)品本身為導(dǎo)向來(lái)進(jìn)行�；剡^(guò)頭來(lái)，總結(jié)一下在這個(gè)過(guò)程中的幾個(gè)原則。

從前端開(kāi)發(fā)的角度看問(wèn)題

這個(gè)生態(tài)環(huán)境當(dāng)中，很多內(nèi)容都是和產(chǎn)品設(shè)計(jì)、運(yùn)維等其他工作有交叉的，并不是說(shuō)前端工程師要把更多相關(guān)的工作納入進(jìn)來(lái)，而是要能從自己的角度對(duì)同一個(gè)問(wèn)題有不同的看法和解決方案，這樣才能發(fā)揮出前端更貼近用戶的優(yōu)勢(shì)。

其 實(shí)這個(gè)研發(fā)閉環(huán)的打造過(guò)程沒(méi)有任何的新內(nèi)容，都是每個(gè)前端工程師日常工作的一部分，區(qū)別在于從系統(tǒng)化的角度將它們串在一起了。這個(gè)閉環(huán)中，最重要的是最后 從瀏覽器回到開(kāi)發(fā)環(huán)境的過(guò)程，但數(shù)據(jù)的收集和分析工作在不同的公司組織架構(gòu)下可能是由其他角色來(lái)完成的，如數(shù)據(jù)挖掘工程師或者產(chǎn)品經(jīng)理等。但我們相信，由 于前端工程師的特殊工作性質(zhì)，使其能夠同時(shí)從工程和用戶兩個(gè)角度觀察產(chǎn)品，那么也會(huì)有自己獨(dú)特的解決問(wèn)題的方式和途徑。這個(gè)生態(tài)環(huán)境是為了能以產(chǎn)品為中心 指導(dǎo)工作而進(jìn)行的基礎(chǔ)建設(shè)，本質(zhì)上也只是一個(gè)工具，如何利用好它，需要整個(gè)團(tuán)隊(duì)進(jìn)行長(zhǎng)期的探索和磨合。

不重新發(fā)明輪子

對(duì) 于團(tuán)隊(duì)來(lái)講，快速、準(zhǔn)確地解決問(wèn)題，滿足需求是唯一目標(biāo)，因此當(dāng)遇到問(wèn)題時(shí)首先要仔細(xì)分析真實(shí)需求到底是什么。需求明確后，就涉及到具體的實(shí)現(xiàn)方案設(shè)計(jì)和 技術(shù)選型等工程方面的決策，開(kāi)源項(xiàng)目或者合適的第三方服務(wù)依然是首選，原因有三。首先，也是最重要的，投入產(chǎn)出比。在整個(gè)閉環(huán)的打造過(guò)程當(dāng)中，會(huì)用到無(wú)數(shù) 的工具和服務(wù)，其中每一個(gè)的復(fù)雜度都是非常高的，如果自己從零開(kāi)發(fā)，時(shí)間成本、人力成本都將高到一個(gè)不可接受的狀態(tài)。其次，開(kāi)源項(xiàng)目和第三方服務(wù)通常比較 專注，對(duì)所要解決的問(wèn)題有更深刻的理解。例如，代碼托管服務(wù)GitHub及相關(guān)的配套服務(wù)，顯然其更專注在代碼托管、團(tuán)隊(duì)協(xié)作方面的需求。最后，開(kāi)源項(xiàng)目 和第三方服務(wù)的擴(kuò)展性和兼容性通常是有保障的，做為開(kāi)源項(xiàng)目或第三方服務(wù)，為上下游其他工具和服務(wù)的接入提供良好的支持是基本的目標(biāo)之一，保證了其在整個(gè) 鏈路中的低耦合性和可替代性。當(dāng)有更合適的解決方案時(shí)，可以方便地將其替換掉而不影響整個(gè)系統(tǒng)的穩(wěn)定性。

將“人”的因素轉(zhuǎn)化為“非人”的因素

“人” 是最不可控的變量因素，無(wú)論是工程質(zhì)量、發(fā)布流程，人工參與的操作都是最容易出問(wèn)題的環(huán)節(jié)。因此，應(yīng)該盡可能在整個(gè)過(guò)程中將更多人的因素轉(zhuǎn)為非人的因素， 機(jī)器化的流程就變得更可控和可靠。舉一個(gè)具體的例子，Code Style是每個(gè)團(tuán)隊(duì)在成員數(shù)量開(kāi)始增加時(shí)都要制定的第一個(gè)規(guī)范，但規(guī)范有了之后能否具體實(shí)施到每一行代碼中、實(shí)施的效果怎么樣，其實(shí)是取決于人——也就 是每個(gè)成員個(gè)體，且這個(gè)執(zhí)行情況是不可控的。這時(shí)我們就需要通過(guò)某種手段將其轉(zhuǎn)為自動(dòng)化的過(guò)程，也就是引入代碼的靜態(tài)檢查，如JSLint或 JSHint，自動(dòng)化檢查過(guò)程就將Code Style的執(zhí)行情況轉(zhuǎn)變成了非人的因素。自動(dòng)化不只是提高生產(chǎn)效率的手段，同時(shí)也是保證質(zhì)量的重要途徑。

寫在最后

很 多團(tuán)隊(duì)都在探索前端未來(lái)的發(fā)展方向，我們也不例外。大家思考這個(gè)問(wèn)題的思路似乎都是相似的，想要跨端——將前端拓展到Android、iOS等平臺(tái)。有的 團(tuán)隊(duì)是借助PhoneGap這種給WebView加殼的形式，也有的是通過(guò)Titanium Mobile或類似的解決方案，打包一個(gè)JavaScript Runtime，通過(guò)bridge來(lái)操作Native API甚至直接將JavaScript編譯成某種目標(biāo)語(yǔ)言�，F(xiàn)在討論前端，不加特殊說(shuō)明的情況下是特指Web前端，而Web前端是被限定在特定的技術(shù)平臺(tái) 上的。上面提到的兩種思路，本質(zhì)上還是被限制在了Web前端自己的技術(shù)體系內(nèi)。那么，如果拋開(kāi)具體的技術(shù)實(shí)現(xiàn)來(lái)思考這個(gè)問(wèn)題呢？

前端，應(yīng)該 是最接近用戶的上層業(yè)務(wù)，工作內(nèi)容是做UI，而User Interface絕不僅僅只是狹義的視覺(jué)上的界面，而是和Interface這個(gè)詞的本意——接口，兩個(gè)不同系統(tǒng)交接并通過(guò)它彼此作用的部分——一樣， 是兩個(gè)系統(tǒng)進(jìn)行信息交換的中間介質(zhì)，而且信息本身是形式多樣化的。兩個(gè)系統(tǒng)，就是指用戶和其所使用的具體產(chǎn)品。從這個(gè)角度看，將前端的業(yè)務(wù)范圍拓展到其他 平臺(tái)是合情合理的，而且在這個(gè)層面上，任何平臺(tái)上做前端開(kāi)發(fā)都應(yīng)該是有統(tǒng)一的價(jià)值觀和方法論的。

前面提到的這個(gè)閉環(huán)，如果將所有的技術(shù)細(xì)節(jié)和實(shí)現(xiàn)方案全都隱去，進(jìn)行進(jìn)一步抽象，只留下需求，就會(huì)變成圖3中的一個(gè)環(huán)形。

圖3 抽象后的生態(tài)系統(tǒng)閉環(huán)

這 個(gè)環(huán)中（其中生產(chǎn)環(huán)境對(duì)iOS和Android等客戶端開(kāi)發(fā)并不一定存在，所以是虛線）每一個(gè)環(huán)境的需求都是有普適意義的，也可以在其他平臺(tái)上面嘗試類似 的工作方式。其中，運(yùn)行環(huán)境到開(kāi)發(fā)環(huán)境這一步，因?yàn)樯婕暗胶芏嘤脩趔w驗(yàn)、數(shù)據(jù)收集和分析的相關(guān)工作，對(duì)前端的意義也顯得格外重要。正是這一部分，使得前端 工程師同其他工程師區(qū)別開(kāi)來(lái)，也是前端工程師最能體現(xiàn)自己價(jià)值的地方——距離用戶更近，能從不同的視角來(lái)思考和解決問(wèn)題。而如何將所有終端都統(tǒng)一的內(nèi)容抽 象出來(lái)，結(jié)合產(chǎn)品形成前端統(tǒng)一的價(jià)值觀和方法論，就是需要進(jìn)一步探索的內(nèi)容了。

最后，推薦一些開(kāi)源項(xiàng)目和第三方服務(wù)，可以直接用來(lái)打造自己的前端研發(fā)生態(tài)環(huán)境：

• JSHint，JavaScript代碼檢查工具；
• Yeoman，工程初始化工具；
• Grunt，任務(wù)調(diào)度和驅(qū)動(dòng)工具；
• Karma Runner，測(cè)試驅(qū)動(dòng)工具；
• Mocha，測(cè)試框架；
• GitHub，著名的Git工程托管服務(wù)；
• Travis CI，和GitHub整合的CI服務(wù)；
• Circle CI，可以和GitHub或Jenkins整合的CI服務(wù)；
• Codeship，能和GitHub或Jenkins整合的CI服務(wù)；
• Google Analytics，數(shù)據(jù)收集和分析服務(wù)；
• Speed Curve，網(wǎng)站性能統(tǒng)計(jì)和分析服務(wù)；
• Roolba、Appfail，網(wǎng)站運(yùn)行期異常收集和分析服務(wù)。