最近呢篩選了不少候選人的簡歷,看到不少關於前端工程化的描述: > "我的一直致力於前端工程化..." > "在公司前端工程化規範,自動化..方面的建設作出了巨大改革..." ... 首先我抱有的但願很大(人才嘛誰能不愛..) 而後呢通過交流探討給我帶來更多的反饋是失望。固然這個領域是`非主流前端領域`。 可是我的以爲仍是頗有趣味並且有必要進行學習的;因此今天筆者簡單的聊一下前端工程化,但願能給你們帶來幫助。
筆者爲了照顧到不一樣時間段融入前端你們庭的讀者,這邊對於前端研發"方式"發展進行一個簡單的回顧;回顧經歷過幾個階段,從而瞭解"工程化"提出的必要性。css
先後端不分離的時代
:那時候所謂的前端擔任的工做更可能是寫頁面。 而後還有就是經過一些技術(ASP,JSP...)將數據進行頁面填充;涉及到這部分技術更偏向於後端,因此前端可能也不併會涉及到這部分工做。(固然也會有扯皮的時候,誰都不肯意幹。。那就是看誰沒話語權咯)先後端半分離時代
: 在一部分工做倆邊扯來扯去的背景下,就研究着如何進行先後端分離,方便更好的實現團隊之間的協做分工。出來不少技術方案 好比在node發展的背景下出現 SSR(server side render) + Node的技術方案;就是服務端將處理好的html模板直接給到前端,前端負責展現。先後端逐步徹底分離
: 在各類技術的推動下慢慢出現了逐步先後端徹底分離的各種架構方案例如RESTful架構;也就是雙方經過協議(http/https/socket)進行調用進行通訊數據傳輸。這樣的話彼此的工做可能就不會有太多的扯皮。可是伴隨還有一些問題,好比API的設計誰來定的問題,前端定義接口的話可能會更理想化(服務端那邊呢有內部的一個大的技術架構服務好比跨集羣這些,在這個背景下可能實現確實會比較困難 [也要幫後端兄弟說句話 哈哈.]);因此我的認爲更多的是雙方合理的討論設計來進行推進。在研發技術方案的日益更新背景下。前端已經從"page開發工程師"逐步變成了"app研發工程師";前端的工做隨着業務的複雜,用戶的體驗提高已經不是一個簡單的工做了,面臨着合做問題,性能問題等等...因此在模式轉變下伴隨着迎來不少問題:html
爲了解決出現的一系列問題就須要選取好的技術架構方案,推動前端工程化的落地。工程化大概包含幾個方面呢?前端
總體規範化node
開發模式組件化webpack
工具化&自動化web
技術優化,性能優化,方案優化...面試
Jquery
一把梭; MVC MVVM的設計模式的優點相信你們都是不言而喻,那麼爲何不選擇進步呢。首先在非工具化(webpack構建生成)的背景下不少研發人員都會遇到一個問題。每次項目部署的時候須要使用者(測試,產品,用戶)去手動清理瀏覽器的緩存;這就是一個很頭疼的問題;每次解釋也挺累的。"靜態資源要清下緩存..."那麼如何從工程方面解決這個問題呢?後端
... <link herf ="XXXX.css"> ... <script src="XXX.js"> ....
如上代碼看起來是沒有什麼問題 爲何程序須要每次去清理瀏覽器緩存呢。緣由是現代瀏覽器爲了性能,開支方面的考慮。解決資源加載問題作出了緩存機制 相同靜態資源會作出本地的緩存。那麼如何解決這個問題呢?很簡單請看下面僞代碼:設計模式
... <link herf ="XXXX?+'new Date()'.css"> ... <script src="XXX?+'new Date()'+.js"> // 不能這樣寫哈 示意 ....
不少細心的同窗在構建工程生產打包的時候已經看到了好比webpack打包它的文件生成通常是"chunk" + hash + .js/css
就是和上面一個解決思路。可是又有問題了 如何決定每一個文件到底需不須要進行緩存的問題來作性能優化呢? 好比一些圖片啊這些就不須要每次從新載入多浪費帶寬資源啊?這個問題留給你們思考一下。或者看一下webpack這些構建工具是如何解決的。前端工程化
前端工程化的必要性以及對於我的的成長是起到了很大的做用;相信你們都有了些許瞭解。
最後筆者認爲你們有必要去學習一下。也能在簡歷上面顯得不那麼單調。不少人就只會寫"精通各類語言,熟悉各類技術..."。哎呀這樣只會讓你的面試官更加的刁難你。每一個語言設計者可能都不敢說本身對於天天在變新的語言每一個細節都熟悉。好比就
JavaScript
來講在日益發展背景下光標準就幾百頁;誰能記得過來。要學會培養本身語言外的工程能力,架構能力。。加油~ 有任何須要交流的隨時留言。