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