前端工程化-前端工程化说明

历史背景说明网址：

https://www.kancloud.cn/csnikey/fepro-guide/943173

前言

在大前端的趋势下，原来的切图仔或者说前端工程师已经不能承载实际需要，在开发以及调试中，我们需要一系列的方案来让我们的项目变得优化，规范，可配置等。本文就这方面做简单分析，并列出了一系列的解决方案，

了解我们所处的阶段

前端从无到有，从简单到复杂，从手动到配置，从融合到后端到主导用户应用，不断的对前端的工程化提出了新的概念和挑战，而在这一系列的工具或者方法中，简单分出以下几个阶段。

stage1：库、框架的选型

前端工程建设的第一项任务就是根据项目特征进行技术选型。
基本上现在没有人完全从0开始做网站，最少都会选下jquery，而React/Angularjs等框架横空出世，也让前端对页面交互、路由控制等有了更多的话语权。

stage2：简单构建

完成项目之后，一般我们都需要对项目中引用的文件进行简单的优化，包括校验、压缩、合并等，而目前市场上提供的构建工具有grunt,gulp,fis以及webpack等。
而市场上目前能做到这个阶段在业界来说已然超出平均水平，属于“具备较高工程化程度”的团队了，查看中国中小企业的网页源代码，能做到最基本的JS/CSS压缩的Web应用都已跨入标准互联网公司行列，不难理解为什么很多前端团队对于前端工程构建的认知还仅停留在“压缩、校验、合并”这种程度。
但是我们必须将自己的前端工作做到行业的前列，所以当下我们在仅仅停留在第一阶段的时候，需要快速进入第二阶段，迈向第三阶段。

stage3:JS/CSS模块化开发

分而治之是软件工程中的重要思想，是复杂系统开发和维护的基石，这点放在前端开发中同样适用。在解决了基本开发效率运行效率问题之后，前端团队开始思考维护效率，模块化是目前前端最流行的分治手段。
很多人觉得模块化开发的工程意义是复用，我不太认可这种看法，在我看来，模块化开发的最大价值应该是分治，只有根据自己的业务需要不断的整合并且开出新的分之，并且分别维护才可以让业务或者技术更加纯熟。而简单的模块复用是不足以应对复杂，多变的需求的。
分治的本质就是针对一对代码，一个文件，我们都应该将其定义为模块。JS模块化方案很多，AMD/CommonJS/UMD/ES6 Module等，对应的框架和工具也有很多；CSS模块化开发基本都是在less、sass、stylus等预处理器的import/mixin特性支持下实现的（本博客系统就是基于stylus实现）。

stage4：工程化问题的爆发

首先要认识到，前端是一种技术问题较少、工程问题较多的软件开发领域。很多人觉得前端门槛低，但是真到这个行业发现有若干的坑需要踩，没有写几行代码那样简单。那可能遇到什么问题呢？

1. 大体量：多功能、多页面、多状态、多系统；
2. 大规模：多人甚至多团队合作开发；
3. 高性能：CDN部署、缓存控制、文件指纹、缓存复用、请求合并、按需加载、同步/异步加载、移动端首屏CSS内嵌、HTTP 2.0服务端资源推送。

解决方案

如果要解决上面的问题，我觉得应该从以下几个方面入手，以后也将重点就以下几个方面以及项目中的具体问题做拓展。

整体规范

• 设计规范
  设计规范是一个前端工程界面部分规范不可或缺的部分，如果设计以及产品不能按照一定的规范执行，那么最终的产品体验以及工程化产物也是复用度很低，不适用于大多数项目的。所以要求公司对所有的公司产品从原型设计到设计稿设计，有整套的设计规范，去除不必要的自由发挥。

• 前端代码规范
  从源头开始制定代码规范，所有的代码符合这一规范，目前制定了包括html\css\js\less在内的代码规范。针对前端项目中遇到的问题，也将统一制定解决方案。比如web视频解决方案，时间控件解决方案，二维码解决方案等。

• 构建规范
  从构建工具开始，每一个细节告诉开发成员应该如何操作，怎样才是规范的，提供完整详细的教程文档以及辅导体制。减少使用不必要的，不规范的代码压缩、验证操作以及不规范的文档结构。

  组件化开发

• 前端作为一种GUI软件，光有JS/CSS的模块化还不够，对于UI组件的分治也有着同样迫切的需求。为了更好的实现代码复用，提高工作效率，我强烈建议在项目团队中应该有一定比例的人负责ui组件的开发。而另一部分人是负责使用以及维护，并不断提出优化建议
• 提到组件开发，不仅仅是前端项目可以用，在很多以后台为主导的项目，组件的思路也可以得到灵活的应用。由此可见，以后我们应该更灵活的开发样式，脚本等。在提供一个大而全的框架的同时，也提供让用户可以根据自己的一个小需求，仅仅引入一个小的组件。

• 不同维度

  就项目而言，一个组件是远远不够的，在实际的开发当中，我们的使用是分很多种情况的。
  有的时候需要根据自己的业务，有的时候需要根据自己的组件，而有时候又是仅仅需要某些页面。所以针对不同的情况，我们可以参考以下的图示，同时需要了解到这种情况是允许存在的。

• 针对中小型项目，建议的文档结构，也是我们目前正在逐步普及的目录结构。最常见的页面+less组件维度。

• 静态资源管理

• 如果说前端对客户端的优点，目前的界面以及交互式肯定比不上的，但是前端的gui界面没有安装的概念，而安装的概念就是把客户端里需要的ui全部本地存储一份。那如果前端在第一次需要的时候就加载全部文件，显然也是不合理的，所以规范的web应用也不会这么做。一般的做法是针对需求做增量更新，最常见的例子就是12306每次的web升级包，虽然它交互并不好。
  由“增量”原则引申出的前端优化技巧几乎成为了性能优化的核心，有加载相关的按需加载、延迟加载、预加载、请求合并等策略；有缓存相关的浏览器缓存利用，缓存更新、缓存共享、非覆盖式发布等方案；还有复杂的BigRender、BigPipe、Quickling、PageCache等技术。这些优化方案无不围绕着如何将增量原则做到极致而展开。
  资源管理的蓝图如下：其中构建工具的部分是通用的，具体选用的时候是针对性的。

• 工程化实践

• 技术选型

  • 规范：已制定的相关文档
  • 版本管理： git，严格按照版本管理+分之管理进行（支持多分之，bug分之，功能分之等）
  • 开源项目仓库：github,gitlab
  • 开发目录： src+dist+lib+test(测试)+ node_modules +bower_components
  • 前端构建工具： gulp +gulp基本插件（gulp-less等）
  • 组件开发工具：less
  • 前端页面模板引擎：tmod，artTemplate
  • 前端框架选型：jq+boot+jq插件
  • 前端ide ：hbuilder+emmet
  • 开发环境：chrome+devTool +模拟器
  • 包管理器：npm -package.json（npm init ,npm (un)publish,npm install）
  • 依赖资源加载：bower
  • 同步调试：browserSync 多终端同步调试工具
  • 前端依赖模块（浏览器环境）：requirejs (seajs)
  • js模块化： cmd,amd模块规范
  • 前端服务器：nodejs

  • 技术创新部分

  • • cnpm企业仓库
      支持内网npm仓库，比npm请求更快。支持企业内部的npm模块发布与使用。
    • gulp项目构建
      支持常见的插件使用，支持gulp的构建实践，实现了开发与生产目录的分离，切实的优化了web项目。
    • less组件命名规范化
      基于模块化之后的深度理解，着重使用less的相关规则，将样式拆分为不同分类，还有不同组件，将css的技术解决方案、兼容方案融合到组件当中。
    • npm模块的定义与发布
      研究了npm js模块的发布机制，可以自行发布模块，供内部员工使用。
    • 调试开发（browserSync）
      摒弃手动多端测试，实现多终端自动测试，开发同步修改。
    • 代码规范
      针对公司全体前端制定代码规范，提供前端页面初始化模板。
    • 多环境集成git
      包括git bash,toriseGit,hb,ws,eclipse多软件集成，让git版本管理使用便携。同时深度调研git版本管理命令行，提供git版本管理入门123系列教程，为公司提供技术支持。
    • nrm无痛切换多源
      可以让你在内网，外网多环境下使用npm命令行
    • npm加载请求机制
      可以根据自己的需求，灵活选择缓存安装还是本地代理安装还是企业内网安装