前天，我們公司前端團隊的幾個人一起去大搜車參加了芋頭所組織的「搜車 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 代理到本地檔案來調試。
運作 livepool
這種方式不僅用來支撐日常的項目開發，還用于調試線上 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 做很多事情，如自家使用的智能家庭系統啦，公司内部的資源資訊管理系統啦，還有通過微信機器人控制智能硬體啦……
資源資訊管理系統
想法總是源源不斷的，就是沒什麼時間和精力去實施，就等着哪天突然打雞血了吧!
另外，我覺得過些年「前端工程師」這個職業會消失。
作者：歐雷
來源：51cto