最近流行的一句話：
“你們別學了，跟不上了！”
隨着前端開發的不斷演變，開發模式的不斷改變，企業對前端的要求也越來越高，再也不是會HTML、CSS，寫寫簡單的JS動效的階段了，而且只會做Web端很多時候也已經不能滿足企業的要求了。工作中你永遠不知道下一個項目會做什麼，Web系統（前端展示，後臺管理）、小程序、公衆號、APP（雙端）、H5推廣頁都有可能。
不管如何吐槽、抱怨，當業務需求擺在面前的時候，還是得打開編輯器，寫下那句“Hello World!"來開始每次的工作。但是作爲一個有追求的前端工程師，每天要打開GitHub或者掘金，學點新知識。於是就看到了這樣的畫面：
Word 天！老子真的學不動了！
從Angular、React、Vue三大框架，到ES標準、CSS佈局、瀏覽器機制，再到模塊化、瀏覽器兼容、設計模式，還有不斷新出的PWA、Flutter、WebAssembly等等技術
前端領域的技術層出不窮，很難不讓人產生焦慮感。
而且據某非著名統計顯示，超過98%的前端工程師電腦裏都保存着一份前端知識體系圖（或者叫前端技能大全圖，或者叫前端必備知識點什麼的），往往就像下面這樣子：
不過你真的認真看完掌握這些知識了麼？
工作中提升是個僞命題？
當面臨面試時，不管是從頭開始學，還是複習，我們都應該按照一條主線來進行。有些是當下必須會的，用於日常工作，屬於重要且緊急。有些是拓展，進階提升自身競爭力的，屬於重要但不緊急，可以排後面。但是不是所有的技術都是靠時間累積可以實現提升的，也不是所有的技術都像反覆流水線一樣的重複就可以提升。一旦陷入了代碼搬磚模式，你不僅勞心費神，工作效率低下，而且無法滿足公司的產品需求。
我們總聽到的一個說法，是前端三大框架跟編程語言一樣都有自己的設計哲學。這表明框架的背後是一個架構、一個生態。每個框架背後牽涉着開發思維、生態系統、配套工具、最佳實踐、性能調優。要精通和熟練一個框架需要付出的成本是很高。很少有人能精通這三個框架的，更別說是一個團隊。很多業務爲了快速開發，就導致前端技術棧非常的混亂，Vue、React和AngularJS三大框架都有，而且風格相差也很大。
對於前端開發人員來說，很多人Vue會一點，Angular也聽說過一點，React也知道一些。面試時，被問到生命週期、組件通信、雙向綁定等等，都能很快講出概念和原理。
面試官也覺得你基礎不錯，決定多聊一些平常所做的業務，畢竟每天都在做的事情是更加擅長的。
於是就出現了接下來的場景：
問：“之前的項目都有哪些規範？”
答：“編碼規範 ... ... 用到ESLint... ... 還有類型檢查，會涉及用到TS... ...”
問：“其他規範呢？”
答：“接口文檔... ... 需求文檔... ...”
問：“那兼容性有統一規範麼？測試規範呢？還有異常和監控有規範化麼？”
答：”小公司/新項目，這些都還沒做過“
問：”那說說基礎業務功能組件如何拆分的吧？“
答：”React常用的組件... “
問：”那考慮過通用和擴展麼？包括業務複雜之後如何處理組件間數據？“
答：“... ... 做得比較少 ... ...”
問：“業務迭代後如果有衝突，怎麼解決？”
答：“開發新業務比較多，迭代都是加新功能……”
……
這是日常面試中，經常會出現的場景，很多人都覺得是面試官問的問題太寬泛，其實往往越是這樣與業務相關的內容更能看出一個開發工程師的工程能力。而往往很多人能做到基礎知識（就是俗稱的硬技能）對答如流，實踐應用（很多人叫它軟技術）就講不了太多內容。
當然後面還有問到更多的複雜技術應用，比如多人協作的功能設計，比如基礎功能和針對性的性能優化。而面試官更想了解的，更深入的如體系化系統建設、數據運營和建模，則永遠也問不到了。
前端工程化到底是什麼？
軟件工程中有一個軟件設計階段，通俗的講就是在開工之前將能確定的確定下來，把該考慮的考慮了。這相比在開發階段發現問題，解決的成本要低很多。相比後端開發，對於前端來說**「軟件設計」*很少被提及，也有可能是一直以來前端的工作都比較「簡單」*，所以比較粗放隨意，一般給了原型和接口文檔就直接開幹了。
但是隨着前端開發者的工作越來越複雜，或者項目/團隊的規模變大，層出不窮的前端框架都在順應這個發展趨勢，向着企業級、工程化的模式和方向進行發展。
對於很多前端開發來說，最難的其實是企業級思維模式的轉換，從單一需求完成到通盤考慮整體項目的技術方案的轉換，而且需要不停的迭代和演進技術架構。
從技術設計，到基礎業務功能編寫，再到複雜業務數據流管理，可插拔組件的設計，以及性能優化，最後到體系化建設，往往是一個企業級項目應有的流程。
就像下面這樣：
詳細的課程設計，可以添加我的微信，一起交流溝通。
