Version：2019.08.28.v1.1
开篇
大家好，我是王小胖，一个集可爱与智慧于一身的胖子。
说到前端工程化，首先想到的是这个小小的概念，“脚手架”。
What？Why？什么是前端脚手架？
相信大家只要接触过前端开发，肯定接触过脚手架（Scaffold）这个概念，或者或多或少使用过它。由于前端脚手架“阅后即焚，用后即弃”的特性，虽然能给前端开发初始阶段带来不小的便利，但是还仿佛如流星闪过一般，不被前端工程化领域所重视，但这里胖子想说，“前端脚手架，它真的，真的，很不错！”
胖子在网上和书籍中查找了一段时间，也没有找到一个对前端脚手架有一个满意的定义。所以今天咱们就直接开始咱们的闲谈，在闲谈的过程中寻找完善脚手架的定义吧。Let's GO！
快速
相信大家但凡接触过知名的和前端有关的，或其他的框架和库的，无论是Angular， VueJS， ReactJS， 或者是Express，NPM等等，都应该使用过这些框架或库提供的脚手架，Angular CLI，Vue CLI， create-react-app， express generator等等。
这些脚手架的最主要目的就是能够让你避开繁琐的项目初始化配置工作，让你快速上手这些框架和库所提供的功能，使你尽快爱上它们。。。想象一下，没有它们提供的脚手架，对于新手来说，你有可能需要花费大半天的时间才能将你的Demo项目跑起来，至少你需要徒手码代码好长时间吧。。。暂且不说能不能坚持到项目启动成功，就是这么长时间，你对于这个库或者框架也已经失去耐心了吧。
所以从我们第一印象来看，胖子给前端脚手架的定义就是
“快速构建项目的初始化文件结构的工具。”
可配置
咱接着来，在大家使用的脚手架工具中，你都会经历在你的初始“init“命令之后，都会紧跟着几个配置的相关问题需要你回答，“项目名字是什么啊？git地址啊？使用的style文件格式？使用的模版技术？有没有女朋友啊？？？！！！”。你会发现脚手架提供给我们很多配置选项供我们灵活的生成初始文件。
所以胖子将脚手架的定义补充了一点。
“快速且可配置的构建项目的初始化文件结构的工具。”
避免重复
OK，继续。大家假想一下没有脚手架的情况，你或你的项目组接到了一个新的前端项目，需要从新构建整个工程，你们技术选型为VueJS 2.X，typescript，SCSS加 PWA等。可能你或团队技术过硬，不到半天，很快利用webpack基础和构建工具整理出了项目开发和构建的文件基本结构，可以开始工作了。但是过几天你们又有一个项目需要同样的技术选型来构建项目，之后呢，你们老板发现你们的项目结构不错，打算推广到整个公司。难道整个公司的项目组都需要重复之前的工作，重新构建，自己写代码？不应该，也是不可能的，太低效了，不能被咱们可爱的程序员接受啊。
这时候你们会想，不如我们构建一套项目文件模版供所有项目组下载吧，这样大家就不会再做重复的工作了，不过很快你发现固定的项目模版的不足了，有的项目组style打算用less。。。那再出一套针对less的文件模版。。。当然不行了，太Low了，不能被咱们可爱的程序员接受啊。这时候你就会想到利用可配置的脚手架为所有项目组提供初始的项目文件结构了，避免了开发人员大量的重复繁琐的工作。
所以咱们再对脚手架的定义做一个补充。
“快速且可配置的，避免重复工作的，构建项目的初始化文件结构的工具。”
规范化
前端技术的百花齐放，百鸟争鸣。技术的自由多样性同样带来了技术栈的难统一的问题，公司跨项目跨部门间，技术如何规范化是一个很大的挑战。怎么能避免行政死命令来让这些桀骜不驯的可爱的程序员们统一技术栈，实现技术的规范化呢？
胖子觉得我们可以从工程化的角度下手，充分利用脚手架来“弱强制化”地推行技术的规范化和统一化。
胖子这里说的不是限制可爱的程序员们只能选用固定的某一门技术，强制不能选择其他技术。而是在一定的过滤后的范围内灵活技术选型。
胖子认为“无规矩无以成方圆”，小的创业公司勉强还好，人员少，灵活性带来的高效和利益实际上短平快地优于规范性带来的稳定和安全的利益。但是对于成规模的公司，具备大量开发人员的公司，公司的一线开发部门，在技术选型和技术使用上就需要牺牲一些灵活性，工程师应该定位在适当范围内的允许适当的灵活性，这样可以为公司开发部门带来不少的益处。
- 降低学习和沟通成本。不同的开发部门，不同的开发人员，可以在一定范围内的技术上沟通，交流（未规范前可能是20个技术，规范后可能只有5个技术），讨论具体的细节的问题了，不用再额外花时间来预学习一些之前没有接触或熟悉的技术了。
- 降低项目开发和维护成本，技术范围的领域的缩小，带来的，一是在各个项目中技术问题的排查解决方案就可以重用，例如B组遇到的问题可能A组之前就有了解决方案了，或者A组直接在脚手架中下载的公共模块上就把问题修复了，B组根本不会再发生同样的问题。二是各个项目部门创建的通用业务模块有可能经过加工后被各个部门重用，方便构建公司级别的统一的物料库。
- 降低新技术选型风险，规范化到脚手架中可用的技术理论上都是经过基础部门过滤过的，或是经过公司权威专家认证过的，所以可以规避很多盲目选型新技术带来的风险。当然这对基础部门也同样提出了更高的选型和审核要求，怎么把控这个粒度？怎么实现规范和灵活性的统一？怎么快速响应需求？都是需要认真思考的问题。
这样，我们再扩展一下我们对脚手架的定义
“快速且可配置化的，避免重复工作，统一技术规范化的构建项目初始化文件结构的工具。”
When？Where？脚手架的生命周期？
其实大家如果查询或了解对于脚手架的介绍和讲解的文章，或者看我们在之前形成的定义，都会看到一个词 “初始”。这也给了脚手架定下了一个“刻板印象”，“阅后即焚，用后即弃”。其实胖子觉得这对脚手架的看法是落后的，狭隘的。
胖子认为脚手架不应该只是服务于创建项目的初始文件，理论上它应该可以在整个项目周期上提供支持和服务。虽然很多工作的支持都是在初始构建的阶段完成或定义的，但是我们应该放开我们的思想禁锢，扩展脚手架对整个工程化的贡献。
大家可以回想一下现实的中建筑的脚手架不也是一直对整个建筑周期起到保驾护航的作用嘛，为什么前端的脚手架不能呢？
另外，现在市场上活跃的，人气高的脚手架产品，我们已经能看到有的已经将功能扩展到整个项目生命周期的很多步了，不只是局限于初始构建这一步。脚手架完全可以慢慢成为前端整个领域的整合型工具。
下面列举胖子了解的脚手架在整个项目周期内可以提供哪些支持和服务：
1.构建阶段
不用多说了，前面寻求定义的过程已经说的很清楚了。。。（其实是胖子真的写不动了。。。还不想Ctrl+C，Ctrl+V。。。）
2.开发阶段
本地代码热更新支持，提高开发效率。
本地mock service服务，实现前后端并行开发，降低项目交付风险。
自动生成新模块代码，省去繁琐工作。
代码提交的预检查，提高代码的稳定性。
3.测试阶段
mock测试数据。
执行测试脚本。
生成统一的测试报告/并上传统一服务器做质量监控。
4.部署阶段
部署前预检查。在项目部署之前，自动执行一些必要检查来保证稳定性和安全性。
自动部署，通常大厂或正式成规模的大公司，部署理论上会有独立的部门来维护，或者会有一套成熟的pipeline来供开发人员使用。但是对于小公司和非正式产品的demo项目，我们完全可以将部署的工作放到脚手架上自动化处理。
5.运维阶段
奇怪!? 脚手架还能服务于运维!？其实大家如果像胖子一样放下对脚手架的刻板印象，而是把它定义成服务于前端整个项目周期的“工具”，脚手架为什么不能为运维阶段做点事呢？比如数据统计和产品稳定性和性能监控。
结语
其实在上面的5个阶段里，胖子还想加入一个阶段，就是“无限制阶段”，意思就是我们不要局限于上面的五个阶段，任何时候，任何地点我们遇到的问题，如果能通过加强脚手架来合理解决，我们都可以考虑进去。
其实，如果我们真正的把脚手架当成一个为前端整个项目周期，或整个项目领域服务的工具，还有很多事和功能实现可以放到脚手架里面。
你可能会有疑问，那照胖子你这么说，那岂不是脚手架就由一个简单编辑的单一职能的便捷工具，变成了一个面面俱到，无微不至的复杂繁琐的大怪物了吗！？这样真的好吗！？
这里胖子想说明一点，我们作为可爱的程序员，任何一个工具或工具里功能的产生，我们都是需要思考一个问题的。这么做究竟是不是能解决我们实际的问题？能提高我们的效率？能节省我们的成本？这些才是最重要的。我们不应该为了全而全，为了完美而完美。我们可爱的程序员生下来就是为了解决实际问题的。所以为什么脚手架单单只能是一个工具呢？不能是工具集，工具库呢？现实中建筑的脚手架也是很多坚固的零部件组合而成的啊，所以我们不要被固定的思维局限和阻挡住我们的创新和思考。
最后，胖子给出自己对前端脚手架的定义。
“前端脚手架，狭义上讲，是快速且可配置化的，避免重复工作，统一技术规范化的构建项目初始化文件结构的工具。广义上讲，也是服务于整个前端项目周期，提供完善技术支持，解决方案的工具集合。”
PS：胖子会在之后的文章中应该会接着说说脚手架相关的东西。敬请期待！
- 胖子认为的好的脚手架的特点和功能
- 业内好的脚手架项目简单介绍
- 简单介绍如何写一个狭义上服务于初始构建阶段的脚手架
如果您有什么问题和建议，欢迎留言。
如果您觉得胖子的文章还过得去，麻烦你轻点右上角的转发朋友圈按钮。胖子这里拜谢了。
转载请注明 码农王小胖
