上周没有更新原创技术文章，原因是忙着重构一个新接手的项目，此项目因为项目技术负责人离职，虽然投入人力持续增多，前端达到4人，后端3人，但因为新参与的童鞋对代码结构和业务的理解，导致项目开发了一个多月，还有一堆问题，达不到上线要求。接手项目之后，一开始对项目业务场景和代码进行简单的了梳理，跟了一天项目，观察提测后FE+RD的状态，自己也动手改了一天代码，不管是FE+RD包括自己都觉得实在是太难受了，小坑大坑不断，于是决定重构。重构不是个人冲动，而是的的确确存在各种大大小小的问题：

接口太碎：项目本身按照Vue组件化开发，但是页面每个组件独自采用vuex+ajax请求管理自己的数据，比如：首页由轮播图、各种列表和用户信息展现组成，导致首页从上到下7~8个模块，每个模块都各自发自己的请求，访问首页需要同时发出8个ajax请求
因为「1」提到的，单个组件数据都是使用Vuex进行管理，导致Vuex的store太乱：而且FE按照组件去开发，各自跟后端RD兑接口、联调，但是没有人来统筹安排，导致大量重复工作；除此之外，action和mutation中的业务逻辑代码太多，而不同页面需要不同的数据格式，则导致：

或者在mutation当中对数据进行重新整理
或者新开个接口，这样就造成接口越来越多，mutation部分代码越来越重。

一开始设计或者沟通有误。比如：用户信息相关的接口，需要传入用户id（uid），而不是通过登录cookie从passport获取；第三方接口需要用户信息，竟然请求的时候将cookie发给对方（幸好cookie是http only的，没有调通被我及时发现）
重复代码太多，抽象能力太差。一份代码在多个地方复制，导致代码改来改去最后都不知道哪里改了哪里没改
命名太乱，包括url、方法名之类，还有错别字，getAdcontent（用户地址信息），getmaildetail（用户地址信息）
研发人员缺乏全局意识，只管自己的代码，而不关心整个流程。由于前后投入人较多，没人对整个项目有把控，只能面向自己的需求编程。比如：积分获取页面，获取成功之后，联调成功，但是实际在积分获取列表页面却没有相关的记录信息；在比如：任何用户都可以领走别人的奖品，原因后端没做奖品是否是当前登录用户获取的校验
问题定位能力不够，遇见问题一调就是半天，找不到根本问题

介绍下项目背景：

此项目是一个用户积分任务和消费项目，一些页面需要用户登录，页面主要包括：首页、任务+列表、商品+列表、个人信息和记录以及其他类（说明和规则等）
项目用Vue+yog2编写，ajax请求部分使用vue resource

架构改造

整个项目还是用Vue+yog2来写，针对进入页面分为两种情况：

第一次通过网站URL进入某个页面，我称为：「首次后端渲染」
非首次已经进入页面URL后，用户点击链接在项目内跳页，我称之为：「非首次跳转」

整个流程整理如下：两个流程从「两个小人」开始看起

后端node Server代码部分

代码流程如下：

router → middleware → page/api action → model → ral请求数据

其中在action部分，专门写了个 baseAction函数，封装了重复的代码，使用时传入用于获取数据的model方法和处理数据的方法即可。

render部分，针对页面第一次请求需要将页面数据放在HTML片段中chunk输出，而不是通过ajax请求（为什么不用vue ssr，可以看下历史公众号文章《Vue SSR 从入门到Case Study》，之后单页内跳转是ajax请求）。详细代码如下：

client.tpl 部分代码：

baseAction 部分实现chunked

Client Vue部分代码

client主要流程是：

vue router → created时期 判断是否有页面数据 →
提交mutation（有数据），dispatch action（异步拉取数据）→ state触发修改，页面dom生成

这部分流程图主要展现是Vuex和Vue resource部分的代码，通过Vuex的dispatch action，触发Vue resource的异步请求，等返回数据则commit mutation。

后端渲染+SPA单页应用

经过改造后整个流程变成：

「首次后端渲染」：此时需要后端渲染主要HTML+页面数据，利用chunked，先将不依赖后端数据部分返给浏览器，页面数据和后面的HTML拿到数据后再返给浏览器。 client.tpl被「一分为二」：HTML[0] + HTML[1]

将页面通用的css和js lib库，放在HTML[0]中，首先返回，浏览器先解析下载
业务代码初始化代码放在HTML[1]，等到获取到后台API数据一起返回

「非首次跳转」：这是一个单页应用的流程，用户点击链接，实际走的是vue的router，然后出发vue页面渲染，URL是通过history pushState mode更改实际URL，这时候如果强刷或者复制url在浏览器打开，又走「首次后端渲染」

vue页面渲染需要的数据是通过vue-resource发起ajax请求，拿到数据之后commit mutation改变state

Vuex梳理

之前代码每个组件都单独ajax请求自己的数据，导致Vuex的module特别多特别乱，而且后端api接口太多太碎，不好维护。最后开发的童鞋自己都在群里抱怨，找个action或者mutation都不知道在哪个文件内，需要搜代码。。

首先做约定，明确什么时候使用Vuex：

页面view相关的数据才使用Vuex来管理，页面功能性ajax（例如签到、兑换）不要使用vuex；「首次后端渲染」和「非首次跳转」的view数据都通过commit mutation来修改state，最终映射到DOM表现上；功能性ajax则在组件内自己发请求实现，保持组件内聚；

P.S：这就是「贫血组件」和「充血组件」的区别，本身组件内的状态和逻辑都放在全局store管理，会增加store复杂度，降低效率（代码性能和开发效率）

然后，收敛vuex module

收敛是根据业务页面做的，前文提到：

页面主要包括：首页、任务+列表、商品+列表、个人信息和记录以及其他类（说明和规则等）

其中需要数据的有：首页、任务（详情、列表）、商品（详情、列表）和个人中心四个。

改造前module：

改造后module针对业务梳理的四个大页面内容，保留了四个：

减少mutation数据处理逻辑

复用后端接口数据格式，减少mutation数据处理逻辑

改造前很多action存在下面的代码（注意箭头部分）：

其中这个循环主要做两件事情：修改 type、修改 img_url为 url，实际根本没有必要：

修改 type：实际这已经是页面view层的逻辑了，在vue的模板或者computed中做更合适
修改 img_url为 url：这里实际是产品的封面图，改成 url反而更不合适了，而且导致了数据不一致

代码可以直接用 item即可！即不需要做额外的循环处理，保证数据一致性，避免前端的二次设计

API显性声明

之前所有的api都是走了一个 proxy，通过node转发一下，直接到了后台API接口，代码如下：

看似很方便甚至有点暗爽的实现，实则带来了下面的问题：

接口非显性声明，降低可控性，造成没法枚举有多少接口，各个接口需要什么参数，增加维护成本
安全性！后台这个服务是完全暴漏给了前端，如果存在敏感的接口，前端js就可以直接透传利用

改造后的代码放在model层，供「首次后端渲染」和「非首次单页」ajax请求使用：

优化

除了做代码重构改造外，还在间隙中做了一些优化，这里记录一下：

后端渲染使用chunked

详见本文「后端node server部分代码」和「后端渲染+SPA」

数据复用

很多页面设计会在首页和列表页面存在有产品的title、图片和简单的一些meta，例如下图：

点击链接进去详情页面可以直接利用，这部分数据我们做了复用。

实现方法是：页面点击的时候，将该条数据内容commit给下一个页面的mutation。

缓存

缓存在node和前端Ajax API多有，后端node主要缓存的是首页，因为首页需要请求4个接口（接口梳理后），其中三个接口是跟用户登录态无关的，这三个接口可以用lru-cache缓存起来。

前端的ajax api缓存是在 get请求增加的，可以根据实际情况用，根据url作为key，使用sessionStorage存储（同时cache类自己实现了缓存时间）

技巧

除了优化外，我在介绍下两个技巧：单页切换view的loading和统一的错误处理。

在单页跳转内，下一个view需要API请求获取数据，然后才能渲染，这时候需要加载个loading显示（或者做个切换动效）。

原理是：

利用eventBus，在router中添加两个事件 closeLoading和 vue .action .error，分别用于「关闭loading」和「展现页面数据错误的错误页」

loading展现在router的 beforeEach的钩子内实现，loading的事件在vuex的action获取数据成功之后发送

错误的触发有vuex 的 action / mutation 来发送事件

eventBus也不用自己写，可以直接用Vue实例的 $on、 $emit、 $once等就够了，代码如下：

import Vue from 'vue'
export default new Vue()

总结

重构主要做的事情是：

统一接口请求，重新梳理API；
收敛Vuex store设计（包括mutation/action的聚合，state简化）；明确Vuex的使用边界
明确组件职责边界，划分「充血组件」与「贫血组件」
抽象封装重复的代码逻辑
做了一些简单优化

说下成果：项目已经delay很久，从4月初到5月初已经一个月了还没上线，接手项目是五一前，整个重构共2个人力用了三天完成95%的工作，目前已经提测，

下面是重构项目的团队内部问题总结：

项目开发中一定要有大局意识，虽然现在项目多是分组件来的开发方式，但是开发前要跟大家交代清楚约定、规范，什么该做什么不该做；
技术负责人多 check 代码，防止错误的道路上越行越远；
要有全局意识，关注整个流程，不要只看到自己的「一亩三分地」，比如：在某个商品页面，购买/兑换成功了，不要认为没有问题了，可能记录页面还没有展现（后台接口没有入库）；
Don’t repeat yourself！看见重复代码就浑身难受，「抽象」能力是工程师的基本能力。
增强debug能力，发现问题直觉就能判断出来哪个环境，然后针对性debug