文章的起因，我只是為了回復一個帖子，http://bbs.csdn.net/topics/390908928?page=1
結果，一扯就根本停不下來。索性，一捅為快，反正是周末。
拿到效果圖時，有這么幾步，就我了解的情況做一下分享，不一定全部都是科學，但可以部分借鑒。
我先說一下，熟練后拿到效果圖時這樣的一個狀態：
http://imcn.me/html/y2012/9871.html/comment-page-1
拿到效果圖時，有這么幾步，就我了解的情況做一下分享，不一定全部都是科學，但可以部分借鑒。
1. 拿到效果圖先是分析：
分析什么，分析上下游的相關情況。先說上游設計和產品，如果設計有相關的文檔，則仔細通讀文檔，就文檔中相關業務流程，頁面跳轉，交互行為，設計細節相關清楚不清楚的問題找設計產品了解確認清楚，如果必要需要郵件確認，免得其后扯皮說，當時沒說清楚，當時說的不是這，怎么怎么的。如果可能還需要開會，讓相關把關人與會參與，比如項目經理，技術總監。
業務流程就是直觀的就是需求設計里邊的流程圖，比如注冊，電話->成功->失敗等等，但這不是最終的頁面，只是流程，然后就要跟流程對頁面，哪個頁面對應流程中的那個節點，頁面的跳轉，跳轉的可能，依賴次序，以及重復頁面的梳理等等。
然后在分析下游后台，頁面的數據是否可以順利的實現，后台接口數據提供的日期，大概約定等等。是否有前台業務邏輯判斷的可能，是否前台需要更復雜簡單的處理。是否在評審中有遺漏的細節，需要重新評估，或者直接否決，等等。
分析這些的目的就是：這些頁面交給下游后台時會出現的一些問題，防止頁面交出去以后，有些鏈接的去向不明，數據不正確，以及少頁面，漏模塊等等情況的發生。
2. 寫頁面之前的需要了解的2種方式：
當然切的時候有2種方式，一部分前端可能是第1種方式，就是把psd轉換成html頁面，交給后端，進行數據的完善。其實這種方式有幾個問題：
a. 頁面的結構划分沒有決定權，比如，有些頁面在后端來說，可以通過后台技術來進行一定的拆分組合。但是純html頁面不能實現這個功能，要是不能合理的拆分，有些資源的調用，或后期頁面的修改有很大的麻煩。
b. 頁面的數據的結構狀態，因為設計交與的頁面狀態是一個理想的狀態，但是頁面至少有三種狀態，比如，數據最少的情況，數據最多的情況，以及數據剛好的狀態，而設計給你的是數據剛好的狀態，其它的如果項目緊設計人員少，那就需要自己腦補，如果有真正的效果圖出來，那還好有參考的依據。否則，后期在測試部門回溯的時候也是比較麻煩。
c. 任務完成的不連續性，因為有些ajax的交互發生，需要重新的渲染頁面，這樣結構或樣式可能會發生改變，如果是純html頁面，那只有等后端完成數據狀態之后，在去完成相關ajax的相關模塊，或者是等后端自己完成ajax，然后出現問題在找你，等等的情況，都加大了合作之間出現bug的風險或可能。
鑒於以上情況，我個人建議利用后端語言的優勢來寫靜態的數據結構或者直接輸出動態的最終view層頁面。這樣在前端層的頁面控制權完全交與前端來負責，但是這樣得具備一個條件：
對前端的技術儲備有大大的要求，必須了解一門后端語言為基礎，了解ajax的整個交互過程或一些常見問題的處理。
當然，說起來很玄乎，其實這些東西都不難。比如流行的web后端語言php，以及php相關的一些框架提供的view模板，可能說，有一定的編程基礎或靜下心來的決心，少花點時間基本都沒有問題。
這種方式也有一個缺點，就是小型的活動頁面，或者一些專題頁面，如果完全套用這種方式，可能盤子太大，不適合。用純html的頁面反而會更快。
3. 然后才是真正的動手寫頁面切圖：
寫頁面也是需要一個過程，從最初的寫出基本的效果到解決常見瀏覽器的兼容bug到最后兼顧頁面復用性，健壯性以及擴展性：
a. 頁面的健壯性：
這個怎么說呢，這個前面已經提過，UI出的psd圖是一個頁面理想狀態下的形態，而頁面有數據，會出現兩種極端狀態，一，數據極多，二，數據極少。所以在頁面排版的時候，考慮這兩種狀態，以免數據太多的時候，撐破頁面，以免數據太少，頁面部分元素會出現收回去狀況，這樣的頁面會出現一些細節沒有處理的常規失誤。
b. 頁面的擴展性：
可以說，這個也是第一條的擴充，擴展性的意思為，在頁面的模塊很少的時候，要考慮未來添加子模塊或兄弟模塊的狀態，為將來留好html接口。在將來添加模塊的時候，盡可能少的去動原來的html結構，使html易於擴展。這個具體情況，具體處理。一般的處理就是如果有可能會有兄弟元素就多套一層，為后台添加兄弟元素盡可能的不影響現有結構。這個點乍看起來很小，其實如果擴充到整個項目，多個項目就有可觀的效應了。
c. 頁面的復用性：
由於頁面中風格相似的模塊很多，或頁面中與頁面中相似的模塊很多，但是總會有那么一丁點的差異，這是設計師認識世界然后在表達世界的產物，我們理解設計師的職業操守，所以只能在前期做一些技術處理，免得后期問候某崗位的親人。具體的有的模塊高點有的模塊低點，還有結構完全一樣，但底紋不一定。這樣建議把表現形式的樣式放在一個class中，物理屬性放在一個class中。還有就是裝飾性的圖片決不不以明標簽的方式插入到頁面中，內容式的內容絕對以<img src="" />的方式插入中去，以免將來多主題，多語言版本的實現。
可能有時候還有的情況是，頁面完全切不出來，html，css完全不知道怎么寫了。但基礎掌握良好，概念基本清楚。這時候我個人建議應該是吸收別人好的東西時候到了，也是個人水平瓶頸的時候，需要在堅持一下完全的突破。具體的方式就是，用firebug去分析先有的bat各個項目的各個頁面，總有你可以借鑒的地方。
4. 切完頁面之后：
本着職業操守或一個有責任的前端，需要進一步分析各個頁面的結構是否在原來加班的時候，或問候親人的時候沒有考慮完全的，或者原來的實現方式不是太好，需要進一步完善，有性能優化或結構優化的可能。
前端開發qq群：159758989 ，禁止閑聊，非喜勿進~！