高端IT就業(yè)培訓(xùn)專家-15年口碑積累，20萬(wàn)名研發(fā)工程師從這里走出

        很多時(shí)候，我們因?yàn)殛P(guān)注最終的結(jié)果，而總是忽略其它的情況。所以我們寫的代碼并不是那么的健壯。這篇文章屬于程序員內(nèi)功修煉，值得一看。寫代碼的時(shí)候，有幾個(gè)階段可以參考一下（魚鷹經(jīng)歷并總結(jié)）：

 階段一 

只要最終的結(jié)果

        處于這個(gè)階段的一般都是初學(xué)者，眼里只有一個(gè)目標(biāo)，那就是程序運(yùn)行成功，從不考慮其他因素。比如一個(gè)簡(jiǎn)單的 SPI 驅(qū)動(dòng)程序，最終的目標(biāo)只要一個(gè)，通信成功。所以當(dāng)需要延時(shí)時(shí)就會(huì)采用死等方式等待結(jié)果，而不會(huì)考慮其他可能出現(xiàn)的結(jié)果，比如因?yàn)槟撤N原因?qū)е乱_電平被持續(xù)一個(gè)電平不變，導(dǎo)致死循環(huán)；比如因?yàn)槟愕难訒r(shí)，導(dǎo)致其他人功能無(wú)法及時(shí)處理。這個(gè)時(shí)候的思考總是過(guò)于理想化，不是因?yàn)樽约禾硐?，太?lè)觀，而是因?yàn)闆](méi)有足夠的經(jīng)歷告訴你，這樣寫是有問(wèn)題的。因?yàn)闆](méi)有經(jīng)歷過(guò)，所以初學(xué)者也就考慮不了那么多，所以你看初學(xué)者的代碼會(huì)很簡(jiǎn)單，是一條直線，邏輯很清晰，沒(méi)有岔路。

 階段二 

做一些常見(jiàn)的異常處理

        隨著經(jīng)歷越多（不管是網(wǎng)上看到的還是自己經(jīng)歷的），漸漸地，自己的代碼變得多了一些，功能還是那個(gè)功能，只是這時(shí)候的你考慮的更多，更全面，你漸漸的增加了各種異常處理。比如你不再使用死等方式延時(shí)，而是增加了一個(gè)等待時(shí)間的超時(shí)處理；又比如你寫的程序不再只有if里面的內(nèi)容（條件為真），還有else（條件為假）。這個(gè)時(shí)候的你眼里不再只有最終的結(jié)果，還有在運(yùn)行過(guò)程中可能出現(xiàn)的其他情況，并且會(huì)對(duì)這些情況做處理。

 階段三 

懷疑一切

        這個(gè)階段的你不再相信任何東西了，即使它是那么的可靠。你總是在函數(shù)開(kāi)始處檢查傳入的參數(shù)（如果有的話），判斷指針是否為空，判斷數(shù)據(jù)是否在需要的范圍內(nèi)，等等。總是在使用指針、數(shù)組的時(shí)候小心翼翼，深怕一不小心就越界了，而這種BUG只有經(jīng)歷的人才懂到底有多難查。總是在異常的地方做出一些動(dòng)作，如返回錯(cuò)誤代號(hào)、如打印錯(cuò)誤消息等。不管怎樣，在出現(xiàn)問(wèn)題后，你總是能夠快速的定位問(wèn)題，而這，得益于你對(duì)異常的處理。

 階段四 

做好善后工作

        階段三可能讓你很快的定位問(wèn)題，但是一旦出現(xiàn)問(wèn)題，程序還是無(wú)法正常執(zhí)行下去，比如申請(qǐng)的資源（內(nèi)存、信號(hào)量等）沒(méi)釋放，又比如關(guān)閉的中斷在異常后未重新打開(kāi)等等。所以異常處理代碼除了能很快定位BUG外，還要做好善后處理，這樣才能讓程序健壯的一直運(yùn)行下去。

        魚鷹曾在《代碼寫完了，你要花多少時(shí)間測(cè)試？》一文中介紹了一些調(diào)試方法，今天，繼續(xù)更深入的探討。

（uCOS II代碼片段）

          很多人其實(shí)不明白，為什么一定要在函數(shù)開(kāi)頭檢查參數(shù)，這不是很浪費(fèi)時(shí)間的嗎（從上面可以看到，參數(shù)檢查有時(shí)候比真正需要執(zhí)行的代碼還要多）？ 不說(shuō)指針，就說(shuō)一些普通變量，為什么要檢查？ 檢查的意義又在哪里？

 浪費(fèi)時(shí)間？

        首先說(shuō)說(shuō)浪費(fèi)時(shí)間的問(wèn)題，確實(shí)，因?yàn)榭偸窃陂_(kāi)頭檢查參數(shù)，會(huì)浪費(fèi)CPU的時(shí)間（魚鷹一開(kāi)始也非常不喜歡），但是當(dāng)你經(jīng)歷了各種難查的BUG之后，你會(huì)發(fā)現(xiàn)，這點(diǎn)時(shí)間還是浪費(fèi)的起。 而事實(shí)上，軟件開(kāi)發(fā)一般都會(huì)有兩個(gè)版本，一個(gè)是Debug版本，一個(gè)是Release版本，只要通過(guò)宏進(jìn)行控制，那么就可以在穩(wěn)定之后，不再檢查這些參數(shù)了。 但是有些重要的數(shù)據(jù)，即使穩(wěn)定了，也不能放棄對(duì)它的檢查，否則一旦出現(xiàn)問(wèn)題，就是災(zāi)難。 所以在檢查時(shí)，還要考慮這些檢查是否在Release版本也是需要的，即按重要性分開(kāi)檢查。

 為什么要檢查？檢查的意義又在哪里？

        這些檢查就像是 函數(shù)的護(hù)城河 ，保證即使參數(shù)錯(cuò)誤，也不會(huì)導(dǎo)致異常問(wèn)題，比如數(shù)組越界，計(jì)算出錯(cuò)等。 那么我們要問(wèn)了，參數(shù)怎么會(huì)錯(cuò)誤，代碼都是固定死的，有經(jīng)驗(yàn)的都知道，參數(shù)是保存在 ?；蚣拇嫫?/span> 的，怎么會(huì)錯(cuò)呢？ 你說(shuō)內(nèi)存數(shù)據(jù)保存時(shí)有問(wèn)題？ 保存時(shí)為1，讀出時(shí)為0？ 別逗了，如果真是這樣，那還怎么玩？ 程序根本沒(méi)辦法跑好吧（遇到強(qiáng)干擾可能會(huì)出現(xiàn)這種情況，甚至可能CPU執(zhí)行流程都是亂的，最終只能重啟，這個(gè)魚鷹倒還沒(méi)遇到過(guò)）。 我們可以認(rèn)為存在RAM和FLASH的數(shù)據(jù)在存儲(chǔ)和讀取方面沒(méi)有問(wèn)題，那么又是什么導(dǎo)致了參數(shù)出錯(cuò)呢？

 棧溢出 

        前面說(shuō)過(guò)，參數(shù)有可能保存在棧里面，如果有些棧溢出了，參數(shù)被破壞也就可以理解了。（關(guān)于棧，可參考筆記《 今天，你的棧溢出了嗎？ 》）

 數(shù)組越界、野指針等指針問(wèn)題 

        一旦越界，那么產(chǎn)生的破壞力不可想象。 所謂越界，就是修改了不屬于你的變量。 比如一個(gè)數(shù)組，你操作了數(shù)組外的數(shù)據(jù)（不管是數(shù)組前面的還是數(shù)組后面的）。 而越界根據(jù)位置又可以分為三種情況。

第一種， 棧（stack） ，比如你在棧里面申請(qǐng)了一個(gè)數(shù)組，越界了，那么修改的就是棧內(nèi)容。

第二種： 堆（Heap） 。你通過(guò)malloc申請(qǐng)的內(nèi)存，如果操作失誤，那么就會(huì)修改不屬于你的空間。

第三種。 全局變量（data） 。如果操作失誤，也會(huì)出現(xiàn)問(wèn)題。

        其實(shí)， 越界這種問(wèn)題不一定就只會(huì)修改這些單獨(dú)的區(qū)域，可能是兩個(gè)區(qū)、三個(gè)區(qū)一起修改了 ，畢竟指針可不管修改的地址到底屬于哪個(gè)區(qū)，還有一種是 野指針 導(dǎo)致的異常操作，那么它修改的位置只有鬼知道了（鬼好像不懂程序）。 比如你申請(qǐng)了一個(gè)數(shù)組，通過(guò)傳入的參數(shù)修改數(shù)據(jù)，如果不限制參數(shù)大小，你確定它不會(huì)把你數(shù)組后所有的內(nèi)存都給清零？ ！

        如果硬要為上面三種情況劃分處理難度等級(jí)，那么最容易也最快解決的就是全局變量的修改，為什么？因?yàn)榈刂繁容^固定，而ARM內(nèi)核有神器處理這種情況，如果出現(xiàn)概率高的話，一查一個(gè)準(zhǔn)，所以魚鷹都不怎么苦惱這種問(wèn)題。

        最難解決的是堆的修改，這種問(wèn)題比棧更難找。原因就在于， 內(nèi)存動(dòng)態(tài)申請(qǐng)和釋放 ，可能這次修改的是這個(gè)位置，沒(méi)出現(xiàn)問(wèn)題，下次修改另一個(gè)地址，就出現(xiàn)了問(wèn)題，這種是最難查的。而棧的空間一般不會(huì)太大，而且他的存取都是有規(guī)律的，要稍微好查一些。

        可能你會(huì)問(wèn)，參數(shù)會(huì)保存在寄存器里面，那么寄存器的數(shù)據(jù)有可能被異常修改嗎？ 異常修改的可能性很小，因?yàn)閷?duì)于C語(yǔ)言而言，寄存器是透明的，用戶很難操作這個(gè)。 但是，雖然說(shuō)參數(shù)傳入之后被修改的可能性很小，但是傳入前修改的可能性還是很大的，比如你傳入的參數(shù)是一個(gè)全局變量，那么這個(gè)全局變量是可能被異常修改的?。?/span> 所以，參數(shù)檢查，是一個(gè)健壯程序必須要有的，這是防止產(chǎn)生重大問(wèn)題最重要的護(hù)城河。 而越早檢查出問(wèn)題，那么越容易定位問(wèn) 題。

        蝴蝶效應(yīng)大家都知道，千里之堤毀于蟻穴大家也知道，用在程序里面也是很合適的。 可能你會(huì)說(shuō)，我對(duì)自己有信心，我的技術(shù)杠杠的，絕對(duì)不會(huì)出問(wèn)題。 真的是這樣嗎？

 01 

時(shí)間久了自己都忘了

        工作時(shí)，常常完成了一個(gè)項(xiàng)目，下一個(gè)項(xiàng)目馬上來(lái)了，如果老項(xiàng)目需要維護(hù)，不需要一兩年，只要一兩個(gè)月，如果你沒(méi)有參數(shù)檢查、異常處理的好習(xí)慣，一旦你修改了代碼，那么很可能因?yàn)槟承┦韬觯瑢?dǎo)致難以發(fā)現(xiàn)的BUG，而解決這些BUG的時(shí)間，比你寫這些異常處理代碼更多。 但是在你剛開(kāi)始寫這份代碼的時(shí)候，因?yàn)樗悸非逦?，考慮的比較多，有哪些異常很清楚，那么很容易寫出那些異常處理代碼。 比如魚鷹去年寫了一份通過(guò)位綁定地址，批量配置引腳的時(shí)鐘、寄存器信息的代碼，那么今年再?gòu)?fù)用代碼的時(shí)候，因?yàn)樽约旱氖韬?，很可能需要大量的時(shí)間解決BUG，那我寫這份代碼的意義就不存在了（寫這份代碼就是為了在標(biāo)準(zhǔn)庫(kù)中通過(guò)端口和引腳號(hào)快速配置引腳），而如果說(shuō)，一旦因?yàn)槭韬鰧?dǎo)致的問(wèn)題，程序會(huì)自動(dòng)幫你檢查，那么解決問(wèn)題就很快了。

 02 

維護(hù)

        不管是別人維護(hù)，還是自己維護(hù)，當(dāng)項(xiàng)目需要更改需求時(shí)，如果因?yàn)槟承┦韬?，?dǎo)致了BUG，那么解決起來(lái)費(fèi)時(shí)費(fèi)力，而且即使你這次解決了，難道下次還要重蹈覆轍嗎？

 03 

合作開(kāi)發(fā)

        一個(gè)項(xiàng)目可能不是一個(gè)人完成的，而是多人合作。而每個(gè)人的水平有高有低， 你敢說(shuō)別人不會(huì)寫出有問(wèn)題的代碼？你敢說(shuō)自己一定不會(huì)寫出有問(wèn)題的代碼？ 而且即使別人沒(méi)有寫出BUG，但因?yàn)槟承┰?，需要修改或屏蔽你的代碼，如果你的代碼能自動(dòng)提醒出這些異常，那么定位問(wèn)題也就不難了。 而魚鷹為什么寫代碼的時(shí)間會(huì)比測(cè)試長(zhǎng)，除了掌握大量的調(diào)試技巧外，就是因?yàn)樵趯懙臅r(shí)候，會(huì)考慮很多，并且這些考慮，大部分會(huì)以代碼的形式存在，少量的會(huì)以注釋或者#warning、#error 形式存在，而其中，最好的方式是代碼形式，因?yàn)樗鼙ＷC程序正常運(yùn)行，即使不能正常運(yùn)行，也應(yīng)該打印消息以提醒用戶問(wèn)題在何處。 所以，魚鷹總是很慶幸自己當(dāng)初花了不少時(shí)間去寫異常處理代碼，而這些代碼，如果需要事后彌補(bǔ)的話，相信花的時(shí)間會(huì)更多（定位問(wèn)題、回想當(dāng)初自己如何思考、補(bǔ)充異常處理代碼，這些都要時(shí)間）。

END

免責(zé)聲明：整理文章為傳播相關(guān)技術(shù)，版權(quán)歸原作者所有

如有侵權(quán)，請(qǐng)聯(lián)系刪除

  專業(yè)始于專注  

  卓識(shí)始于遠(yuǎn)見(jiàn)  

# 往期干貨 #

點(diǎn)擊下方圖片即刻前往

   瞅一瞅看一看 ↘