（本文说的前端主要针对Web前端）
随着前端应用的不断复杂化，用户体验的要求复杂化，前端已经从简单的UI界面的编写，进化为了复杂工程体系。

什么是零配置理念？

随着前端工程的不断复杂化，前端工程师需要了解的周边知识体系也变的越来越庞大。我们会使用Webpack，做各种配置，引入各种插件，编写各种脚本去完成编译、部署等等的工作，很多时候每个项目都需要做各种微调。这就导致了‘配置环境’这种工作本身会带来各种消耗。
随着前端社区的不断发展，发现可以把上述的各种工作通过封装，形成一个独立的框架或者库，通过一些约定使得不再需要任何配置，只要引入库或者框架，遵守约定即可，这可以大大的减低前端工程师们的重复工作，不在需要摆弄各种插件去适配使用css、sass还是css-in-js方案，不需要去各种配置支持typescript还是ES6，还是各种bable编译，这些工作框架或者库层面完全做好了，拿来即用，这就是零配置的理念。
在开源社区中可以看到大量的框架、库都往这个方向走，看React相关的：

  • create-react-app: 基于webpack的react的脚手架库，对于本地调试、hot-reload、编译、各类webpack插件支持、自带lint、typescript支持、ServiceWorker等等，主要支持的是SPA的形式，没有SSR的支持，拿来即用，非常方便。
  • parcel：致力于替代webpack的工具，0配置，通过社区的努力把该有的配置直接内置在库里面，什么sass支持、typescript支持等等，直接帮使用者配置好了。拿来即用。
  • nextjs：一个完整工具链的React开发框架，其主要卖点是SSR，现在也支持Export静态文件，方便即用，
  • umi：蚂蚁开源的React开发框架，通过一整套的工程工具（cli），组件库集成，数据管理集成，直接拿来写业务就好了。
  • gatsby：原来是基于react静态页面生成器的定位，但是随着不断的进化，从数据获取到编译部署等一整套的解决方案，不仅仅是静态页面的生成。

这些框架、库会有一些差异，对于一些功能会有偏重点，但都是通过一套工程工具（cli命令）、一套约定（比如pages放页面组件，命名规范）来实现零配置的理念。而这大大提升了业务开发的效率，通常使用默认的配置就可以满足绝大多数的需求，当然它们也支持一些个性化的配置。
我觉得在这个理念之下，慢慢的这些应用框架和库，有的会慢慢的趋同，都能支持ssr，都可以支持静态导出等等功能，因为本质上诉求的相似的，不管用的基本框架是什么（react，Vue，angular），工程的诉求都是相似的。
零配置的理念本质是通过工程手段，标准化开发模式、降低工程化本身的成本，提高开发结果的质量。简单来说就是：降低成本，提高质量。
**

指导意义

在项目中，可能使用了社区的框架、库，也可能没有使用而是自己搭建了一套，可以通过上述的理念，社区的实践中，在自己搭建的过程中带来了极大的指导意义。

标准化、流程化、自动化

一个前端项目，真正的思考编码只是其中一小部分，在没有非常完善的工具的时候，大多数的时间是在调试环境、写样板代码、没有类型支持的话一直在寻觅的过程等等，而这些没有思考的步骤，都是需要标准化、流程化，最后都自动化。而这个是非常重要的指导意义。
在工程实践中，以下的步骤都是可以标准流程自动化的：

  • 基本的lint，format，代码规范，提交规范（commit hook）
  • 编译、部署、自动化测试
  • 自动样板代码生成

有了这些工程的工具的保驾护航，一些低级的认为错误就可以极大的避免，而工程师本身可以把思考更多的用在业务、技术本身。
总结一下：能标准化的标准化（lint，代码规范，格式规范，命名规范等），能流程化的流程化（编译、部署等），最后把标准和流程自动化，通过一套脚本或者cli或者IDE集成或者可视化的页面。最后的目的是把工程师从这些重复劳动中解放，专注于业务、技术实现。

确定性与不确定性

另一个重要的指导意义是，这些所有的工作，最终都是减少了前端开发不确定性，减少人为出错的可能性，增加了全流程的确定性，没有比机器自动完成更加确定的了，虽然绝对的确定性是不存在，世界本质是不确定的。
记得这样一个故事，谷歌传奇工程师 Jeff Dean 和 Sanjay Ghemawat，早起谷歌快速发展时期，遇到过各种奇怪的问题，比如有的bit突然从0变成了1，而其原因是超新星爆炸导致的宇宙射线粒子有极小的概率撞击到计算机芯片中，是的0和1的翻转。
作为工程师，可能会遇到各种不确定的事，而工程化就是把发生的问题自动处理，减少重复劳动，降低不确定性。

质量

有了这一系列的努力、工具，那么从一个大的维度上来说，给与每个开发人员相当于画了一个边界，这保证的系统质量的底线被拉高了。虽然产品系统的质量最终是在于工程师写的每一行代码，有了这些系统性的保障，工程能够出错的范围也被大大缩小了。
有了这些的保驾护航，工程质量底线也会被提高到一个比较高的起点。

不可忽视的问题

隐藏了实现细节，也就带来了隐患，如果出了任何问题，有时候很难排查，如果过度依赖外部的整套工具，如果框架工具本身产生的重大问题，那么会被动。通常需要有这些考虑：

  • 自研整套工具：在资源许可的情况下，可以重复造轮子，更好的把控性也是很重要的。但对于很多小团队其实是得不偿失的，除了可能提高自身技术能力外，很多时候并不如社区工具来的成熟
  • 了解使用框架、工具的细节：不能仅仅停留在使用的阶段，在拿来用的过程中，要调研，要试着却理清整个实现细节，为未来出现问题，而不至于束手无策。其他注意：
    • 选择比较活跃的，防止没人维护
    • 选择和现有技术栈相匹配的（SSR？，SPA？，Reac？，Vue?，JS?，TS?等等因素）

结语

现实前端需求的复杂化，使得前端工程体系的出现和复杂化，工程师的思维从编码到前端体系的转变，需要工程思维。
上手零配置，配置是可选。把复杂的工程配置都隐藏起来，减少重复劳动，最终达到的就是：降低成本、提高质量的目的。