前端工程化系列之闲谈“脚手架”（上）

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：胖子会在以后的文章中应该会接着说说脚手架相关的东西。敬请期待！

1. 胖子认为的好的脚手架的特色和功能
2. 业内好的脚手架项目简单介绍
3. 简单介绍如何写一个狭义上服务于初始构建阶段的脚手架

若是您有什么问题和建议，欢迎留言。

若是您以为胖子的文章还过得去，麻烦你轻点右上角的转发朋友圈按钮。胖子这里拜谢了。

转载请注明 码农王小胖