团队中的 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 作不少事情，如智能家庭系统啦，公司内部的资源信息管理系统啦，还有经过微信机器人控制智能硬件啦……

想法老是不断的，就是没什么时间和精力，就等着哪天忽然打鸡血了吧！

另外，我以为过些年「前端工程师」这个职业会消失。