善于從bug中分析問題也是一種能力

　　在前端開發(fā)中，出現(xiàn)一些bug不過是家常便飯。這些bug常常會使你焦頭爛額，不知所措。至少在我的早期職業(yè)生涯中是這樣。拿CSS來說，在FF下好好的樣式，可到了IE就全亂了套。Js也有同樣的問題，在FF中運(yùn)行良好的代碼，放在IE中運(yùn)行就會提示你有錯(cuò)誤發(fā)生。相信這類問題你一定遇到過，也深以為痛。但是，如果你弄清了這些問題的實(shí)質(zhì)，你就會豁然開朗，你會突然發(fā)現(xiàn)一切盡在你的掌握之中。

　　好些時(shí)候，有朋友拿著在IE中亂套的頁面向我求救。在看過他們的代碼之后，我會告訴他們在代碼的某一行加上zoom:1即可，在嘗試著加上這個(gè)屬性之后，問題迎刃而解。當(dāng)他們下次拿著同樣的問題(不過這次是以不同的方式呈現(xiàn)出來)再來求救的時(shí)候，我用的是相同的解決方案。曾經(jīng)有個(gè)朋友，在頁面布局時(shí)發(fā)現(xiàn)某個(gè)地方總是多一片空白，找了很久也沒解決，他將鏈接地址發(fā)給我，我通過Firebug看了代碼之后，告訴他問題的癥結(jié)所在，并提出解決方案。當(dāng)他想進(jìn)一步了解為什么是這樣的時(shí)候，我告訴他這是“塊格式化上下文(Block formatting context)”和IE特有的hasLayout屬性所致，并發(fā)給他相關(guān)的資源鏈接。開始的時(shí)候，我錯(cuò)誤的以為這是IE中的bug，在充分了解“格式化上下文”和 IE的hasLayout屬性之后，我明白了那些常見問題發(fā)生的根本原因。

　　同樣，在js調(diào)試中我們也會遇到類似的問題。比如，在定義一個(gè)對象時(shí)，多出一個(gè)逗號(如var obj = {a:”bug”,b:”shit”,}或者var arr = [1,2,3,,])造成IE6/7/8不能正常運(yùn)行。最惱火的時(shí)候，在你查遍所有代碼，發(fā)現(xiàn)竟然是一個(gè)逗號造成的時(shí)候，你不免生出許多無奈。一個(gè)逗號，竟帶來如此的差異，那么這個(gè)問題就值得細(xì)細(xì)思考一番。幾番調(diào)試，你會發(fā)現(xiàn)數(shù)組多一個(gè)逗號在瀏覽器之間帶來的差異，逗號位于數(shù)組的中間和位于數(shù)組的末尾產(chǎn)生的不同結(jié)果。當(dāng)你查閱相關(guān)的資料，最終在ECMAScript 5 11.1.4中找到對數(shù)組中多余逗號的相關(guān)描述時(shí)，你就會徹底明白了問題發(fā)生的根本原因，你就會明白這不是一個(gè)bug：FF等高級瀏覽器按照規(guī)范來運(yùn)行，只是IE瀏覽器到了IE9才真正實(shí)現(xiàn)它。

　　這兩個(gè)我們常見的問題，尤其是第一個(gè)問題，我不想再本篇中對此做詳盡的描述。關(guān)于此類問題的文章已有人做過分析，無須我再次添足。我要說的是，在前端開發(fā)中，當(dāng)同樣的問題多次出現(xiàn)的時(shí)候，學(xué)會分析，學(xué)會思考，學(xué)會總結(jié)，方能提高。唐代名醫(yī)孫思邈有云：“上工治未病，中工治欲病，下工治已病”。問題出現(xiàn)，如果僅僅是為了解決問題而解決問題，那么我們就會永遠(yuǎn)停留在“治已病”的階段，問題解決起來就相對棘手。倘若能從問題當(dāng)中尋根問底，刨清實(shí)質(zhì)，就會更進(jìn)一步。一旦問題了然于胸，在開發(fā)的開始階段就會避免問題的發(fā)生，或?qū)栴}的發(fā)生有一定的預(yù)見性。在這個(gè)時(shí)候，你就是“上工”——“是故圣人不治已病治未病，不治已亂治未亂，此之謂也。”

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈