 |
VOOZH | about |
|
VOOZH | about |
記得當時刷筆試題的時候有了解過「前端工程化」，無非就是用自動化工具幫助開發人員完成一些小細節，提高工作效率之類的，不過當時可沒想到可維護性這麼遠
構建項目 -> 模塊化開發 -> 復用 -> 測試 -> 調試 -> 驗證 -> 發布 -> 版本控制，這整個流程的很多環節都可以用自動化工具解放人力，提高項目的可維護性
一.自動化的優缺點js開發中使用自動構建系統的優缺點如下：
自動源碼控制能夠區分清楚用於調試的代碼和將來發布的代碼，開發階段不必估計影響線上產品
靜態代碼分析能自動完成（JSLint、JSHint）
發布前可以進行多種方式的加工（合併文件、壓縮代碼）
自動化測試，能很快發現錯誤
很容易重做一次重複性的工作（比如再次合併文件、壓縮代碼）
有些開發人員用不習慣，因為改動代碼之後要重新構建一次，而不是傳統的保存文件，刷新頁面
部署到線上的產品代碼與開發階段的代碼不同，難以追蹤bug
經驗不足的開發人員可能不會用這種自動構建系統
一般不同的項目需要不同的目錄結構，但下面給出的幾條原則是廣泛適用的：
一個對象對應一個文件
避免多名開發人員修改衝突，文件越少，衝突的概率越大，一個對象對應一個文件能最小化這種風險
把相關文件用文件夾分組
這樣管理代碼更容易根據功能定位對應代碼
分離第三方代碼
最好用CDN引入第三方庫，這樣就不用對第三方代碼進行多餘的源碼控制了
分離構建產物
應該把構建的產物放在另一個文件夾里，不要進行源碼控制，避免無意中反覆構建帶來的時耗
把測試代碼放近點
要把測試代碼放在很容易找到的地方，比如和源碼放在一起，或者test/目錄下與源碼路徑相似的位置
Ant：基於Java的
Buildy：基於NodeJS的
Gmake：UNIX粉喜歡的
Jammit：基於Ruby的
Jasy：基於Pathon的
Rake：基於Ruby的
Sprockets：基於Rack的
JSLint：道格拉斯做的好工具
JSHint：和上面的差不多，但配置選項更多
合併文件，插入版本號什麼的，用第一步用的自動構建工具就能搞定
瘦身和壓縮的區別是瘦身是針對代碼語法的優化，讓源碼更短；而壓縮就是把純文本的源碼文件變成別的更小的文件，壓縮後不能再編輯，除非先解壓
瘦身工具比較多，作者推薦了幾個：
YUI Compressor：Yahoo!的，基於Java，能縮短變量名、去掉空白字符、去掉注釋，還能給CSS瘦身
Closure Complier：Google的，基於Java，能進行深層次優化（去掉不用的方法，把只用一次的方法扔進閉包），比YUI的瘦身效果更好
UglifyJS：基於NodeJS，還能合併var語句
JSDoc：基於java的
YUI Doc：用js寫的
其它：Docco、Dojo Documentation Tools、JoDoc、Natural Docs、NDoc、PDoc
YUI Test Selenium Driver：（作者總是喜歡把Yahoo!的東西排前面，好員工哇）YUI的單元測試框架
Yeti：利用各個瀏覽器進行js測試
PhantomJS：提供WebKit瀏覽器環境，可以配合QUnit和Jasmine
JsTestDriver：Google的單元測試框架，支持自動瀏覽器測試
Jasmine：行為驅動的js測試框架
QUnit：JQuery的單元測試框架
Selenium：功能測試框架，支持瀏覽器測試
應該至少構建3個版本：
開發版
要求是儘量快，否則影響開發人員火力全開
具體任務是：清理文件 -> 初始化構建環境 -> 檢查代碼 -> 合併文件
注意：不要把自動測試環節放進來，因為費時間，開發版構建要求儘量快
集成版
用來排查錯誤，應該每隔一段時間運行一次檢查並報告錯誤
具體任務是：代碼瘦身 -> 測試 -> 文檔生成
注意：文檔生成環節是可選的，因為加進來可能會影響錯誤檢查（錯誤可能來自文檔生成環節）
發布版
要保證0錯誤，穩定可靠的產品
具體任務是：加工文件（添上版本、版權資訊等等）
注意：可以考慮把部署等發布任務加進來，也可以選擇把集成結果直接加工後部署，但要保證集成結果沒問題
CI（Continuous Integration）系統是用來增強對集成版的錯誤排查的，持續集成可以每個一段時間自動運行並檢查代碼報告錯誤，甚至聯繫錯誤相關的具體開發人員
到這裡整本書就結束了，這本書是淘寶UED博客推薦的，還算不錯，也沒有特別晦澀難懂的英文句子。
200頁的書斷斷續續看了近3個星期，不算太慢，當然，在這期間還看完了《JavaScript語言精粹》、《The Book of CSS3》，學了SASS入門，寫了10篇博文