作前端也有“捷径”，科学偷懒大法了解一下！

如今前端很是火热，相关的技术更是层出不穷，前端人也在不停地学学学。那么有没有什么“偷懒”的方式，帮助咱们更加有效地完成编码的KPI呢？本人从事前端开发工做多年，负责公司多个大型项目前端架构设计与落地实践，本文就和你们聊一聊前端的“项目实践之道”与“变化之道”。

 

在进入正题以前，咱们先回顾一下前端的发展史。前端在最先期的阶段，又被称为“切图仔”——写一些简单的静态页面，而后交给后端组装起来；后面随着业务的发展，产生了更复杂的业务需求，jQuery，bootstrap等相继问世帮助咱们更快地开发；而随着外部对前端业务需求的增强，页面变得愈来愈复杂，原有模式的开发变得愈来愈吃力。这时诞生了MVVM概念，angular、react、Vue框架相继出现，这使得整个前端的发展进入到一个新时代。那么，如何在发展的浪潮中找到前端的“道”呢？

 

首先来看一则小故事：

 

行者问老和尚：“您得道前，作什么？”老和尚说：“砍柴担水作饭。”行者问：“那得道后呢？”老和尚说：“砍柴担水作饭。”行者又问：“那何谓得道？”老和尚回答说：“得道前，砍柴时惦记着挑水，挑水时惦记着作饭；得道后砍柴即砍柴，担水即担水，作饭即作饭。”

 

不难看出，老和尚得的“道”指的是同一时间专一作一件事。作前端也是同理。在得道前，咱们以为前端工做复杂，缘由在于同一时间考虑了好几项功能，一不留神就把全部东西都写出来，但代码的质量并不高。

 

1、何为前端工程化之道？

最重要的工做是对代码层次有效地拆解，咱们能够简单地将其划分为项目的框架、组件、服务、业务页面四个部分。框架分为基础框架和业务框架，搭建业务框架，目的在于提供总体的解决方案让其它区块（层）更加纯粹；善用组件库【基础组件（含样式）、业务组件】，减小重复的轮子；服务即为统一的方法集或者对于某一模型层的统一处理；而业务页面的重点在于专一业务自己。此外，还有模块化，微服务等等。咱们默认层与层之间是互相信赖的，当咱们在作其中某一项工做的时候，能够看成其余部分不存在，仅着手于咱们须要的。

 

此外，咱们也能够从另外一个角度将层区分为：数据层（包括封装了对数据的一些基础处理）、逻辑层（项目较大，逻辑层可能会被拆成多层）和视图层。

 

在拆解项目的过程当中，划分目录结构很关键。固然，如今的CLI在目录结构上帮咱们拆好了一部分，好比下面这个vue-cli给咱们生成的结构：

 

它在建立项目的时候会自动帮咱们建立目录结构，简化了咱们初始化项目时的工做。但这个项目结构仔细来看过于简单，更接近demo的状态，于是咱们须要再对这个结构进行改进。咱们须要创建一个业务框架，规划更健全的目录结构，同时包一层方法库（如权限、请求）并提供统一处理函数及全局拦截相关的处理，搭配好必要的全家桶套餐等。

2、前端工程化之目录结构拆分实践

下图是咱们某一个项目的结构。它相对复杂，包括PC端和移动端两部分，共用的部分就在common文件里。它包括assets（图片、资源信息）、components（一些公共的组件）、过滤器、mixin（一些用于合并的模块）、service（公共服务）、stores（数据存储）、utils（预处理函数，工具）。

 

PC文件夹里有一些特有的静态资源、文件、插件。Mobile这个文件夹也是同样的道理。这个项目里的components更倾向于通用业务组件，plugin则倾向于放一些引起效果变化的插件；router是一些路由信息；views是一些业务的组件。经过这样的分层，写业务的同窗能够在views里去写；即使是一我的负责全部部分，他也可以在各个环节都保持专一。

3、实例：个推部分产品架构设计实践

个推拥有较为丰富的产品线，其中有的产品线下不一样产品的主要功能模块近似，但这些产品之间又相互独立。因此，若是咱们逐个开发单个产品，代码会被重复拷贝屡次，若其中一个须要修改，则其余的都要作相应的调整。那么咱们如何解决这个问题呢？

 

这里先介绍几个具体的概念。

产品：每一个具体的APP就是一款产品。

项目代码：包括广义的gulp/src/cloud等，与狭义的src文件夹。

 

基于这些，咱们想到了一个方法：源代码做为独立的一部分，对于不一样产品使用不一样配置及特殊组件，而后打包成不一样的产品。

 

 这是根据以上设计模式画的示意图。

 

 

咱们内部有一个组件库，包括基础组件和样式组件。

 

个性化的部分

首先把这些模块拆分为一个个小的组件，这里咱们用三角形、圆形和方形表示；而后结合原来的基础组件，组成部分功能组件；接下来经过功能组件的堆积，造成各个具体的业务功能。于是总体上，个性化部分（业务功能的不断自我调用）至关于一个模块了，能够组装到某个产品中，它的最终形式是由相关的配置决定的。此外，view里的插槽的区块，是由产品来定义插槽中业务组件的最终展示形式。

 

公共的部分

数据层会提供一些支撑服务，主要是帐号服务，与临时存储相关。咱们也针对数据层进行了划分：API call借鉴RPC思惟，造成通用发请求的方法；Model call是比较早期的一种模式，会把具体的请求服务分装好；get json是针对某一部分没有封装成后端接口源数据的文件。

 

视图层主要有两部分，不一样产品的配色不一样，文案也不一样。

 

以上就是咱们总体的一个架构。

 

4、关于架构模块划分的一些TIPS

下面给你们介绍一下咱们须要的一些工具：1、自写node小程序用于检查一些权限，比肉眼更精准；2、自建CLI，基于项目实践流程，将一些固化的工做写成工具集成到自有的CLI里面。随着项目演进，咱们将apps文件夹拆成了独立的仓库管理，并写了一个脚本，让其和主程序软链，从而直接能够运行。

 

前面，咱们也提到了组件库。除了业务框架的细分，咱们还须要对组件进行分类，包括：样式库、公共函数库、**js**的插件、业务组件、模块化。

 

至于组件库的范围，咱们能够分为全范围级别组件库、产品线级别组件库、项目自有组件库、专项组件库。

 

5、前端的变化之道

由于如今前端很火热，因此相关的一切皆在变化，包括技术栈、业务、设计思路、架构等等。不只如此，业务需求、开发人员、项目复杂度、实现思路等等也在变化，这些变化有可能有意无心地致使咱们的代码正在慢慢“变坏”。

 

咱们发现代码写得越大，坏得越快，由于接触的点太多。于是，当代码出现了“坏味道”的时候，咱们须要尽快地把它们校验出来。有一个效应叫“破窗效应”——即一个地方有不少窗户，其中一块玻璃被打破了，若是你不去管它，以后你会发现愈来愈多的玻璃被打破。于是代码出现了问题须要当即解决，不然问题通过多年积累，到最后咱们会发现项目已经改不动了，只能弃船逃跑，新起炉灶。

 

上一个实践的优点，有可能成为下一个实践的劣势。早期咱们发现二级菜单中的几个列表业务功能很是接近，咱们将其合起来求同存异，很容易管理。后来，功能近似的二级菜单愈来愈多，全部的二级模块混在一块儿，差别内容也聚沙成塔，咱们再想改的时候便异常痛苦。对此，咱们的一个解决思路是，当咱们发现代码实践方式有些“别扭”的时候，就要作一些重构和修正方案。但这不是一蹴而就的，也不是到某个点为止，而是须要一直去作。

 

还有一个不得不提的变化，是官网内的一些项目，即从SSR到SSR。在先后端未分离的时候，须要ASP、PHP、JSP之类的服务端静态页面渲染。后来前端工程的能力愈来愈强，能够实现浏览器端渲染；再到现在，诞生了vue的SSR。如今咱们可能会用SPA的方式开发，其缺点是SPA对于官网而言可能会比较“重”，或者说咱们更加习惯目前的开发方式，难以适应jQuery时代的开发。可是另外一方面，多页面也存在必定好处——每一个页面都很是独立，能够更好地SEO，用户也能够享受更快的到达时间。因此，从SSR到SSR，看上去好像倒退了，但实际上这是一个螺旋上升的过程。

 

此外，外部也在发生着一些变化。好比，angular到6了，Webpack 4发布了，Node之父推新产品了等等…

六：结语

市场变化太快，虽然技术很重要，但思想比技术更重要。技术是学不完的，但思想能够类比，甚至是能够创新的。基于新的思路，也许你也能写出新的算法，新的技术。