你一定是闲得蛋疼才重构的吧

on 2018-07-23 | by 奇舞团关注作者

挑战进一步优化 1. HTML瘦身 2. 渐进渲染 3. 优化图片重构的收益参考

随着“发布”进度条走到100%，重构的代码终于上线了。我露出了老母亲般的围笑……

最近看了一篇文章，叫《史上最烂的开发项目长啥样：苦撑12年，600多万行代码》，讲的是法国的一个软件项目，因为各种奇葩的原因，导致代码质量惨不忍睹，项目多年无法交付，最终还有公司领导入狱。里面有一些细节让人哭笑不得：一个右键响应事件需要花45分钟；读取700MB的数据，需要花7天时间。足见这个软件的性能有多糟心。

如果让笔者来接手这“坨”代码，内心早就飘过无数个敏感词。其实，笔者自己也维护着一套陈酿了将近7年的代码，随着后辈的添油加醋……哦不，添砖加瓦，功能逻辑日益复杂，代码也变得臃肿，维护起来步履维艰，性能也不尽如人意。终于有一天，我听见了内心的魔鬼在呼唤：“重构吧～～”

重构是一件磨人的事情，轻易使不得。好在兄弟们齐心协力，各方资源也配合到位。我们小步迭代了大半年，最后一鼓作气，终于完成了。今天跟大家分享一下这次重构的经验和收益。

挑战

此次重构的对象是一个大型单页应用。它实现了云端文件管理功能，共有10个路由页面，涉及文件上传、音视频播放、图片预览、套餐购买等几十个功能。前端使用QWrap、jQuery、RequireJS搭建，HTML使用PHP模板引擎Smarty编写。

我们选择了Vue.js、vue-router、vuex来改造代码，用webpack完成模块打包的工作。仿佛一下子从原始社会迈向了新世纪，是不是很完美？

（图片来自网络）

由于项目比较庞大，为了快速迭代，重构的过渡期允许新旧代码并存，开发完一部分就测试上线一部分，直到最终完全替代旧代码。

然鹅，我们很快就意识到一个问题：重构部分跟新增需求无法保证一致。比如重构到一半，线上功能变了……产品不会等重构完再往前发展。难不成要在新老代码中并行迭代相同的需求？

别慌，一定能想出更高效的解决办法。稍微分析一下，发现我们要处理三种情况：

1. 产品需要新增一个功能。比如一个活动弹窗或路由页面。

解决方法：新功能用vue组件实现，然后手动加载到页面。比如:

const wrap = document.createElement('div')
document.body.appendChild(wrap)
new Vue({
  el: wrap,
  template: '<App />',
  components: { App }
})

如果这个组件必须跟老代码交互，就将组件暴露给全局变量，然后由老代码调用全局变量的方法。比如：

// someApp.js
window.someApp = new Vue({
  ...
  methods: {
    funcA() {
      // do somthing
    }
  }
})

// 老代码.js
...
window.someApp.funcA()

注意：全局变量名需要人工协调，避免命名冲突。PS：这是过渡期的妥协，不是最终状态。

新增一个路由页面时更棘手。聪明的读者一定会想到让新增的路由页面独立于已有的单页应用，单独分配一个URL，这样代码会更干净。

假如新增的路由页面需要实现十几个功能，而这些功能已经存在于旧代码中呢？权衡了需求的紧急性和对代码整洁度的追求，我们再次妥协（PS：这也是过渡期，不是最终状态）。大家不要轻易模仿，如果条件允许，还是新起一个页面吧，心情会舒畅很多哦。

2. 产品需要修改老代码里的独立组件。

解决方法：如果这个组件不是特别复杂，我们会以“夹带私货”的方式重构上线，这样还能顺便让测试童鞋帮忙验一下重构后有没有bug。具体实现参考第一种情况。

3. 产品需要修改整站的公共部分。

我们的网站包含好几个页面，此次重构的单页应用只是其中之一。它们共用了顶部导航栏。在这些页面模板中通过Smarty的include语法加载：

{%include file="topPanel.inc"%}

产品在一次界面改版中提出要给导航栏加上一些功能的快捷入口，比如导入文件，购买套餐等。而这些功能在单页应用中已经用vue实现了。所以还得将导航栏实现为vue组件。

为了更快渲染导航栏，需要保留它原有的标签，而不是在JS里以组件的形式渲染。所以需要用到特殊手段：

在topPanel.inc里写上自定义标签，对应到vue组件，比如下面代码里的<import-button>。当JS未加载时，会立即渲染导航栏的常规标签以及自定义标签。

<div id="topPanelMountee">
  <div id="topPanel">
      <div>一些页面直出的内容</div>
      ...
      <import-button>
        <button class="btn-import">
          导入
        </button>
      </import-button>
      ...
  </div>
</div>

导航栏组件：topPanel.js，它包含了ImportButton等子组件（对应上面的<import-button>）。等JS加载后，ImportButton组件就会挂载到<import-button>上并为这个按钮绑定行为。另外，注意下面代码中的template并不是<App />，而是一个ID选择器，这样topPanel组件就会以#topPanelMountee里的内容作为模板挂载到#topPanelMountee元素中，是不是很机智～

// topPanel.js
new Vue({
  el: '#topPanelMountee',
  template: '#topPanelMountee',
  components: {
    ...
    ImportButton
  }
})

彻底重构后，我们还做了进一步的性能优化。

进一步优化

1. HTML瘦身

在采用组件化开发之前，HTML中预置了许多标签元素，比如：

<button data-cn="del" class="del">删除</button>
<button data-cn="rename" class="rename">重命名</button>
...

当状态改变时，通过JS操作DOM来控制预置标签的内容或显示隐藏状态。这种做法不仅让HTML很臃肿，JS跟DOM的紧耦合也让人头大。改成组件化开发后，将这些元素统统删掉。

之前还使用了很多全局变量存放服务端输出的数据。比如：

<script>
    var SYS_CONF = {
        userName: {%$userInfo.name%}
        ...
    }
</script>

随着时间的推移，这些全局变量越来越多，管理起来很费劲。还有一些已经废弃的变量，对HTML的体积做出了“贡献”。所以重构时只保留了必需的变量。更多数据则在运行时加载。

另外，在没有模板字面量的年代，HTML里大量使用了script标签存放运行时所需的模板元素。比如:

<script type="text/template" id="sharePanel">
    <div class="share">
        ...
    </div>
</script>

虽然上线时会把这些标签内的字符串提取成JS变量，以减小HTML的体积，但在开发时，这些script标签会增加代码阅读的难度，因为要不停地切换HTML和JS目录查找。所以重构后删掉了大量的<script>标签，使用vue的<template>以及ES6的模板字面量来管理模板字符串。

2. 渐进渲染

首屏想要更快渲染，还要确保文档加载的CSS和JS尽量少，因为它们会阻塞文档加载。所以我们尽可能延迟加载非关键组件。比如：

延迟非默认路由

单页应用有很多路由组件。所以除了默认跳转的路由组件，将非默认路由组件打包成单独的chunk。使用import()的方式动态加载。只有命中该路由时，才加载组件。比如：

const AsyncComp = () => import(/* webpackChunkName: "AsyncCompName" */ 'AsyncComp.vue')
const routes = [{
  path: '/some/path',
  meta: {
    type: 'sharelink',
    isValid: true,
    listKey: 'sharelink'
  },
  component: AsyncComp
}]
...

延迟不重要的展示型组件

这些组件其实可以延迟到主要内容渲染完毕再加载。将这些组件单独打包为一个chunk。比如：

import(/* webpackChunkName: "lazy_load" */ 'a.js')
import(/* webpackChunkName: "lazy_load" */ 'b.js')

延迟低频的功能

如果某些功能属于低频操作，或者不是所有用户都需要。则可以选择延迟到需要的时候再加载。比如：

async handler () {
  await const {someFunc} = import('someFuncModule')
  someFunc()
}

3. 优化图片

虽然代码做了很多优化，但是动辄几十到几百KB的图片瞬间碾压了辛苦重构带来的提升。所以图片的优化也是至关重要滴～

1. PNG改成SVG

由于项目曾经支持IE6-8，大量使用了PNG，JPEG等格式的图片。随着历史的车轮滚滚向前，IE6-8的用户占比已经大大降低，我们在去年放弃了对IE8-的支持。这样一来就能采取更优的解决方案啦～

我们的页面上有各种大小的图标和不同种类的占位图。原先使用位图并不能很好的适配retina显示器。现在改成SVG，只需要一套图片即可。相比PNG，SVG有以下优点：

压缩后体积小无限缩放，不失真 retina显示器上清晰

2. 进一步“压榨”SVG

虽然换成SVG，但是还远远不够，使用webpack的loader可以有效地压缩SVG体积。

用svgo-loader去除无用属性

SVG本身既是文本也是图片。设计师提供的SVG大多有冗余的内容，比如一些无用的defs，title等，删除后并不会降低图片质量，还能减小图片体积。

我们使用svgo-loader对SVG做了一些优化，比如去掉无用属性，去掉空格换行等。这里就不细数它能提供的优化项目。大家可以对照svgo-loader的选项配置。

用svg-sprite-loader合并多个SVG

另外，SVG有多种用法，比如：img，background，inline，inline + <use>。如果某些图反复出现并且对页面渲染很关键，可以使用svg-sprite-loader将多个图合并成一个大的SVG，避免逐个发起图片请求。然后使用内联或者JS加载的方式将这个SVG引入页面，然后在需要的地方使用SVG的<use>标签引用该图标。合并后的大SVG如下图：

使用时：

<svg>
  <use xlink:href="#icon-add"></use>
</svg>

即可在使用的位置展现该图标。

以上是一些优化手段，下面给大家分享一下重构后的收益。

重构的收益

以下是重构带来的收益：

收益项重构前重构后组件化无 100% 模块化 50% 100% 规范化无 ESLint 代码规范检查语法 ES5 ES6+ 首屏有效渲染时间 1.59s 1.28s（提升19%）首次交互时间 2.56s 1.54s（提升39%）

组件化：从0到100%

老代码没有组件的概念，都是指令式的编程模式以及对DOM的直接操作。重构后，改为组件化以后，可以充分利用组件的高复用性，以及虚拟DOM的性能优化，带来更愉悦的开发体验。

模块化：从50%到100%

老代码中也用RequireJS做了一定程度的模块化，但是仅限于业务模块，没有解决第三方依赖的安装和升级问题。重构后，借助webpack和npm，只需要npm install安装第三方依赖，然后用import的方式加载。极大地提高了开发效率。

规范化：从0到1

老代码几乎没有代码规范，甚至连同一份文件里都有不同的代码缩进，强迫症根本无法忍受。重构后，使用ESLint对代码格式进行了统一，代码看起来更加赏心悦目。

ES6+语法：从0到大量使用

老代码所使用的库因为历史悠久，加上没有引入转译流程，只能使用ES5语法。重构后，能够尽情使用箭头函数、解构、async/await等语言新特性来简化代码，从而提升开发体验。

性能提升

根据上线前后Lighthouse的性能检测数据，首次有效渲染时间（First Meaningful Paint，FMP）提升 19% 。该指标表示用户看到有用信息的时间（比如文件列表）。首次交互（First Interactive，FI）提升 39%。该指标表示用户可以开始跟网页进行交互的时间。

以上就是这次重构的总结。不要容忍代码里的坏味道，更不要容忍低效的开发模式。及时发现，勇敢改进吧～

参考

Chrome 中的 First Meaningful Paint

Using SVG

Modern JavaScript Explained For Dinosaurs

文章来源：

Author：奇舞团
link：https://75team.com/post/yunpan_refactoring.html

下一篇：75CDN 增加 SRI 支持

上一篇：同学，W3C了解一下？

你一定是闲得蛋疼才重构的吧

挑战

进一步优化

1. HTML瘦身

2. 渐进渲染

3. 优化图片

重构的收益

参考

添加我喜欢的博客

编辑我的关注

更多推荐博客

你一定是闲得蛋疼才重构的吧

挑战

进一步优化

1. HTML瘦身

2. 渐进渲染

3. 优化图片

重构的收益

参考

添加我喜欢的博客

编辑 我的关注

更多 推荐博客

编辑我的关注

更多推荐博客