前端开发中减小重复劳动，提高效率的方法

内容来源：2018 年 6 月 23 日，饿了么前端技术专家徐辛承在“饿了么技术沙龙・第27弹 【前端专场】”进行《中后台场景下的工具化和平台化实践》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：3099 | 8分钟阅读

获取嘉宾演讲视频及PPT： suo.im/4vQeeG

摘要

前端领域有两大永恒的主题——性能和效率，中后台场景下对性能的要求不高，但对效率的要求是极致的。在这种背景下，咱们在业务开发过程当中孵化出了几个工具和平台，分享下咱们的设计和思考。

背景

在任何技术领域中性能和效率一直都备受关注。中后台项目中因为移动化办公还没有普及，目前大多数仍是以PC页面的形式展示 ，用户使用平台的目的也较为单一，仅是为了工做。

这种场景下性能通常不是关注的重点，加载时间即便是二、3秒影响也不会太大，且PC的硬件设备和网络情况相对移动端要好不少，只要稍加注意性能就不会有什么问题。

可是在效率（工程效率）上却要有极致的提高，由于中台场景中页面会很是多。就以供应链场景举例，咱们的供应链下有N个系统，首先是采购系统，采购完后存储到仓库，仓库中有仓储系统，以后是配送和营销。这整一套流程须要有一个数据平台来支撑，不管是正向仍是逆向，所以页面数据会很是多，对开发效率有很高的要求。

工具和平台的实践

开发效率方面通常能想到的优化就是减小重复劳动。前端开发阶段能够经过一些工具或平台减小开发上的重复，也能够从整个项目链路来看有哪些可优化点，好比联调、测试、线上维护等方面。针对这两点，咱们主要作了3个实践：IDE插件、“Mock”平台、模板仓库平台。

IDE插件

通常要提升在IDE中编写代码的效率采用的都是IDE自己提供的snippets的方式，可是这些snippets存储在本地，没法进行共享。插件的形式无疑能很好的解决问题，因为咱们的场景使用的是Element UI，因此专门定制了一个插件pickman。与大多数拥有相似功能的插件同样，它能够将特定的代码片断插入到IDE中。另外为了减小查看文档的耗时，咱们提供了更方便的文档查看方式，在选中标签以后按下cmd+1（mac）就会打开文档中相应的页面并展现在IDE中。

“Mock”平台

在没有真实数据接口的状况下若要调试数据最多见的方法是mock.js，经过一些规则随机生成一些相应的数据。

大体流程如上。先通过设计评审出一份接口设计文档，以后前端根据文档mock数据，开发过程当中与后端合做校订协议，后端使用postman之类的工具修正接口，最后进入真实数据联调阶段。

不过上面的过程当中存在几个问题。

一是如何维护mock数据。好比针对某个页面生成mock数据的文件夹路径如何存放，若是存放在js同级目录下，上线的时候就要剔除掉这些json数据，若是是统一文件夹存储，那么就要针对代码中请求路径进行替换。另外一方面是没法保持实时更新，致使数据陈旧无人维护，又要从新生成新的mock数据。

二是如何约束接口文档。一般咱们是将文档规则写在wiki中，不过这样很难保证真实性，好比字段数据类型是否正确、request和response顺序问题。

三是如何避免脏代码注入。

前两个问题已被开源平台Rap2很好解决了，该平台主要分为用户和API两个维度的管理。每一个用户会被分配到不一样团队，目的是为了权限控制，防止API滥用；API管理方面有API仓库进行api分类。

至于脏代码注入其实能够经过proxy方式来解决，好比在webpack的proxy中写入dev环境下对应的domain。另外还有一个问题没有提到，就是如何迁移wiki，由于文档都是在wiki中，若是要迁移已维护好的文档成本会相对较。为此咱们作了一个迁移工具，它会遍历整个wiki的dom进行归类，而后取出全部的数据转化成json，最后将json导入到平台中。

字段重复

平台中API管理部分的字段重复度很高，以供货商采购的流程来讲，其中有个skuinfo（商品数据）的概念，这个skuinfo的规则是固定的，好比ID必须为9位数字、number为string等等。可是因为每一个API的管理相对孤立，不一样的人写的API的生成规则就有可能不一样，这形成的问题一方面是不规范，另外一方面增长了重复劳动。

因此咱们引入了实体的概念，每一个实体能够是一个对象或属性。它细粒度到每一个value的维度，不只实体之间能够相互引用，API和实体间也能够相互引用。这样就能够将全部重复的工做抽象成一个实体，另外还能够对实体部分进行权限控制，这两个措施本质上是让每一个字段有准确、惟一的生成规则。

新的问题

纵观整个开发流程，其实中后台场景下QA测试的时候关注的是数据流转的正确性，并不关注UI和UE的细节。其次因为咱们的项目成立时间较短QA人员不足任务又比较紧张，因此初期是以黑盒测试为主。这种状况下为了保证质量，就须要引入自动化测试机制，主要有三个阶段模拟输入、自动编写测试case、验证输出。

基于上面的考量，能够发现咱们须要的不只是单纯的Mock平台，而是mock加自动化测试的辅助平台。目前咱们所能作的是给自动化测试提供输入，由于mock阶段和自动化测试阶段本质上有类似性。Test case环节要由QA维护，咱们这边能作的有限。验证输出环节则能够作一些相应工做，自己mock的正向流程就是从规则生成数据，而验证环节刚好相反是以数据验证是否符合规则。

将来规划

在将来规范上咱们首先要实现的是验证输出的部分，其次是丰富mock规则以及可视化，还会作一个更新检测工具来验证这次更新是否符合mock平台的维护文档，最后是关于业务流程的测试。

模板仓库平台

要想快速开发大量的1.0项目，你们一般可能会使用脚手架工具。可是这里存在几个问题，首先脚手架工具没法作到快速预览，其次对于这类工具来讲页面就是最小维度，没法再细分到组件片断层面，最后它主要面对的是开发者，而中后台项目中UI和UE的规则又相对比较统一，原型图和最终页面十分类似，这样的话直接经过拖拽组件造成页面和实际编写模板代码其实并没有太多差异。

基于以上缘由咱们构建一个模板仓库平台，经过可视化的组件拼装，快速生成页面代码。目前已经支持了模板上传和在线预览。

以后咱们可能还会新增命令行工具，便于开发者使用。也会逐步摆脱对组件库和框架的依赖，实现彻底的零依赖。

经验总结

工程化

我的理解工程化所须要实现的目标有4个，可用性、可维护性、稳定性、提高效率。若想在前端工程化方面有更多的探索，效率提高这块是重点，它基于模块化、规范化、自动化来实现。具体实践中咱们会从架构层面作模块化和规范化，自动化事务由平台负责，使用工具减小开发过程当中的耗时。

技术项目

在开发以前找出当前业务中的痛点，肯定要解决的问题。开发过程当中制定渐进加强的计划，逐步完善项目切勿想一蹴而就，为了缩短开发周期能够由团队中相对高阶的同窗对项目进行模块拆分，分配给其余同窗。开发完成后必定要进行快速的迭代和响应，认为时机成熟就能够去作推广，并使用可量化的数据来展示成果。