最近在进行反思，同时也有了一些不成熟的想法，顺便结合一下个人经历写一点感悟吧

前端工程化要解决的问题是啥

万事万物之理皆有共同之处，前端工程师面对的最大问题是啥？其实是使用者的不可确定性，万能的jquery其实就是因为抹平了当时浏览器的差异点才成为一个最棒的第三方工具的

但是工程化就是抹平差异？

工程化的最根本目的在于，让开发者更加专注，减少心智成本

心智成本和最古老的工程化

在目前一堆堆工具出现之前，前端就有过最原始的工程化了，也就是按照目录和功能的分类，通过目录结构就可以轻松的明白当前在编辑和控制的是哪个部分

但是分目录的情况下又会增加一些额外成本，公共的header和footer，公共依赖包的引入，如果要统一修改就得进行遍历 于是pug ejs 等等也纷纷开始出现 当然 每次都需要用命令来编译回html才能正确使用

心智成本仅仅如此么？

其实用过现代开发框架的人可以发现，除了框架，还有一堆webpack啊 gulp啊 eslint啊babel啊 pritter这种工具的引入，这些工具覆盖了从编译到转码 从格式规范到自动修复的方方面面，这也牵涉到了心智成本的更高一级了，标准化，规范化，自动化

一切像一个人写的 降低理解成本

是的 工程化一部分的目的在于规范化，降低准入门槛，能看懂一块就自然能看懂另一块，用同样的标准能够通行无阻

一切都帮你自动做好了 降低时间成本

人皆有不同，每个人的代码习惯总是或多或少有点差异，有好的也有坏的，同时人也是懒的，重复低效的事情做多了一样会厌烦 之前有提到jade ejs这类工具，其实是需要运行命令才能转为html的，但是工程化后，这都成了工程化的一环 只要监听到变化，就会自动编译成对应格式，代码习惯不一样？工程化之后自有工具自动格式化 监听发布分支之后自动发布测试

万事皆虚，万事皆允 降低适配成本

浏览器也是飞速在发展，js标准也是在不停迭代更新，但我们能随意使用这些新标准么？答案是，可以但也不可以，一方面工程化目标就在于你可以使用最新的技术而工程化可以将它转为兼容代码，但是另一方面，如果不清楚目标群体贸然上一些无法转译需要polyfill或者单浏览器支持的特性的时候 工程化就无法解决了

如何做工程化？

2020年了，其实现代浏览器框架/第三方框架在这方面已经很成熟了选择你的技术栈对应的cli工具就好了，还有gitlab ci github actions这些

老工程化的更新和改造

未完待续

微服务化

未完待续