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

[[169783]]

聚會現場

這次聚會的主題全部是與大搜車現行的業(yè)務和技術掛鉤的：芋頭講述了團隊中 Node.js 的技術演進及未來展望;死月分析了幾個常用 ORM 的特點并安利了自己的作品;Plusman 分享了日志監(jiān)控方案和實踐。(相關演示文稿可以到芋頭所寫的總結中下載)

整場下來，雖說沒有醍醐灌頂，但對我們團隊接下來要做的事情還是比較有借鑒意義的。另外，這場聚會給了我很多信心，讓我覺得等我們積累些經驗之后，也可以總結出來與其他公司的人分享交流一下。

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

前端工程化

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

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

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

項目中前端工程問題比較嚴重，開發(fā)舒適度和效率都比較低。

網絡代理

正因為靜態(tài)資源文件與后端框架相隔離，在開發(fā)時無法通過本地文件的相對路徑進行引用。我們利用 LivePool 將模板中引用靜態(tài)資源文件的 URL 代理到本地文件來調試。

運行 LivePool

這種方式不僅用來支撐日常的項目開發(fā)，還用于調試線上 bug。能夠方便、快速地解決線上問題固然使人愉悅，但開發(fā)時就麻煩得讓人蛋疼了。

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

活動頁面

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

做來做去，活動頁的代碼有很多地方是一樣的，雖說是時效性很高的頁面，但總復制粘貼也不是個辦法。碼農是最討厭做重復無意義且沒挑戰(zhàn)性的事情的一種生物，所以他們會想方設法去把那部分自動化處理，解放自己!

為了讓雙手不那么麻，工頭基于 Yeoman 開發(fā)了一個活動頁的腳手架「generator-mhc-activity」。在我對它進行優(yōu)化處理之后，只需在終端中敲入簡單的命令就能生成桌面端和移動端兩個版本的活動頁面框架。

自動構建

構建工具在我來的時候就已經有了，用的是 Gulp。那時只是用來合并、壓縮文件，并沒有充分發(fā)揮它的作用;并且源碼都是用標準語言編寫的，也無法讓它展現出其他價值。

隨著公司將重心轉移到針對商家的 B2B 業(yè)務的「賣好車」，我們有機會嘗試引入新的開發(fā)方式以提高舒適度和效率。

在新的項目中，分別采用 Sass 和 ES6 編寫樣式和腳本，連同圖片文件一起與后端框架放在同一個 Git 倉庫;使用 FIS3 把它們編譯成標準語言，并在部署時合并、壓縮文件以及進行為文件加指紋等操作。

圖片上傳

項目里的圖片等靜態(tài)資源文件是存儲在 CDN 上的，發(fā)布前會用工頭寫的 Node.js 腳本把那些新增和改動的文件上傳上去。

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

后來，我在原有的基礎上做了很多優(yōu)化，形成一個可配置、支持多個 CDN 的功能較為完善的上傳工具——RocketZ。與 FIS3 配合，可以在七牛再抽風時輕輕松把靜態(tài)資源文件切換到頑兔的備份。

團隊定制

當使用的工具多了，就希望有一個工具能夠替代它們，也就是包含它們所有的功能。要做到這點，就得根據團隊的需求造一個輪子出來。我覺得每個前端團隊都需要這么一個專屬于自己的輪子，「Bumblebee」就是為此而生。

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

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

前后端分離

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

起初，這個項目到底要用來干嘛，并沒有很明確的想法。想過用來渲染無動態(tài)數據的頁面，也想過完全替代 Java，但想來想去都不太靠譜，最后決定用來做前后端分離。然而，出于種種原因且當時也不算是剛需，只搭了個架子就擱置在那了。時隔兩個多月，它的重要性日漸突出，決定撿起來好好做下去!

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

是什么?

「前后端分離」這個概念網上有很多文章描述，用我的話來簡單概括就是：「前端」和「后端」并不應該用設備、平臺來劃分，而應以關注點和職責來劃分——與人機交互及數據展現相關的都算是「前端」，即 Controller 層和 View 層;與業(yè)務邏輯及數據存儲相關的都算是「后端」，即 Model 層。

前端工程師的本職就是將數據展示在頁面上并提供給用戶極佳的體驗，與其他客戶端應用工程師幾乎是一樣兒一樣兒的。所以，進行前后端分離恰恰是將原本應該由前端工程師去做的事情歸還了回來——職責回歸。

為什么?

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

      起來!不愿做奴隸的人們!

      -------------《義勇軍進行曲》

與后端框架耦合在一起，開發(fā)效率低且溝通成本高，頁面變更的發(fā)布緩慢，對于開發(fā)和運營來說都不友好。另一方面，簡單修改的發(fā)布在運營童鞋眼里看來就應該是分分鐘的事兒，如果非要拖到晚上等著跟后端一起發(fā)布，他們會覺得我們前端工程師「真沒用」!

無論從哪方面說，將前端的開發(fā)和發(fā)布流程獨立出來勢在必行!

怎么做?

關于怎么去進行分離，簡單說來，就是通過 API 將前、后端這兩個獨立的個體連接起來——后端專注于業(yè)務邏輯，將需要展現的數據通過 API 輸出;前端專注于數據呈現，通過 API 輸入和獲取數據。

然而，實際的系統(tǒng)架構和環(huán)境較為復雜，實現起來也許沒有想象中那么簡單，并且不僅要考慮如何去開發(fā)，還要考慮如何去測試和部署發(fā)布的問題。

目前所想到的需要解決的問題有：同時訪問 Java 框架和 Node.js 框架中的頁面以及將 Java 框架中的頁面平滑遷移到 Node.js 框架中去;在不同環(huán)境中對數據的讀寫操作;集成進內部的一鍵部署發(fā)布系統(tǒng)。

關于我們團隊在前后端分離實踐方面更多具體的事情請關注今后的文章～ ;-)

不算題外話的話

最近想用 Node.js 做很多事情，如自家使用的智能家庭系統(tǒng)啦，公司內部的資源信息管理系統(tǒng)啦，還有通過微信機器人控制智能硬件啦……

[[169784]]

資源信息管理系統(tǒng)

想法總是源源不斷的，就是沒什么時間和精力去實施，就等著哪天突然打雞血了吧!

另外，我覺得過些年「前端工程師」這個職業(yè)會消失。