前端工程化的我的思考-續

(題圖：from  unsplash)

有朋友問最近看的哪兩本關於前端的書籍——《前端架構設計》+《前端工程化：體系設計與實踐》，一本重道，一本重術，道與術結合更具指導意義。但願瞭解前端的朋友推薦看一下。

接着上篇未完的話題，《前端工程化的我的思考》，前端工程化很龐大，涉及的點也比較多，筆者也只是想到那裏就寫到那裏，要討論的朋友可在文末留言討論。

規範檢查

既然走工程化路線，代碼規範剛首當其衝，但每一個人的編碼習慣各異，只能靠團隊規範來大方向上求同存異，Java的規範是出了名的，規範檢查插件、組件也是種類繁多。前端天然也會有對應的組件來解決前端代碼的規範問題，如jslint，eslint，stylelint等，結合svn/git或構建編譯工具來確保代碼的規範性，應該也有詳細的規範文檔來約定。我比較喜歡用的工具組合是SonarQube+Jenkins，利用Jenkins進行持續集成構建的同時，進行規範檢查，將結果輸出到SonarQube中在頁面上展示出來，固然這屬於一種後置的檢查，在本機開發構建時，就能夠集成到構建工做包或IDE插件中進行檢查。

前端測試

很多項目針對後端有嚴格的單元測試經過率、測試代碼覆蓋率、代碼註釋率等，但對前端要求比較少，這也從側面說明前端測試很差作，特別是前端的自動化測試工做。若是是先後端兼顧的開發，你基本是不會想到給前端代碼寫單元測試的，由於後端的邏輯性更強，測試方便。若是你是專職作前端開發的，你應該想一想有沒有給你的前端代碼作單元測試？咱們老是習慣於在JS代碼中加入alert或console，刷新頁面看看到底結果如何，一處又一處，一遍又一遍，直到隨處可見的alert/console淹沒在正常代碼處理中。

很差作不表明不能作，具體到不一樣的技術棧，想必也有對應的測試工具來輔助你們進行測試，如Vue體系、React體系等等，算是有比較成熟的生態。也有獨立的優秀三方測試框架，如Mocha、Karma等，結合斷言庫如char.js（沒有寫斷言驗證的單元測試都是耍流氓），集成到CI工具中，完成一個持續性的流程。

工做流

工程化作的比較好的當屬Java，而前端前些年彷佛不存在這個概念。雖然一部分人也在努力這麼作，直到NodeJS的出現，纔有了質的飛越。不但提高了前端在軟件工程中的地位，也爲一大批工具的出現奠基了基礎。獨立構建、獨立部署、任務處理（編譯、壓縮、混淆、合併、解決依賴、文件hash）等工具的出現，將一個完整的工做流程串聯起來，再結合CI/CD工具，可謂發揮出極大的威力，解放人力，提高生產力。特別是Jenkins新版本中Pipeline功能的提出，使工做流程配置更加流暢。

附：《前端架構設計》思惟腦圖總結圖

---

寫到這裏，算是這段思考的一個完結，文中提到的點都比較數粗糙，後續仍是要深刻進去，畢竟覺知此事要躬行。