前端工程化需要怎么样的准备，性能？安全？监控？
问题描述
能不能有一个系统的答案？
自有前端工程师这个称谓以来，前端的发展可谓是日新月异。相比较已经非常成熟的其他领域，前端虽是后起之秀，但其野蛮生长是其他领域不能比的。虽然前端技术飞快发展，但是前端整体的工程生态并没有同步跟进。目前绝大多数的前端团队仍然使用非常原始的切图（FE）->套模板（RD）的开发模式，这种模式下的前端开发虽说不是刀耕火种的原始状态，但是效率非常低下。
前端工程化面临的问题
要解决前端工程化的问题，可以从两个角度入手：开发和部署。
从开发角度，要解决的问题包括：
提高开发生产效率；
降低维护难度。
这两个问题的解决方案有两点：
制定开发规范，提高团队协作能力；
分治。软件工程中有个很重要的概念叫做模块化开发其中心思想就是分治。
从部署角度，要解决的问题主要是资源管理，包括：
代码审查；
压缩打包；
增量更新；
单元测试；
要解决上述问题，需要引入构建/编译阶段。
开发规范
开发规范的目的是统一团队成员的编码规范，便于团队协作和代码维护。开发规范没有统一的标准，每个团队可以建立自己的一套规范体系。
值得一提的是JavaScript的开发规范，尤其是在ES2015越来越普及的局面下，保持良好的编码风格是非常必要的。
模块还是组件？
很多人会混淆模块化开发和组件化开发。但是严格来讲，组件（component）和模块（module）应该是两个不同的概念。两者的区别主要在颗粒度方面。《Documenting Software Architectures》一书中对于component和module的解释如下：
A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.
In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.
简单讲，module侧重的是对属性的封装，重心是在设计和开发阶段，不关注runtime的逻辑。module是一个白盒；而component是一个可以独立部署的软件单元，面向的是runtime，侧重于产品的功能性。component是一个黑盒，内部的逻辑是不可见的。
用通俗的话讲，模块可以理解为零件，比如轮胎上的螺丝钉；而组件则是轮胎，是具备某项完整功能的一个整体。具体到前端领域，一个button是一个模块，一个包括多个button的nav是一个组件。
模块/组件化开发的必要性
随着web应用规模越来越大，模块/组件化开发的需求就显得越来越迫切。模块/组件化开发的核心思想是分治，主要针对的是开发和维护阶段。
关于组件化开发的讨论和实践，业界有很多同行做了非常详细的介绍，本文的重点并非关注组件化开发的详细方案，便不再赘述了。笔者收集了一些资料可供参考：
Web应用的组件化开发；
前端组件化开发实践;
大规模的前端组件化与模块化。
模块和组件的争论由来已久，甚至某些编程语言对两者的实现都模糊不清。前端领域也是如此，使用过bower的同行知道bower安装的第三方依赖目录是bower_component；而npm安装的目录是node_modules。也没必要为了这个争得头破血流，一个团队只要统一思想，保证开发效率就可以了。至于是命名为module还是component都无所谓。
构建&编译
严谨地讲，构建（build）和编译（compile）是完全不一样的两个概念。两者的颗粒度不同，compile面对的是单文件的编译，build是建立在compile的基础上，对全部文件进行编译。在很多Java IDE中还有另外一个概念：make。make也是建立在compile的基础上，但是只会编译有改动的文件，以提高生产效率。
不论是大前端还是小前端，构建阶段在两种模式下的作用完全一致，构建的作用就是对静态资源以及模板进行处理，换句话说：构建的核心是资源管理。
资源管理要做什么？
前端的资源可以分为静态资源和模板。模板对静态资源是引用关系，两者相辅相成，构建过程中需要对两种资源使用不同的构建策略。
静态资源构建策略
静态资源包括js、css、图片等文件，目前随着一些新规范和css预编译器的普及，通常开发阶段的静态资源是：
es6/7规范的文件；
less/sass等文件（具体看团队技术选型）；
[可选]独立的小图标，在构建阶段使用工具处理成spirit图片。
构建阶段在处理这些静态文件时，基本的功能应包括：
es6/7转译，比如babel；
将less/sass编译成css；
spirit图片生成；
以上提到的几个功能可以说是为了弥补浏览器自身功能的缺陷，也可以理解为面向语言本身的，我们可以将这些功能统称为预编译。
除了语言本身，静态资源的构建处理还需要考虑web应用的性能因素。比如开发阶段使用组件化开发模式，每个组件有独立的js/css/图片等文件，如果不做处理每个文件独立上线的话，无疑会增加http请求的数量，从而影响web应用的性能表现。针对诸如此类的问题，构建阶段需要包括以下功能：
依赖打包。分析文件依赖关系，将同步依赖的的文件打包在一起，减少http请求数量；
资源嵌入。比如小于10KB的图片编译为base64格式嵌入文档，减少一次http请求；
文件压缩。减小文件体积；
hash指纹。通过给文件名加入hash指纹，以应对浏览器缓存引起的静态资源更新问题；
代码审查。避免上线文件的低级错误；
以上几个功能除了压缩是完全自动化的，其他两个功能都需要人工的配置。比如为了提升首屏渲染性能，开发人员在开发阶段需要尽量减少同步依赖文件的数量。
以上提到的构建功能只是构建工具的基本功能。如果停留在这个阶段，那么也算是个及格的构建工具了，但也仅仅停留在工具层面。对比目前较流行的一些构建产品，比如fis，它具备以上所得的编译功能，同时提供了一些机制以提高开发阶段的生产效率。包括：
文件监听。配合动态构建、浏览器自动刷新等功能，提高开发效率；
mock server。并非所有前端团队都是大前端（事实上很少团队是大前端），即使在大前端体系下，mock server的存在也是很有必要的；
模板的构建策略
模板与静态资源是容器-模块关系。模板直接引用静态资源，经过构建后，静态资源的改动有以下几点：
url改变。开发环境与线上环境的url肯定是不同的，不同类型的资源甚至根据项目的CDN策略放在不同的服务器上；
文件名改变。静态资源经过构建之后，文件名被加上hash指纹，内容的改动导致hash指纹的改变。
对于模板的构建宗旨是在静态资源url和文件名改变后，同步更新模板中资源的引用地址。
现在有种论调是脱离模板的依赖，html由客户端模板引擎渲染，简单说就是文档内容由JavaScript生成，服务端模板只提供一个空壳子和基础的静态资源引用。这种模式越来越普遍，一些较成熟的框架也驱动了这个模式的发展，比如React、Vue等。但目前大多数web产品为了提高首屏的性能表现，仍然无法脱离对服务端渲染的依赖。所以对模板的构建处理仍然很有必要性。
具体的构建策略根据每个团队的情况有所差异，比如有些团队中模板由后端工程师负责，这种模式下fis的资源映射表机制是非常好的解决方案。
构建可以分为工具层面和平台层面的功能：
工具层面
预编译，包括es6/7语法转译、css预编译器处理、spirit图片生成；
依赖打包；
资源嵌入；
文件压缩；
hash指纹；
代码审查；
模板构建。
平台层面
文件监听，动态编译；
mock server。
一个完整的前端工程体系应该包括：
统一的开发规范；
组件化开发；
构建流程。
开发规范和组件化开发面向的开发阶段，宗旨是提高团队协作能力，提高开发效率并降低维护成本。
构建工具和平台解决了web产品一系列的工程问题，旨在提高web产品的性能表现，提高开发效率。
随着Node.js的流行，对于前端的定义越来越宽泛，在整个web开发体系中。前端工程师的角色越来越重要。本文论述的前端工程体系没有涉及Node.js这一层面，当一个团队步入大前端时代，前端的定义已经不仅仅是前端了，我想Web工程师这个称号更合适一些。
这篇关于前端工程化需要怎么样的准备，性能？安全？监控？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
