前端研發(fā)生態(tài)環(huán)境構(gòu)建經(jīng)驗談
不記得從什么時候起,“生態(tài)環(huán)境”這個詞經(jīng)常出現(xiàn)在人們耳邊,而在IT行業(yè)中似乎出現(xiàn)頻率更高——所有的巨頭公司都在建設或運營自己的“生態(tài)環(huán) 境”,要形成“閉環(huán)”。那么對前端開發(fā)來講,是否也需要有一套自己的生態(tài)環(huán)境形成一個閉環(huán)呢?那前端開發(fā)的生態(tài)環(huán)境和閉環(huán)又應該是什么樣的呢?
過去很長一段時間,我們都在探索適合自己團隊的發(fā)展之路,建立大家共同認可的愿景和發(fā)展目標等。這時,首先要明確的就是,團隊的追求和價值觀是什么。最初, 每次制定全年或季度的工作計劃時,除和具體業(yè)務相關(guān)的工作外,還會出現(xiàn)提高工程質(zhì)量、提高開發(fā)效率等這樣的任務。隨著時間推移,我們發(fā)現(xiàn)如果前端工程師的 工作目標是讓前端工程師們能更好地工作,那么就陷入了一個死循環(huán),因為這個目標很難被具體化,也很難將前端工程師真正的價值體現(xiàn)在目標中。經(jīng)過一段時間的 探索,我們嘗試從所參與的產(chǎn)品本身出發(fā)制定工作目標,這樣“提高工程質(zhì)量”、“提高開發(fā)效率”就變成了過程,產(chǎn)品的進步就代表前端工程師的工作產(chǎn)生了價值。
實踐后發(fā)現(xiàn)這個方向是正確的,因為無論團隊內(nèi)部在做什么都只是手段和途徑,而產(chǎn)品本身的改進證明目的達到了。進而我們開始嘗試將整個過 程系統(tǒng)化,于是就提到了開頭所說的前端開發(fā)的生態(tài)環(huán)境和閉環(huán)。如果按照環(huán)境將前端工程師工作的平臺進行劃分,將會是開發(fā)環(huán)境、服務器和瀏覽器三個在物理上 互相隔離的點,而通過一系列工具、平臺和方法論,就能將這三個孤立的點串聯(lián)起來,形成一個整體(如圖1所示)。
圖1 前端生態(tài)環(huán)境形成的閉環(huán)
通過這個閉環(huán),特別是從瀏覽器回到開發(fā)環(huán)境這個環(huán)節(jié),前端工程師會通過具體產(chǎn)品和終端用戶進行頻繁的信息交換,在最終的產(chǎn)品中進行信息收集,再將信息轉(zhuǎn)化為指標或其他能夠衡量產(chǎn)品質(zhì)量的形式,以此指導工作方向。
打造前端研發(fā)生態(tài)環(huán)境
接下來,按階段將整個過程落實到具體的工程實現(xiàn)上,最終的產(chǎn)出是一套完整的工具、平臺和方法論。
從開發(fā)環(huán)境到服務器
開 發(fā)環(huán)境是一切工作的開始,每一行代碼都是從這里出發(fā)最終deliver給終端用戶的,并不涉及到具體業(yè)務或產(chǎn)品。當團隊人數(shù)增加、項目規(guī)模和數(shù)量開始膨脹 時,很多日常的開發(fā)和發(fā)布操作就會占用工程師很多的時間和精力,而這些工作通常又是機械式重復的。為了解決效率問題,自動化是必然的方案。這個環(huán)節(jié)中大部 分的問題抽象后都是工程問題,也就是通常所說的前端持續(xù)集成(CI)。合理的CI過程可以有效提高開發(fā)效率和工程質(zhì)量,提供快速且可靠的持續(xù)交付能力。目 前,豌豆實驗室的前端CI過程如圖2所示。
圖2 豌豆實驗室的前端CI過程
其中包含了以下環(huán)節(jié):
- 版本管理,保證代碼安全和協(xié)同工作的效率;
- on-save或pre-commit檢查,包括lint和code style檢查;
- Code Review;
- 自動化測試;
- 自動化構(gòu)建;
- 自動化部署。
工程在開發(fā)環(huán)境進行簡單的提交前檢查,如靜態(tài)分析和簡單的測試,然后提交到代碼托管服務,通過Code Review后合并入庫,進行完整的自動測試,最后根據(jù)需要發(fā)布到測試或生產(chǎn)環(huán)境。
整 個流程的核心工具是Grunt。Grunt是一個基于Node.js的任務管理和調(diào)度工具,最初是完全按照前端開發(fā)的需求打造的,但得益于其強大的擴展 性,現(xiàn)在也可以被用于其他類型的工程。Grunt的核心是Gruntfile.js文件,其中預留了眾多諸如測試、構(gòu)建、部署等任務入口,可以在各個階段 中按需調(diào)用。
對于中小型團隊來講,合理利用開源項目和第三方服務可以有效降低在這個環(huán)節(jié)上的投入。同時,因為工程自動化要求同種工程的結(jié)構(gòu)等都是相近的,這也是一個將對工程進行規(guī)范化的契機,通過Yeoman或類似的工具可以實現(xiàn)這個目的。
服務器到瀏覽器
經(jīng)過前面提到的CI,工程就被發(fā)布到了線上服務器,可以分發(fā)給終端用戶了。服務器在整個閉環(huán)中起到的是承上啟下的作用,其中很多工作都是離前端工程師的傳統(tǒng)認知比較遠的內(nèi)容,主要包括:
- 負載均衡;
- 靜態(tài)資源管理;
- CDN自動化管理;
- Cache策略管理;
- 線上服務性能指標監(jiān)控;
- 安全防護。
從 傳統(tǒng)的技術(shù)團隊合作分工來看,這一部分內(nèi)容通常是由運維工程師來完成的。但我們發(fā)現(xiàn)由于服務器和瀏覽器之間的信息交換的暢通和效率將會直接影響產(chǎn)品在某些 方面的體驗,所以其中某些部分也是可以被前端工程師納入到工作內(nèi)容當中的,或者是可以基于前端的需求進行調(diào)整和優(yōu)化的,主要集中在加載速度和可靠性以及安 全三個方面。
這個過程需要和運維團隊緊密配合,要求對方提供統(tǒng)一、與業(yè)務無關(guān)且可編程的配置接口,將服務規(guī)范化。例如,某工程的靜態(tài)資源在CDN上的過期規(guī)則,可在工程的配置文件中進行描述,在發(fā)布時自動通過CDN或CDN源站提供的API進行操作。
業(yè)務層的安全防護也應該在這個環(huán)節(jié)中考慮進來,例如統(tǒng)一的跨站腳本防御策略、API的CORS應用策略和CSP規(guī)則等,都應該由前端來驅(qū)動進行制定和實施。
瀏覽器到開發(fā)環(huán)境
瀏覽器是前端工程師的主場,大部分的工作最終都把瀏覽器當作運行環(huán)境,因此這個點也是最重要的。在這個點上主要包含以下工作內(nèi)容:
- 客戶端性能監(jiān)控;
- 異常捕獲與收集;
- 用戶行為跟蹤與統(tǒng)計;
- 用戶反饋收集。
可 以概括地分為工程數(shù)據(jù)和用戶數(shù)據(jù)收集兩大部分。工程數(shù)據(jù)是用來監(jiān)控產(chǎn)品的性能指標和異常情況的,進而有針對性地進行性能調(diào)優(yōu)和Bug修復,而產(chǎn)品數(shù)據(jù)則是 用來分析用戶的需求指導產(chǎn)品功能改進的。除了配套的統(tǒng)計工具外,也要能從這些數(shù)據(jù)當中轉(zhuǎn)化有意義的信息,同時,以這個點為基礎,不停地改進整個循環(huán)。
響應速度也是一個需要重點考量的目標,無論是線上產(chǎn)品的異常還是性能退化的發(fā)生,或者某個功能設計失誤導致用戶使用出現(xiàn)嚴重問題,都應該能在這個流程中快速反饋回來進行快速響應,將損失降到最低。同時,在正常的開發(fā)過程中,響應速度快也能夠提高產(chǎn)品本身的迭代速度。
同 樣,在這個環(huán)節(jié)也有很多第三方服務可以使用,最常用的就是Google Analytics了,可以提供性能跟蹤、用戶行為統(tǒng)計、事件統(tǒng)計等常見的網(wǎng)站數(shù)據(jù)分析服務。除此之外,還可以使用SpeedCurve來對加載性能進行 針對性的跟蹤和分析,使用Roolba或Appfial服務來收集運行時異常。
以工具為基礎,工程師就可以對產(chǎn)品最終運行的情況有更形象和具體的認知。例如,當我們對加載速度進行優(yōu)化時,就可以看到點擊率的上升或跳出率的下降,因此這些指標就可以坐為我們制定工作目標的標準。
閉環(huán)
到這里,一個完整的前端開發(fā)生態(tài)環(huán)境就形成了一個閉環(huán)。以此為基礎,前端工程師只要將大部分精力放在最后一個環(huán)節(jié),就可以快速地改進產(chǎn)品,讓工作最終以產(chǎn)品本身為導向來進行;剡^頭來,總結(jié)一下在這個過程中的幾個原則。
從前端開發(fā)的角度看問題
這個生態(tài)環(huán)境當中,很多內(nèi)容都是和產(chǎn)品設計、運維等其他工作有交叉的,并不是說前端工程師要把更多相關(guān)的工作納入進來,而是要能從自己的角度對同一個問題有不同的看法和解決方案,這樣才能發(fā)揮出前端更貼近用戶的優(yōu)勢。
其 實這個研發(fā)閉環(huán)的打造過程沒有任何的新內(nèi)容,都是每個前端工程師日常工作的一部分,區(qū)別在于從系統(tǒng)化的角度將它們串在一起了。這個閉環(huán)中,最重要的是最后 從瀏覽器回到開發(fā)環(huán)境的過程,但數(shù)據(jù)的收集和分析工作在不同的公司組織架構(gòu)下可能是由其他角色來完成的,如數(shù)據(jù)挖掘工程師或者產(chǎn)品經(jīng)理等。但我們相信,由 于前端工程師的特殊工作性質(zhì),使其能夠同時從工程和用戶兩個角度觀察產(chǎn)品,那么也會有自己獨特的解決問題的方式和途徑。這個生態(tài)環(huán)境是為了能以產(chǎn)品為中心 指導工作而進行的基礎建設,本質(zhì)上也只是一個工具,如何利用好它,需要整個團隊進行長期的探索和磨合。
不重新發(fā)明輪子
對 于團隊來講,快速、準確地解決問題,滿足需求是唯一目標,因此當遇到問題時首先要仔細分析真實需求到底是什么。需求明確后,就涉及到具體的實現(xiàn)方案設計和 技術(shù)選型等工程方面的決策,開源項目或者合適的第三方服務依然是首選,原因有三。首先,也是最重要的,投入產(chǎn)出比。在整個閉環(huán)的打造過程當中,會用到無數(shù) 的工具和服務,其中每一個的復雜度都是非常高的,如果自己從零開發(fā),時間成本、人力成本都將高到一個不可接受的狀態(tài)。其次,開源項目和第三方服務通常比較 專注,對所要解決的問題有更深刻的理解。例如,代碼托管服務GitHub及相關(guān)的配套服務,顯然其更專注在代碼托管、團隊協(xié)作方面的需求。最后,開源項目 和第三方服務的擴展性和兼容性通常是有保障的,做為開源項目或第三方服務,為上下游其他工具和服務的接入提供良好的支持是基本的目標之一,保證了其在整個 鏈路中的低耦合性和可替代性。當有更合適的解決方案時,可以方便地將其替換掉而不影響整個系統(tǒng)的穩(wěn)定性。
將“人”的因素轉(zhuǎn)化為“非人”的因素
“人” 是最不可控的變量因素,無論是工程質(zhì)量、發(fā)布流程,人工參與的操作都是最容易出問題的環(huán)節(jié)。因此,應該盡可能在整個過程中將更多人的因素轉(zhuǎn)為非人的因素, 機器化的流程就變得更可控和可靠。舉一個具體的例子,Code Style是每個團隊在成員數(shù)量開始增加時都要制定的第一個規(guī)范,但規(guī)范有了之后能否具體實施到每一行代碼中、實施的效果怎么樣,其實是取決于人——也就 是每個成員個體,且這個執(zhí)行情況是不可控的。這時我們就需要通過某種手段將其轉(zhuǎn)為自動化的過程,也就是引入代碼的靜態(tài)檢查,如JSLint或 JSHint,自動化檢查過程就將Code Style的執(zhí)行情況轉(zhuǎn)變成了非人的因素。自動化不只是提高生產(chǎn)效率的手段,同時也是保證質(zhì)量的重要途徑。
寫在最后
很 多團隊都在探索前端未來的發(fā)展方向,我們也不例外。大家思考這個問題的思路似乎都是相似的,想要跨端——將前端拓展到Android、iOS等平臺。有的 團隊是借助PhoneGap這種給WebView加殼的形式,也有的是通過Titanium Mobile或類似的解決方案,打包一個JavaScript Runtime,通過bridge來操作Native API甚至直接將JavaScript編譯成某種目標語言,F(xiàn)在討論前端,不加特殊說明的情況下是特指Web前端,而Web前端是被限定在特定的技術(shù)平臺 上的。上面提到的兩種思路,本質(zhì)上還是被限制在了Web前端自己的技術(shù)體系內(nèi)。那么,如果拋開具體的技術(shù)實現(xiàn)來思考這個問題呢?
前端,應該 是最接近用戶的上層業(yè)務,工作內(nèi)容是做UI,而User Interface絕不僅僅只是狹義的視覺上的界面,而是和Interface這個詞的本意——接口,兩個不同系統(tǒng)交接并通過它彼此作用的部分——一樣, 是兩個系統(tǒng)進行信息交換的中間介質(zhì),而且信息本身是形式多樣化的。兩個系統(tǒng),就是指用戶和其所使用的具體產(chǎn)品。從這個角度看,將前端的業(yè)務范圍拓展到其他 平臺是合情合理的,而且在這個層面上,任何平臺上做前端開發(fā)都應該是有統(tǒng)一的價值觀和方法論的。
前面提到的這個閉環(huán),如果將所有的技術(shù)細節(jié)和實現(xiàn)方案全都隱去,進行進一步抽象,只留下需求,就會變成圖3中的一個環(huán)形。
圖3 抽象后的生態(tài)系統(tǒng)閉環(huán)
這 個環(huán)中(其中生產(chǎn)環(huán)境對iOS和Android等客戶端開發(fā)并不一定存在,所以是虛線)每一個環(huán)境的需求都是有普適意義的,也可以在其他平臺上面嘗試類似 的工作方式。其中,運行環(huán)境到開發(fā)環(huán)境這一步,因為涉及到很多用戶體驗、數(shù)據(jù)收集和分析的相關(guān)工作,對前端的意義也顯得格外重要。正是這一部分,使得前端 工程師同其他工程師區(qū)別開來,也是前端工程師最能體現(xiàn)自己價值的地方——距離用戶更近,能從不同的視角來思考和解決問題。而如何將所有終端都統(tǒng)一的內(nèi)容抽 象出來,結(jié)合產(chǎn)品形成前端統(tǒng)一的價值觀和方法論,就是需要進一步探索的內(nèi)容了。
最后,推薦一些開源項目和第三方服務,可以直接用來打造自己的前端研發(fā)生態(tài)環(huán)境:
- JSHint,JavaScript代碼檢查工具;
- Yeoman,工程初始化工具;
- Grunt,任務調(diào)度和驅(qū)動工具;
- Karma Runner,測試驅(qū)動工具;
- Mocha,測試框架;
- GitHub,著名的Git工程托管服務;
- Travis CI,和GitHub整合的CI服務;
- Circle CI,可以和GitHub或Jenkins整合的CI服務;
- Codeship,能和GitHub或Jenkins整合的CI服務;
- Google Analytics,數(shù)據(jù)收集和分析服務;
- Speed Curve,網(wǎng)站性能統(tǒng)計和分析服務;
- Roolba、Appfail,網(wǎng)站運行期異常收集和分析服務。
- 基于用戶創(chuàng)新
界面設計日新月異,夢創(chuàng)義堅持基于用戶需求的界面創(chuàng)新設計……
- 服務設計思維
互聯(lián)網(wǎng)的格局發(fā)生的改變,在我們進行設計服務時更是考慮不同用戶、不同……
- 洞察用戶心理
洞察用戶有意識和無意識的行為以及心理特征通過構(gòu)造一系列的服務來促進……
- 查看更多 >>
最新新聞Latest News
- 中小型企業(yè)網(wǎng)站建設完應該如何營銷
- 很多中小型企業(yè)往往糾結(jié)于以下10個問題:一、我們起步比別人晚,我們的……
- 做企業(yè)網(wǎng)站到底做給誰看?
- 設計經(jīng)常時不時的遇到一些企業(yè)客戶,常常搞不清楚誰會真正看你的企業(yè)網(wǎng)……
- 傳統(tǒng)企業(yè)進軍移動互聯(lián)網(wǎng),從移動云網(wǎng)站開始
- 移動互聯(lián)網(wǎng)是移動通信和互聯(lián)網(wǎng)融合的產(chǎn)物,其發(fā)展的重要基礎便是智能手……
- 網(wǎng)站建設和運營五大細節(jié)決定用戶黏性
- 網(wǎng)站的成功離不開搜索引擎優(yōu)化,更離不開最基礎最根本的用戶群體,如何……
- 2015年值得關(guān)注的電子商務5大趨勢
- 線上線下銷售的界線正在變得越來越模糊。在2015年,這一趨勢仍將繼續(xù)!