历史背景说明

## 前言 在大前端的趋势下，原来的切图仔或者说前端工程师已经不能承载实际需要，在开发以及调试中，我们需要一系列的方案来让我们的项目变得优化，规范，可配置等。本文就这方面做简单分析，并列出了一系列的解决方案， ## 了解我们所处的阶段 前端从无到有，从简单到复杂，从手动到配置，从融合到后端到主导用户应用，不断的对前端的工程化提出了新的概念和挑战，而在这一系列的工具或者方法中，简单分出以下几个阶段。 ### 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组件的开发。而另一部分人是负责使用以及维护，并不断提出优化建议。组件化开发的图示应该是下图所示：  提到组件开发，不仅仅是前端项目可以用，在很多以后台为主导的项目，组件的思路也可以得到灵活的应用。由此可见，以后我们应该更灵活的开发样式，脚本等。在提供一个大而全的框架的同时，也提供让用户可以根据自己的一个小需求，仅仅引入一个小的组件。  如果有以上的工程概念，那么为了实现优化，我们需要针对不同的组件指定开发者，并在一个开源项目上让大家的组件都是可见的。并且可以无缝的融合到一起，如果要做到这一点，就必须共同遵循同一套规则。其中版本管理的建议用git，而公司内部的gitlab已经为我们提供了便利条件。不同人员分工的图示如下：  ### 不同维度 就项目而言，一个组件是远远不够的，在实际的开发当中，我们的使用是分很多种情况的。 有的时候需要根据自己的业务，有的时候需要根据自己的组件，而有时候又是仅仅需要某些页面。所以针对不同的情况，我们可以参考以下的图示，同时需要了解到这种情况是允许存在的。  如果放到一个项目中，可能就是下图所示的结构。   针对中小型项目，建议的文档结构，也是我们目前正在逐步普及的目录结构。最常见的页面+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加载请求机制 可以根据自己的需求，灵活选择缓存安装还是本地代理安装还是企业内网安装 ## 其他 本文部分内容参考以下文档，表示真心的感谢！ * fouber：[前端工程化基础篇]