webapp項目前端總結

標籤：使用   公司   客戶   另一個   mda   開始   地方   多個   代理   

提綱

• 整體把握，從設計稿入手——技術選型
• 並行開發，從實現靜態頁面開始
• 前端自動化
• 前端js邏輯
• 前後端整合
• 小問題集合
• 總結

1.整體把握，從設計稿入手 —— 技術選型

新項目到手，算是運氣好，設計稿都已經全部完成了，40多個頁面。不用擔心邊做邊改的情況。能夠提前確定重用性和一些規範。
項目主要要求：
1. 相容PC、、移動端，相容現代瀏覽器，IE9+等
1. 嵌入到安卓、ios用戶端和，要求頁面獨立
1. 使用node.js作為中介軟體

我負責前端頁面和邏輯，node是另一個同事負責，前端架構由前端組長負責。
前端架構選型是開發前很重要的準備：
1. UI架構: 考慮過uikit、amazeUI、bootstrap，最終選擇bootstrap+自訂樣式，主要原因公司其他項目也用的bootstrap。對我來說這三個架構我之前都沒用過，作為一個一年經驗的前端很可笑吧，其實我覺得也沒啥，馬上學便是。
1. js庫: 考慮過jquery和zepto，最終選擇jquery
1. 前端工具： gulp,browserify，bower，less
1. node用的express，node那個同事熟悉
1. 前端模板用的swig
1. greensock動畫庫

 2.並行開發，從實現靜態頁面開始

經過一個星期的前期準備和調研，前端基本的架子搭起來了，gulp、bower、 規範。js這一塊自動化還未準備就緒，node背景架子也在搭建。各方進度都有不一致的地方，考慮到並行開發，我建議我先做靜態頁面，node後台繼續搞自己的，組長繼續研究架子。
這樣也好，專心寫頁面，能更專註的考慮html、css方面的東西。做完40個頁面總共花了8的工作時間（未加班），我覺得還是比較快了。
css方面從bower裡引入了bootstrap的部分less源碼，再覆蓋一些源碼需要修改的樣式，然後更多的是自己定義的樣式。這個過程中已經考慮了很多重用、結構、命名問題，所以前期4天的時間我的進度都很慢，因為邊寫就邊最佳化了，磨刀不誤砍柴工，後4天就差不多完成了30個頁面。以下是檔案結構，按照bootstrap規範：

3.前端自動化

靜態頁面寫完了，剛好組長架子、工作流程這一塊也搭好了，後台也做了一些功能等待整合。
組織js用到了browserify，前後端的js邏輯都能用到require了。
項目比較緊，組長這一個架子都還沒徹底搞懂，還是挺複雜的，之後松點了將會好好看看。
自動化帶來了更高效率的開發，監聽、打包、壓縮、iconFont、require等前期做好了配置，後面幾乎就不需要改動了，對於前端來說，這些都是必不可少的技術要求。

4.前端JS邏輯

JS這一塊，為每個頁面配置了viewName，寫在了base.html裡，所有頁面將繼承base，這一塊當然就是開始說的swig模板，相應檔案夾的裡所有html檔案的js將會引入page->{% viewName %}->index.js。
browserify把一些依賴js掛到了全域，比如：jquery，jq-validate，jq-form，greensock。
特定的頁面配置了pageConfig，用來擷取一些資料。
觸發事件都用事件代理控制，組件間通訊用trigger觸發器。

view裡：html寫好dom節點和動態參數，自動化工具會自動拼接節點產生swig前端模板，在其他js裡面就可以require了。傳入相應參數，就可以輸出到頁面了，自訂popup組件和list組件很方便就能調用。

5.前後端整合

好像沒啥好說的，後端準備好介面，前端調用就行了，某些問題上需要多點溝通，保證需求理解一致。

 6.小問題集合

1. gulp iconFont某些字型表徵圖殘缺，暫時icomoon手動更新
2. 移動端 active 失效: -webkit-tap-highlight-color: transparent;
3. html5 video audio很多事件現代瀏覽器支援不好，特別是移動端的瀏覽器，可以用這個地址做測試http://www.w3.org/2010/05/video/mediaevents.html

 7.總結

1. 整體把控、注重新命名和重用，出現覺得不合理的和需要重用的就應該最佳化。
2. 如果有條件先實現靜態頁面，再最後來寫js邏輯，這樣開發應該會更快。
3. 因為多少自己也做過設計，也知道有時候作為前端感覺設計師不放過每一個細節讓人覺得有點累，但是我們應該尊重設計師，不要有任何抱怨因為這是他們的責任，當然我說這一點並不是我之前抱怨他們了，而是每當很忙很累的時候，看著設計師提上來的UI問題時候，我這樣激勵過自己，覺得這一點還是挺好，讓我更積極，希望大家能多換位思考。
4. 前後端做好各自的單元測試，盡量保證自己代碼問題會是最少的，這樣整合成本就變得低了。
5. 用到第三方架構和庫且不熟悉的情況下，遇到需求問題，應該首先從三方文檔裡找解決需求的辦法，實在引入的三方庫沒有解決方案，再考慮自己解決。
6. 前期約定好各種規範

 

http://www.cnblogs.com/1wen/p/4477894.html

 

webapp項目前端總結