[[83932]]

 這個標題目的很簡單，就是為了讓我們這些日復一日埋頭碼頁面的網頁重構工作者，重拾面對這個我們所熱愛的行業的熱情；檢視經常被我們在繁瑣的工作中忽略的初級錯誤；以新人的眼光和態度迸發熱情認真對待每一個頁面。基本上都是我最想表達和同樣需要重新審視的東西，也希望可以作為給剛入行的新人們的一些小小指引:）

一般來說，接到一個新的需求，以簡單的少頁面需求為例，流程上可以簡單分為幾大階段：

1. 查看設計稿，閱讀需求文檔、原型圖；

2. 查看并分析設計稿，在腦中整理出粗略解決方案；

3. 切圖、合并圖片；

4. 書寫HTML代碼、CSS代碼；

5. 檢查瀏覽器兼容性；

6. 對比設計稿，檢查還原度；

7. 開發聯調修改，測試解bug，上線后再確認一遍頁面無bug。

理想情況來說，按照流程一步步做下去，很順利地就能把需求處理好然后***上線，重構所做的工作某些程度上也被視為相對設計師來說相當的不苦。但我們不得不經常面對的糾結情況同樣有很多，其中涉及的更多工作內容可能包括：

1. 需求變更，包括設計稿上的修改和重構直接處理的靜態頁面的修改；

2. 適應原有動態模塊HTML結構的樣式重寫；

3. 多平臺調試，如PC客戶端內嵌、移動客戶端；

4. 種種或不明或刁難情況。

假設情況一：需求不明確，負責人多次變更，設計稿內容短缺且無原型稿。

如果只是三種可能之一，需求不明確可以找負責人確認，負責人換可以看需求文檔，設計稿不全可以找設計師補。如果偏偏不巧同時碰上了這么個亂子，甚至雪上加霜設計師都不知道跑哪去了，需求方趕著上線，負責人被煩得只能趕緊把這個爛攤子丟出去…… 這種時候跟他們一樣懷著煩躁的心態顯然是不可取的，再急也要對你的項目負責，對的，需求給到你就是你的項目了不管他掛誰的名頭，***出來的頁面被罵被恥笑難道你能很高興地一起哈哈大笑么。

最該做的，首先是理清這個項目到底是個什么玩意，拿來干什么，需要實現哪些功能，既然沒人能理清這個流程，自己學一下梳理也是種技能。還有，再煩躁也不要跟負責人叫囂，一條繩子上的螞蚱誰都不好過，互相理解能取得對方的感恩和尊重。當然要適當給點下馬威，你說趕著上線給你加班加點做，需求方（頭頭or客戶）不滿意又來一堆修改折騰，也要麻煩負責人懂得反省自己的忽略的過程。***，抱著平和的心態，安靜地完成這個項目。

假設情況二：迅雷看看評論模塊

評論模塊可以說是看看重要而獨特的數據之一，根源在看看官網，輕易變更結構需要后臺重新開發一套模板和重新錄入內容，那么也意味著如果需要調用評論必須遵守原來的結構。這樣的情況對于求新求變的重構來說是有點痛苦的，但如果換個角度想，一樣的結構依靠CSS變換出多彩多姿的形式，不也是能力挑戰之一么。以雪花秘扇官網為例，小小的評論模塊加了邊框圓角和鼠標經過變換的效果是不動感了許多~

假設情況三：需求是內嵌在迅雷7客戶端的應用插件

Windows平臺上的國內軟件內嵌瀏覽器目前還未見過非IE核心的（如果你見過歡迎分享），迅雷7內嵌瀏覽器則以本機瀏覽器版本為準，但僅包括IE6、IE7（7及以上版本皆采用IE7）。

為客戶端內嵌頁面要多考慮一些特殊情況，如：

7.2之前的迅雷版本的應用插件，相比起瀏覽器全屏的大小可顯示區域較小，為了達到接近實際展現的效果，將瀏覽器縮放成同比例是個不錯的主意，推薦火狐插件web developer，菜單中的窗口大小可以自定義多種尺寸方便切換調試。 說到瀏覽器窗口大小必須一提的是經常會被忽略的一個兼容點，即瀏覽器非全屏狀態下背景被截斷，如下圖

即便PC上的瀏覽器縮放可以忽略不管，別忘了在移動設備端界面太小頁面顯示不全需要滑動來瀏覽整個頁面的情況，不能不說這是看起來不太美妙的體驗。

PS：關于移動平臺的情況篇幅有限暫且略過，我會在后續的文章里繼續介紹 :）

假設情況四：不時穿插的緊急修改而你手里已經有三四個需求在同時進行，各種混亂夾雜

繁忙的白天RTX會響個不停一會這個專題幫忙看下這個問題，一會大廳那個商城需要加點東西…顧得上這個可能就漏了那邊需要把寬度改小點直接扔了出去，沒顧上那邊開發產品一并叫囂趕著上線啊發版啊速度啊…便簽條列下進行中的項目、交付時間、修改要點、待深思問題等備注顯得就很有必要了，紙筆拿上順便練練書法，省得不小心好多字都不會寫了~

回想網頁重構都在做什么到此結束，歡迎探討交流，你可以不認同我的觀點并提出異議，我也愿意誓死為你捍衛這份權利并很樂意來一番唇槍舌劍 :）

原文鏈接：http://kb.cnblogs.com/page/148953/