善于從bug中分析問題也是一種能力
在前端開發中，出現一些bug不過是家常便飯。這些bug常常會使你焦頭爛額，不知所措。至少在我的早期職業生涯中是這樣。拿CSS來說，在FF下好好的樣式，可到了IE就全亂了套。
Js也有同樣的問題，在FF中運行良好的代碼，放在IE中運行就會提示你有錯誤發生。相信這類問題你一定遇到過，也深以為痛。但是，如果你弄清了這些問題的實質，你就會豁然開朗，你會突然發現一切盡在你的掌握之中。
好些時候，有朋友拿著在IE中亂套的頁面向我求救。在看過他們的代碼之后，我會告訴他們在代碼的某一行加上zoom:1即可，在嘗試著加上這個屬性之后，問題迎刃而解。當他們下次拿著同樣的問題（不過這次是以不同的方式呈現出來）再來求救的時候，我用的是相同的解決方案。
曾經有個朋友，在頁面布局時發現某個地方總是多一片空白，找了很久也沒解決，他將鏈接地址發給我，我通過Fiebug看了代碼之后，告訴他問題的癥結所在，并提出解決方案。當他想進一步了解為什么是這樣的時候，我告訴他這是“塊格式化上下文（Block formatting context）”和IE特有的hasLayout屬性所致，并發給他相關的資源鏈接。
開始的時候，我錯誤的以為這是IE中的bug，在充分了解“格式化上下文”和 IE的hasLayout屬性之后，我明白了那些常見問題發生的根本原因。
同樣，在js調試中我們也會遇到類似的問題。比如，在定義一個對象時，多出一個逗號（如var obj = {a:”bug”,b:”shit”,}或者var arr = [1,2,3,,]）造成IE6/7/8不能正常運行。
最惱火的時候，在你查遍所有代碼，發現竟然是一個逗號造成的時候，你不免生出許多無奈。一個逗號，竟帶來如此的差異，那么這個問題就值得細細思考一番。幾番調試，你會發現數組多一個逗號在瀏覽器之間帶來的差異，逗號位于數組的中間和位于數組的末尾產生的不同結果。
當你查閱相關的資料，最終在ECMAScript 5 11.1.4中找到對數組中多余逗號的相關描述時，你就會徹底明白了問題發生的根本原因，你就會明白這不是一個bug：FF等高級瀏覽器按照規范來運行，只是IE瀏覽器到了IE9才真正實現它。
這兩個我們常見的問題，尤其是***個問題，我不想再本篇中對此做詳盡的描述。關于此類問題的文章已有人做過分析，無須我再次添足。
我要說的是，在前端開發中，當同樣的問題多次出現的時候，學會分析，學會思考，學會總結，方能提高。唐代名醫孫思邈有云：“上工治未病，中工治欲病，下工治已病”。問題出現，如果僅僅是為了解決問題而解決問題，那么我們就會永遠停留在“治已病”的階段，問題解決起來就相對棘手。
倘若能從問題當中尋根問底，刨清實質，就會更進一步。一旦問題了然于胸，在開發的開始階段就會避免問題的發生，或對問題的發生有一定的預見性。在這個時候，你就是“上工”——“是故圣人不治已病治未病，不治已亂治未亂，此之謂也。”
【編輯推薦】
