写作心路历程
历经半年的时间，我终于完成了《透视前端工程化》专栏的写作。从零开始完成一个脚手架的搭建，对于我来讲可能算不上一件困难的事，但是把这个实现过程总结成文字，去教会更多的人，对我来说却是一个极大的挑战。这也再次证明了，当学生比当老师容易，当球员比当教练容易。
大纲的编写相当于要提前将专栏的内容规划好。从确定大纲到写作具体章节，时间间隔可能会很长，所以难点在于保证未来章节内容的写作思路不会偏离专栏大纲的设计。为了使写作过程更加顺畅连贯，我对大纲反反复复调整过不下四次，用了近一周的时间，才最终确认。
长时间的写作对意志力是一个考验。按照写作安排，每周至少需要完成一篇文章的写作。如果是全职写作的话，这倒不是什么问题，但是由于平时工作比较紧张，只能在业余时间去写。每周都有完稿的压力，半年以来一直像一块石头压在胸口，好多次都差点放弃……如果不是编辑同学每每在关键时刻出现鼓(cūi)励(cù)我，多半这个专栏就无缘面世了。在此，我向负责本专栏的编辑同学致以诚挚的感谢！
回顾和总结
前端工程化是一个系统的概念，从框架工具到流程规范，涉及研发过程的方方面面。所以我对前端工程化的介绍选择从脚手架入手，希望通过脚手架工具的搭建，系统介绍前端工程化所涉及的流程规范和框架工具。这门专栏主要是讲了以下两部分内容。
首先，如何将繁琐的配置工作抽象成项目模板。
当前的前端开发依赖于大量的前置配置工作，前端工程师因此也被戏称为“前端配置工程师”。如果每次开发一个项目都要将配置工作重复来一遍，估计很多人都要逃离前端这个职业了。
显然聪明的前端小伙伴们是不答应的。
于是，专栏中最重要的部分就是将最常用的功能和配置做成模板。下次开发新项目的时候，将模板复制过来，改改就能使用了。项目模板实现的功能主要包括本地开发环境、mock server、测试、构建、部署等核心功能。每个功能的实现都是建立在大量的开源工具基础之上的。比如 Webpack、ESlint、NightWatch、Mocha。这恰恰体现了工程化中的分而治之思想。
其次，通过命令行工具自动生成项目框架。
项目模板设计好之后，开发者还是需要先做一些配置（如，将模板拷贝过来、修改一下项目名和部署的目录）然后再开始开发。理论上说，任何重复性的工作都可以由工具来处理。这也是我们设计命令行工具的主要目的。
具体到专栏中，就是通过命令行从远程拉取项目模板。用户在命令行的交互界面中输入项目的初始化信息，命令行根据用户指定的信息对项目模板进行渲染，最终自动帮我们创建好项目框架。从工具层面来讲，我们首先使用 commander 来创建命令行，用 download-git-repo 下载远程仓库，然后使用 inquirer 与用户进行交互，收集项目初始化信息，最后使用 Metalsmith 渲染模板完成项目创建。
关于前端工程化的一些感悟
相信通过对专栏的学习，各位前端小伙伴都可以对如何实现一个脚手架有一个清晰的思路，对前端工程化的概念和内涵也都形成一定的认识。
这些年，通过亲历的众多项目（成功的经验也好，失败的教训也罢），我产生了一些感悟，在此分享出来，希望能帮助大家少走弯路。
适合自己的才是最好的
前端小伙伴们都是出了名的爱（bèi pò）学习，看到别人家有高大上的技术或者流程工具，自己的团队也一定得赶紧看齐。这种想法并不理性，因为每个团队的规模和所处的阶段不尽相同，我们不应该完全照搬别人的流程和工具。正确的做法是学习别人的思想，然后结合自己的实际情况，打造适合自己的技术体系。
比如几个人的小团队，是不需要那么完善的规范和工具的，过于完善的工具和流程规范在这个阶段反而可能降低整体研发效率。简单实用的小工具反而更高效。
当团队规模在二十人以上的时候，效率和协作的瓶颈就会开始显现，如果没有一定的规范、流程和工具的约束，整体的产出很可能远远小于个体之和。这个时候需要制定相关的流程规范、统一框架工具来提升整体的效率。
开放协作，站在巨人的肩膀上才能取得更大的成就
公司规模比较大的时候，各个业务部门之间就会形成一个个的小技术圈子，难免会出现各种平台工具的重复建设，造成资源浪费。之所以出现这种情况，有两方面的原因。第一，公司非常大，各个团队之间的关联性很小，缺乏有效的沟通交流机制，所以各个部门只能各自规划。第二，为了满足自己想开发平台工具的私心，明知公司有现成可用的平台工具，还要重复造轮子。
对于重复造轮子的问题，我不想多说，确实在各个公司都有存在。我想说的是，作为技术人应该始终保持开放的心态，在研发任何平台工具之前，首先要想，当前是否已经存在类似的工具可以解决自己的问题？如果有的话，那么请直接拿来使用。如果有但不能满足需求的话，可以在已有工具的基础上进行二次开发，这远比重新开发一个工具要高效得多。
我们的技术社区之所以能繁荣发展到今天的地步，就是因为开发者们保持了开放协作的心态，充分吸收和利用了已有的成果。
