團隊中的 Node.js 實踐

本文首發於歐雷流。因爲我會時不時對文章進行補充、修正和潤色，爲了保證所看到的是最新版本，請閱讀原文。

前天，咱們公司前端團隊的幾我的一塊兒去大搜車參加了芋頭所組織的「搜車 Node Party」。這是我第一次參加與 Node.js 相關的線下聚會，若是不算「杭JS」的話。

此次聚會的主題所有是與大搜車現行的業務和技術掛鉤的：芋頭講述了團隊中 Node.js 的技術演進及將來展望；死月分析了幾個經常使用 ORM 的特色並安利了本身的做品；Plusman 分享了日誌監控方案和實踐。（相關演示文稿能夠到芋頭所寫的總結中下載）

整場下來，雖然說沒有醍醐灌頂，但對咱們團隊接下來要作的事情仍是比較有借鑑意義的。另外，這場聚會給了我不少信心，讓我以爲等咱們積累些經驗以後，也能夠總結出來與其餘公司的人分享交流一下。

在這裏，我先簡單說說咱們團隊使用 Node.js 的一些場景。若能從頭至尾認真地讀下去，會了解到咱們的技術演進和發展方向。

前端工程化

Node.js 從問世開始，已經漸漸成爲前端工程師的必備技能，開發中或多或少都會用到它。雖然不是很重，但咱們在團隊中也有用到 Node.js，主要是使用命令行工具處理前端工程問題。

剛來公司時，業務重心還在 B2C 的平行進口車交易網站「買好車」上，前端團隊的工做主要就是新功能開發和修修補補，還有就是鋪天蓋地的活動頁。

當時有兩個 Git 倉庫：一個是 Java 的全棧式框架 Webx，主站的 HTML 代碼都是用 Velocity 模版寫的；另外一個是全部項目的頁面所用到的 CSS、JS 和圖片等靜態資源文件。

項目中前端工程問題比較嚴重，開發溫馨度和效率都比較低。

網絡代理

正由於靜態資源文件與後端框架相隔離，在開發時沒法經過本地文件的相對路徑進行引用。咱們利用 LivePool 將模板中引用靜態資源文件的 URL 代理到本地文件來調試。

這種方式不只用來支撐平常的項目開發，還用於調試線上 bug。可以方便、快速地解決線上問題當然令人愉悅，但開發時就麻煩得讓人蛋疼了。

每新增一個文件就要先上傳到測試服務器才能映射到本地，每修改一點代碼就要新開一個終端窗口運行 livepool……你手指麻不？你不麻？我麻！

活動頁面

想當年，活動頁真是多到數不勝數，每一個活動要作桌面版和移動版兩份，有時一天要作兩個活動，加起來就是四個頁面。

作來作去，活動頁的代碼有不少地方是同樣的，雖然說是時效性很高的頁面，但總複製粘貼也不是個辦法。碼農是最討厭作重複無心義且沒挑戰性的事情的一種生物，因此他們會千方百計去把那部分自動化處理，解放本身！

爲了讓雙手不那麼麻，工頭基於 Yeoman 開發了一個活動頁的腳手架「generator-mhc-activity」。在我對它進行優化處理以後，只需在終端中敲入簡單的命令就能生成桌面端和移動端兩個版本的活動頁面框架。

自動構建

構建工具在我來的時候就已經有了，用的是 Gulp。那時只是用來合併、壓縮文件，並無充分發揮它的做用；而且源碼都是用標準語言編寫的，也沒法讓它展示出其餘價值。

隨着公司將重心轉移到針對商家的 B2B 業務的「賣好車」，咱們有機會嘗試引入新的開發方式以提升溫馨度和效率。

在新的項目中，分別採用 Sass 和 ES6 編寫樣式和腳本，連同圖片文件一塊兒與後端框架放在同一個 Git 倉庫；使用 FIS3 把它們編譯成標準語言，並在部署時合併、壓縮文件以及進行爲文件加指紋等操做。

圖片上傳

項目裏的圖片等靜態資源文件是存儲的 CDN 上的，發佈前會用工頭寫的 Node.js 腳本把那些新增和改動的文件上傳上去。

當時腳本寫得比較簡陋，既沒有配置文件又不能傳入變量，每次都要手動去把須要上傳的文件拷貝出來放到同一個目錄下，把腳本中的路徑修改成那個目錄纔可以上傳，麻煩至極！而且沒有作容災處理，只能上傳到七牛，它的生死存亡直接影響到咱們……不幸的是，已經經歷過兩次這種事情了！

後來，我在原有的基礎上作了不少優化，造成一個可配置、支持多個 CDN 的功能較爲完善的上傳工具——RocketZ。與 FIS3 配合，能夠在七牛再抽風時輕輕鬆把靜態資源文件切換到頑兔的備份。

團隊定製

當使用的工具多了，就但願有一個工具可以替代它們，也就是包含它們全部的功能。要作到這點，就得根據團隊的需求造一個輪子出來。我以爲每一個前端團隊都須要這麼一個專屬於本身的輪子，「Bumblebee」就是爲此而生。

Bumblebee 的實質就是一個容器，把 yeoman-environment（Yeoman 的底層）和 RocketZ 包裝起來經過子命令調用。只用這一個工具就能使用腳手架和上傳圖片的功能，既使用簡單又減小了記憶、管理等成本，何樂而不爲呢？

接下來還想加入安裝插件和構建等功能，前提是有時間和精力……

先後端分離

到 5 月份時，請拓爺（花名文拓，Java 架構師）新開了一個項目，用於在現有項目基礎上基於 Node.js 作一些事情。

起初，這個項目到底要用來幹嗎，並無很明確的想法。想過用來渲染無動態數據的頁面，也想過徹底替代 Java，但想來想去都不太靠譜，最後決定用來作先後端分離。然而，出於種種緣由且當時也不算是剛需，只搭了個架子就擱置在那了。時隔兩個多月，它的重要性日漸突出，決定撿起來好好作下去！

我對不起組織，請狠狠地鞭笞我……

是什麼？

「先後端分離」這個概念網上有不少文章描述，用個人話來簡單歸納就是：「前端」和「後端」並不該該用設備、平臺來劃分，而應以關注點和職責來劃分——與人機交互及數據展示相關的都算是「前端」，即 Controller 層和 View 層；與業務邏輯及數據存儲相關的都算是「後端」，即 Model 層。

前端工程師的本職就是將數據展現在頁面上並提供給用戶極佳的體驗，與其餘客戶端應用工程師幾乎是同樣兒同樣兒的。因此，進行先後端分離偏偏是將本來應該由前端工程師去作的事情歸還了回來——職責迴歸。

爲何？

在傳統的 web 開發模式中，「前端」僅僅是指 MVC 架構模式中的 View 層。在這種模式下，前端的開發和發佈進度被後端框架所牽制，感受像被奴役了同樣。每次在僅僅是修改一點點樣式或文案還得等後端人員去發佈時，內心就會默默地在唱——

起來！不肯作奴隸的人們！

與後端框架耦合在一塊兒，開發效率低且溝通成本高，頁面變動的發佈緩慢，對於開發和運營來講都不友好。另外一方面，簡單修改的發佈在運營童鞋眼裏看來就應該是分分鐘的事兒，若是非要拖到晚上等着跟後端一塊兒發佈，他們會以爲咱們前端工程師「真沒用」！

不管從哪方面說，將前端的開發和發佈流程獨立出來勢在必行！

怎麼作？

關於怎麼去進行分離，簡單說來，就是經過 API 將前、後端這兩個獨立的個體鏈接起來——後端專一於業務邏輯，將須要展示的數據經過 API 輸出；前端專一於數據呈現，經過 API 輸入和獲取數據。

然而，實際的系統架構和環境較爲複雜，實現起來也許沒有想象中那麼簡單，而且不只要考慮如何去開發，還要考慮如何去測試和部署發佈的問題。

目前所想到的須要解決的問題有：同時訪問 Java 框架和 Node.js 框架中的頁面以及將 Java 框架中的頁面平滑遷移到 Node.js 框架中去；在不一樣環境中對數據的讀寫操做；集成進內部的一鍵部署發佈系統。

關於咱們團隊在先後端分離實踐方面更多具體的事情請關注從此的文章～ ;-)

不算題外話的話

最近想用 Node.js 作不少事情，如智能家庭系統啦，公司內部的資源信息管理系統啦，還有經過微信機器人控制智能硬件啦……

想法老是不斷的，就是沒什麼時間和精力，就等着哪天忽然打雞血了吧！

另外，我以爲過些年「前端工程師」這個職業會消失。