NodeJS服务端重构计划

不知不觉做node开发已经半年时间了。这期间写尝试着去攻克了一些问题。实现了一下想法，也遇到过一些坑。

是时候来梳理一下代码，规划一下接下来的工作。

现阶段我们的nodeserver端代码结构是这种：

乍一看好像没有什么问题。事实上这当中充斥着一些反复代码，以及一些没有測试的模块，代码组织也不够合理。这些问题都是须要处理的。

先来说说几个经常使用的术语

• router
  
  路由模块负责请求的分发。把请求转给详细的controller。controller是每一个请求进来之后处理的逻辑，而route则定义了请求应该进入那个controller。

• controller
  
  controller是一个完毕某项任务的调度中心，不设计详细的数据库操作，也不做页面渲染。仅仅负责获取现有的数据。加工处理。调用相应的接口把数据呈现给client。

• middleware
  
  我们知道server响应一个client请求通常是串行的操作。由路由模块把请求分发到详细的controller，在分发到controller之前我们能够对这些数据做一些欲处理操作。比如推断请求头部的 content-type 字段提前把数据解析好，比方过滤一些包体过大的请求等。

  完毕这些任务的模块一般称为中间件。也叫过滤器吧！

1. 利用MVC结构来又一次布置代码

在转nodejs开发之前写过一些PHP的代码，深受其代码结构的影响。传统的MVC架构清晰并且easy理解。看过了一些开源项目的代码结构，感觉server端代码结构还是有很多能够借鉴的地方。因为前端界面是基于canvas来绘制的，所以不存在传统意义上的渲染界面操作，server仅仅完毕一些主要的CURD操作就可以。

1.1 引入Router模块

依据详细的业务逻辑抽象在controller之前引入一个Router来分发请求。express4.x提供了一个Router函数，摈弃了之前把请求直接挂载到全局app对象上的做法(app.use(”api/a’, controler))。

推荐的做法是把不同的业务模块挂在不同router对象上(app.use(‘/api/a’, webRouter))。再把router挂在app对象上。

  //之前的做法

  var app = express();

  app.post('/api1/a', ControllerA);

 //推荐做法

 var app = express();

 //user manager

 var router = express.Router();

 router.post('/api1/a', ControllerA);

 app.use('/api1', router);

1.2 把几个反复的校验操作抽象为filter(middleware)

在一些须要验证用户是否登录的模块，须要推断用户的信息是否挂在session对象上。我们能够把这个操作抽象为一个过滤器。当我们发现几个模块都有相似的预处理操作时都能够抽象为过滤器的形式。

1.3 替换oauth模块

server端集成了各种社交帐号的授权登录模块，经过几个月的測试以及趋于稳定了，只是在不同浏览器上竟然还存在不一致的表现。

考虑到代码兴许的维护成本，还是放弃这个轮子了，nodejs有个passport模块能够来解决问题！

1.4 替换现有的Model模块

我们的数据库採用mongodb，现有的model模块基于原生的驱动来封装，须要写一些新功能的时候体力活比較多，考虑放弃这个轮子。当时在写PHP程序的时候写了一个ORM模块把数据库的操作抽象成对语言对象的操作。nodejs有不少的ORM模块，考虑使用mongose或者sequelize来完毕这个任务。

1.5 优化异步处理

从接触Nodejs开发起，一个不得不正视的问题是怎么把异步处理写的优雅。简洁。有四个方式能够选择，

• fibjs . 我们知道nodejs基于异步io，在调用一个异步函数等待返回的时候都须要注入一个回调函数。

  假设我们能够把这个等待处理结果的过程默认给实现了，这样就能解决回调的问题。 fibjs 正好能够解决问题。

  只是 fibjs 严重的模块侵入方式。也就是说原先的npm模块都得拿来改动。

• 第三方异步处理模块 . nodejs经过这些年的发展逐渐出现了一些开源模块来解决异步的问题。如async/eventproxy/step/等等。这些模块基于事件处理的方式来解决回调金字塔的问题。

• Promise . Promise是一个非常优秀的理念。通过把一些小的功能函数封装成promise函数，一个复杂的请求事实上就相应着一个promise函数链。

  简洁优雅的代码组织方式。良好的异常捕获机制都是Promise的长处。只是promise存在的一个问题是，假设一个模块用promise写好了，差点儿其他与之相关的模块都得换成promise的形式。

• KOA . koa积极拥抱ECMA6标准，其利用co模块实现， 同步代码抒发异步情怀！

  koa 须要重写整个server模块，打算后面来干这个事情，故舍弃之。promise涉及的代码非常多，不会比直接使用koa轻松多少所以也暂且放弃。打算选择一个折中的方式，一些轻量模块就直接用回调好了，相信良好的抽象能力也能解决一部分问题。较复杂的异步操作就通过第三方异步模块来完毕。学习成本不大，拿来就用，何乐不为呢！

2.引入自己主动化測试模块

1.1 基本測试

測试的重要性不言而喻。之前在开发的过程中也给一些比較重的模块写呢一些測试。可是都不成系统，不够完好。

单元測试计划使用assert加shouldjs配合mocha来完毕外加一个mock模块来完毕，另外mocha能够方便的生成代码覆盖度測试报告。server端集成測试能够使用superagent来模块请求、校验请求结果。

1.2 pre-commit hook

每次提交都触发測试，动态检測代码健壮性。

这样也就能防范于未然了。

1.3 锁定版本号

Nodejs生态圈非常繁荣。我们项目使用的非常多都是开源模块，为了保证项目稳定性，规避一些第三方模块的BUG。在測试稳定后把版本号锁定。

---

时间计划

3 天