版權聲明:轉載時請以超連接形式標明文章原始出處和做者信息及本聲明
http://www.blogbus.com/monw3c-logs/221368642.html
javascript
這個題目有點大, 由於對於開發富應用和SPA(單頁面應用, Single Page Application), 一個前端工程師須要掌握太多太多知識和工具了. 這裏只說我本身最近半年在摸索和研究前端富應用和SPA相關技術的過程當中的一些經驗和總結.css
一個好的IDE可讓你敲鍵盤的次數大大減小, 我我的推薦使用Sublime Text, 速遞快, 功能強大, 可擴充, 這也是我目前正在使用的IDE.html
呃, 難道還有別的選擇? 開發前端應用不都是用Javascript麼? 對的, 由於如今有了CoffeeScript. 相比於Javascript的類C++/Java靜態語言語法, CoffeeScript提供了更貼近天然語言的動態語言語法, 更少的代碼, 更少的語法漏洞, 更好的代碼可讀性.前端
Javascript 程序很難調試, 特別是當代碼行數超過必定量級以後. 爲了讓程序邏輯更有條例, 與服務器端的web框架相似, 前端也有不少Javascript庫或者框架提供了MVC或類MVC架構. 按照MVC架構進行設計, 能夠很清晰地將Module(數據模塊), View(頁面展現), Controller(用戶行爲響應控制)進行分離. 對於小型web應用來講, 這可能可有可無, 甚至MVC帶來的弊端會掩蓋它的優勢, 但對於一個超過上千行的web應用來講, 一個清晰的程序架構能夠極大地減小模塊間的耦合性.html5
你們能夠仔細看一下Top 10 Javascript MVC框架的對比. 我我的感受, Backbone的代碼更緊湊一些, 開發社區也比較活躍.java
Javascript 語言自身不提供代碼的加載管理, 當JavaScript代碼分紅多個模塊, 處於不一樣文件中時, 如何管理模塊之間的依賴關係以及文件的加載順序, 就會變成一個很是棘手的事情. 而且JavaScript自身不提供名字空間的管理, 不一樣模塊, 不一樣的JavaScript庫之間的都有可能出現命名衝突.jquery
AMD(Asynchronous Module Definition)是用來規範如何定義模塊及其依賴項, 以及如何異步加載模塊. 你們能夠參考Addy Osmani的博文Writing Modular JavaScript With AMD, CommonJS & ES Harmony來了解具體的細節.git
目前前端使用最普遍的前端AMD庫應當是RequireJS.固然還有淘寶玉伯的Seajs.程序員
Javascript代碼的書寫格式很是自由, 甚至帶着錯都能運行下去, 這也是爲何JavaScript代碼很難調試的緣由之一.github
進行代碼質量的靜態檢查能夠極大減小因爲語法漏洞或者拼寫疏忽帶來的這些額外錯誤, 推薦使用jshint. 若是使用CoffeeScript, 這步能夠省略了, CoffeeScript編譯後的代碼都能經過jshint的檢測.
單元測試是一個很是大的話題, 我沒有辦法用簡短的一段話或者一篇文章將單元測試涉及到的方法和工具都介紹清楚.
技術大牛們都不肯意作單元測試, 固然, 不多有軟件工程師願意認可本身不是技術大牛:). 由於人員, 時間或者其餘各類因素, 不少軟件工程師們都願意首先捨棄單元測試, 去保證功能的實現.
這 裏我不想挑起爭論, 但個人經驗的確是, 從我的角度上看, 單元測試能很大加深程序員對代碼的理解程度, 加速我的能力的提高; 從項目角度上看, 技術經理須要權衡當前的開發, 迴歸測試和後繼的代碼維護成本之間的平衡, 而後決定是否實施單元測試, 以及多少程度的單元測試, 這是技術經理的職責.
在前端web應用中比較經常使用的單元測試框架包括:
Mock庫能夠採用SinonJS. 若是願意, 還能夠採用Should, Expect, Chai等Assertion庫.
另外, 若是但願在持續集成中加入對測試的支持, 還須要加入Non-GUI瀏覽器的支持, 目前採用比較多的方案是:
因爲Zombie當前的版本還不能支持RequireJS, 所以我更傾向於使用PhantomJS.
爲了提升web應用的加載速度, 必須對Javascript文件, CSS文件進行Minification和Concatenation, 根據經驗, 優化後的代碼加載速度比優化前的要提升數倍.
經常使用的工具包括:
大部分開源的JavaScript構建工具都集成了對這些工具的支持, 所以不必在這些工具上面花太多精力. 使用了RequireJS的應用, 能夠直接使用其自帶的r.js進行代碼優化.
任 何web應用工程都須要構建和部署, 一個自動化的構建和部署腳本能讓編程人員更加專一於應用自己, 而不被繁瑣的流程所困擾. 自動化的構建和部署是一個web前端項目最基本的要求, 當項目開始的時候, 項目組最好能在頭兩個迭代週期就完成自動化的構建和部署腳本的開發.
目前使用比較多的構建工具備:
我我的比較傾向於grunt, 若是工程中用了RequireJS, bbb(grunt擴展)是更好的選擇.
在網絡地址本例子工程中, 我使用grunt/bbb
開發了構建和部署腳本, 能夠完成:
感興趣的人能夠去看看上述例子工程的grunt.js配置文件, 也能夠將這個例子工程做爲web前端項目的模板.
下面的幾點感觸和具體的技術細節無關, 可是我我的以爲, 對於每一個想以編程做爲本身職業規劃的程序員來講, 這幾點尤爲重要.
軟件技術發展很快, 對於熱愛技術的程序員來講, 必須常常更新本身的知識, 才能保證本身不會落伍. 所以, 天天都須要花必定時間去閱讀, 瞭解行業最新的技術發展動態.
個人習慣是用Google Reader訂閱幾個常常更新的前端技術相關的RSS:
另外, 有些郵件週報也很不錯:
GitHub是一個很是有用的站點, 在上面能看到那些大牛們是怎麼討論問題, 如何思考問題, 以及如何實現或者修正的. 閱讀開源項目的文檔能瞭解概要, 若是須要了解細節, 最有效的方式是閱讀代碼, 特別是看針對問題的提交記錄.
StackOverflow是一個很是有名的編程問答站點, 我所遇到的大部分編程問題都能在上面找到答案, 即使沒有答案, 也能找到其餘人對這個問題的考慮. 另外, 別忘了強大的Google Search. 若是Google被牆, 能夠考慮用Bing. 我不喜歡百度, 由於其搜索的命中率過低了.
選擇合適的工具對於軟件項目來講, 能夠極大地提升工做效率, 起到事半功倍的效果. 好的商業軟件大多須要支付鉅額的費用, 而且搞很差還水土不服. 爲了控制成本, 能夠多嘗試嘗試雲端的工具. 在知乎上有關於這些工具的討論, 你們有興趣能夠去看看別人怎麼作的.
多參加技術社區的活動, 包括線上的技術解答, 以及線下的技術講座等. 分享越多, 得到也就越多.