我对前端工程化的理解

随着项目越做越大,同质化项目越来越多,在前端多人协作开发的模式下,前端项目的工程化也越来越重要

前端工程化要解决两个问题:

  提高开发效率

  降低维护难度

提高开发效率:

  定制化脚手架:

    最近在尝试研究脚手架,因为之前一直使用vue脚手架来开发,对于底层的一些东西不是很了解,后来有了一些明白,vue脚手架本质上是利用node的native能力和npm的包管理能力以及webpack打包能力 来打造成一套基于vue的webpack开发套件,这样理解:我们在开发像目前一定需要搭建开发环境,现在基本上都是搭建webpack开发环境,然后还有一些基本的项目组织结构等等,这些东西基本上同质化的项目都是一样的,所以我们如果想要编写自己的脚手架,我们就可以先把这些环境搭建好,然后上传到gitlab上,然后利用npm的bin能力,通过执行cmd脚本将gitlab上代码从远程下载下来,下载下来之后利用node的本地文件操作能力,将文件保存到制定位置,然后利用node异步执行npm install将所有依赖下载下来,那我们为什么要费这么大劲呢?一个公司的项目如果底层是一致的话,特别是webpack编译这块是统一的话,那再后面对所有项目进行统一的处理是很提高效率的,比如说 后面需要对所有前端项目进行埋点,那可能就不需要前端开发人员去做什么了,之间架构师在底层代码做处理,然后前端开发人员更新一下脚手架就可以了

  组件化开发:

    组件化开发的重要性不必再说了,在这里我们要讨论的是将开发强业务类型组件,我们把Element比作是弱业务类型组件,一些只有公司内部使用的 与行业相关性非常强的我们可以将该业务逻辑抽离出来,做成一个组件,比如说笔者所在的公司开发一个教师资料卡,把这个教师资料卡做成一个组件 在其他任何项目上 只要需要使用教师资料卡,可以直接npm引入该资料卡,传入一个 教师身份验证就可以弹出一个教师资料卡,这里的关键是将所有组件放到一个公司内部私有的npm服务器上,我是用的Verdaccio。在开发业务型组件的时候不可能单独为每一个业务型组件去搭建一套开发环境,笔者使用的是storybook来开发业务型组件。

  统一的代码风格:

    统一的代码风格在维护的时候会大大提高效率,笔者使用的是eslint

扫描二维码关注公众号,回复: 5170124 查看本文章

  将数据层单独抽离出来:

    这个只是在小项目中试用过,我们将前端与服务层和本地进行沟通的部分单独抽离出来做成一个项目,同时将数据校验部分也拿过来,这里的数据校验不仅仅是提交表单的数据校验,也包括获取数据的对数据做的一些准确性校验,这样做的目的是减少业务复杂度,同时如果将这块发布到npm上,前端在使用的时候,直接引入就好了,而如果其他项目也有这样的需求 是不是也可以直接引入这个数据层呢?这样就不用再去写一个数据层了

  前端发布自动部署:

    如果从提高开发效率的角度来说,这个应该是必不可少的,但是手动部署也不是不可以,自动部署做到的时候,监听代码提交,自动重新部署,因为现在前端也使用node做代理,所以也要启动一个服务,同时在使用node-Koa做中中间层处理的时候也需要重新启动服务,具体实现逻辑是 :在Linux服务器写一个脚本,监听某一个端口(比如说8080),然后脚本中编写远程拉取最新代码和重启服务的脚本,然后在gitlab上绑定webhhok,webhook是一个实时的用于服务器端通信的技术,这边代码提交后,gitlab会通过webhook通知到linux服务器的脚本,linux服务器的脚本会自动拉取远程master代码,并重启pm2

  Node中间层:

    Node中间层负责对服务器端提供的RESTful风格接口做进一步的处理,实际上如果不单独做一个node中间层,而是直接写在前端js里面也是可以的,单无疑增加了代码复杂度。这也契合了工程化中不断解耦分治的概念

  

猜你喜欢

转载自www.cnblogs.com/mrzhu/p/10382813.html