最近流行的一句话：
“你们别学了，跟不上了！”
随着前端开发的不断演变，开发模式的不断改变，企业对前端的要求也越来越高，再也不是会HTML、CSS，写写简单的JS动效的阶段了，而且只会做Web端很多时候也已经不能满足企业的要求了。工作中你永远不知道下一个项目会做什么，Web系统（前端展示，后台管理）、小程序、公众号、APP（双端）、H5推广页都有可能。
不管如何吐槽、抱怨，当业务需求摆在面前的时候，还是得打开编辑器，写下那句“Hello World!"来开始每次的工作。但是作为一个有追求的前端工程师，每天要打开GitHub或者掘金，学点新知识。于是就看到了这样的画面：
Word 天！老子真的学不动了！
从Angular、React、Vue三大框架，到ES标准、CSS布局、浏览器机制，再到模块化、浏览器兼容、设计模式，还有不断新出的PWA、Flutter、WebAssembly等等技术
前端领域的技术层出不穷，很难不让人产生焦虑感。
而且据某非著名统计显示，超过98%的前端工程师电脑里都保存着一份前端知识体系图（或者叫前端技能大全图，或者叫前端必备知识点什么的），往往就像下面这样子：
<figcaption> 前端知识体系图.jpg </figcaption> 不过你真的认真看完掌握这些知识了么？
工作中提升是个伪命题？
当面临面试时，不管是从头开始学，还是复习，我们都应该按照一条主线来进行。有些是当下必须会的，用于日常工作，属于重要且紧急。有些是拓展，进阶提升自身竞争力的，属于重要但不紧急，可以排后面。但是不是所有的技术都是靠时间累积可以实现提升的，也不是所有的技术都像反复流水线一样的重复就可以提升。一旦陷入了代码搬砖模式，你不仅劳心费神，工作效率低下，而且无法满足公司的产品需求。
我们总听到的一个说法，是前端三大框架跟编程语言一样都有自己的设计哲学。这表明框架的背后是一个架构、一个生态。每个框架背后牵涉着开发思维、生态系统、配套工具、最佳实践、性能调优。要精通和熟练一个框架需要付出的成本是很高。很少有人能精通这三个框架的，更别说是一个团队。很多业务为了快速开发，就导致前端技术栈非常的混乱，Vue、React和AngularJS三大框架都有，而且风格相差也很大。
对于前端开发人员来说，很多人Vue会一点，Angular也听说过一点，React也知道一些。面试时，被问到生命周期、组件通信、双向绑定等等，都能很快讲出概念和原理。
面试官也觉得你基础不错，决定多聊一些平常所做的业务，毕竟每天都在做的事情是更加擅长的。
于是就出现了接下来的场景：
问：“之前的项目都有哪些规范？”
答：“编码规范 ... ... 用到ESLint... ... 还有类型检查，会涉及用到TS... ...”
问：“其他规范呢？”
答：“接口文档... ... 需求文档... ...”
问：“那兼容性有统一规范么？测试规范呢？还有异常和监控有规范化么？”
答：”小公司/新项目，这些都还没做过“
问：”那说说基础业务功能组件如何拆分的吧？“
答：”React常用的组件... “
问：”那考虑过通用和扩展么？包括业务复杂之后如何处理组件间数据？“
答：“... ... 做得比较少 ... ...”
问：“业务迭代后如果有冲突，怎么解决？”
答：“开发新业务比较多，迭代都是加新功能……”
……
这是日常面试中，经常会出现的场景，很多人都觉得是面试官问的问题太宽泛，其实往往越是这样与业务相关的内容更能看出一个开发工程师的工程能力。而往往很多人能做到基础知识（就是俗称的硬技能）对答如流，实践应用（很多人叫它软技术）就讲不了太多内容。
当然后面还有问到更多的复杂技术应用，比如多人协作的功能设计，比如基础功能和针对性的性能优化。而面试官更想了解的，更深入的如体系化系统建设、数据运营和建模，则永远也问不到了。
前端工程化到底是什么？
软件工程中有一个软件设计阶段，通俗的讲就是在开工之前将能确定的确定下来，把该考虑的考虑了。这相比在开发阶段发现问题，解决的成本要低很多。相比后端开发，对于前端来说**「软件设计」*很少被提及，也有可能是一直以来前端的工作都比较「简单」*，所以比较粗放随意，一般给了原型和接口文档就直接开干了。
但是随着前端开发者的工作越来越复杂，或者项目/团队的规模变大，层出不穷的前端框架都在顺应这个发展趋势，向着企业级、工程化的模式和方向进行发展。
对于很多前端开发来说，最难的其实是企业级思维模式的转换，从单一需求完成到通盘考虑整体项目的技术方案的转换，而且需要不停的迭代和演进技术架构。
从技术设计，到基础业务功能编写，再到复杂业务数据流管理，可插拔组件的设计，以及性能优化，最后到体系化建设，往往是一个企业级项目应有的流程。
就像下面这样：
详细的课程设计，可以添加我的微信，一起交流沟通。
京公网安备 11010502036488号