很多時候,我們因為關(guān)注最終的結(jié)果,而總是忽略其它的情況。所以我們寫的代碼并不是那么的健壯。
這篇文章屬于程序員內(nèi)功修煉,值得一看。
寫代碼的時候,有幾個階段可以參考一下(魚鷹經(jīng)歷并總結(jié)):
階段一:只要最終的結(jié)果
處于這個階段的一般都是初學(xué)者,眼里只有一個目標(biāo),那就是程序運行成功,從不考慮其他因素。
比如一個簡單的 SPI 驅(qū)動程序,最終的目標(biāo)只要一個,通信成功。所以當(dāng)需要延時時就會采用死等方式等待結(jié)果,而不會考慮其他可能出現(xiàn)的結(jié)果,比如因為某種原因?qū)е乱_電平被持續(xù)一個電平不變,導(dǎo)致死循環(huán);比如因為你的延時,導(dǎo)致其他人功能無法及時處理。
這個時候的思考總是過于理想化,不是因為自己太理想,太樂觀,而是因為沒有足夠的經(jīng)歷告訴你,這樣寫是有問題的。
因為沒有經(jīng)歷過,所以初學(xué)者也就考慮不了那么多,所以你看初學(xué)者的代碼會很簡單,是一條直線,邏輯很清晰,沒有岔路。
階段二:做一些常見的異常處理
隨著經(jīng)歷越多(不管是網(wǎng)上看到的還是自己經(jīng)歷的),漸漸地,自己的代碼變得多了一些,功能還是那個功能,只是這時候的你考慮的更多,更全面,你漸漸的增加了各種異常處理。
比如你不再使用死等方式延時,而是增加了一個等待時間的超時處理;又比如你寫的程序不再只有if里面的內(nèi)容(條件為真),還有else(條件為假)。
這個時候的你眼里不再只有最終的結(jié)果,還有在運行過程中可能出現(xiàn)的其他情況,并且會對這些情況做處理。
階段三:懷疑一切
這個階段的你不再相信任何東西了,即使它是那么的可靠。
你總是在函數(shù)開始處檢查傳入的參數(shù)(如果有的話),判斷指針是否為空,判斷數(shù)據(jù)是否在需要的范圍內(nèi),等等。
總是在使用指針、數(shù)組的時候小心翼翼,深怕一不小心就越界了,而這種BUG只有經(jīng)歷的人才懂到底有多難查。
總是在異常的地方做出一些動作,如返回錯誤代號、如打印錯誤消息等。
不管怎樣,在出現(xiàn)問題后,你總是能夠快速的定位問題,而這,得益于你對異常的處理。
階段四:做好善后工作
階段三可能讓你很快的定位問題,但是一旦出現(xiàn)問題,程序還是無法正常執(zhí)行下去,比如申請的資源(內(nèi)存、信號量等)沒釋放,又比如關(guān)閉的中斷在異常后未重新打開等等。
所以異常處理代碼除了能很快定位BUG外,還要做好善后處理,這樣才能讓程序健壯的一直運行下去。
魚鷹曾在《代碼寫完了,你要花多少時間測試?》一文中介紹了一些調(diào)試方法,今天,繼續(xù)更深入的探討。
(uCOS II代碼片段)
很多人其實不明白,為什么一定要在函數(shù)開頭檢查參數(shù),這不是很浪費時間的嗎(從上面可以看到,參數(shù)檢查有時候比真正需要執(zhí)行的代碼還要多)?不說指針,就說一些普通變量,為什么要檢查?檢查的意義又在哪里?
浪費時間?
首先說說浪費時間的問題,確實,因為總是在開頭檢查參數(shù),會浪費CPU的時間(魚鷹一開始也非常不喜歡),但是當(dāng)你經(jīng)歷了各種難查的BUG之后,你會發(fā)現(xiàn),這點時間還是浪費的起。
而事實上,軟件開發(fā)一般都會有兩個版本,一個是Debug版本,一個是Release版本,只要通過宏進行控制,那么就可以在穩(wěn)定之后,不再檢查這些參數(shù)了。
但是有些重要的數(shù)據(jù),即使穩(wěn)定了,也不能放棄對它的檢查,否則一旦出現(xiàn)問題,就是災(zāi)難。
所以在檢查時,還要考慮這些檢查是否在Release版本也是需要的,即按重要性分開檢查。
為什么要檢查?檢查的意義又在哪里?
這些檢查就像是函數(shù)的護城河,保證即使參數(shù)錯誤,也不會導(dǎo)致異常問題,比如數(shù)組越界,計算出錯等。
那么我們要問了,參數(shù)怎么會錯誤,代碼都是固定死的,有經(jīng)驗的都知道,參數(shù)是保存在棧或寄存器的,怎么會錯呢?
你說內(nèi)存數(shù)據(jù)保存時有問題?保存時為1,讀出時為0?
別逗了,如果真是這樣,那還怎么玩?程序根本沒辦法跑好吧(遇到強干擾可能會出現(xiàn)這種情況,甚至可能CPU執(zhí)行流程都是亂的,最終只能重啟,這個魚鷹倒還沒遇到過)。
我們可以認(rèn)為存在RAM和FLASH的數(shù)據(jù)在存儲和讀取方面沒有問題,那么又是什么導(dǎo)致了參數(shù)出錯呢?
棧溢出
前面說過,參數(shù)有可能保存在棧里面,如果有些棧溢出了,參數(shù)被破壞也就可以理解了。(關(guān)于棧,可參考筆記《今天,你的棧溢出了嗎?》)
數(shù)組越界、野指針等指針問題
一旦越界,那么產(chǎn)生的破壞力不可想象。
所謂越界,就是修改了不屬于你的變量。比如一個數(shù)組,你操作了數(shù)組外的數(shù)據(jù)(不管是數(shù)組前面的還是數(shù)組后面的)。
而越界根據(jù)位置又可以分為三種情況。
第一種,棧(stack),比如你在棧里面申請了一個數(shù)組,越界了,那么修改的就是棧內(nèi)容。
第二種:堆(Heap)。你通過malloc申請的內(nèi)存,如果操作失誤,那么就會修改不屬于你的空間。
第三種。全局變量(data)。如果操作失誤,也會出現(xiàn)問題。
其實,越界這種問題不一定就只會修改這些單獨的區(qū)域,可能是兩個區(qū)、三個區(qū)一起修改了,畢竟指針可不管修改的地址到底屬于哪個區(qū),還有一種是野指針導(dǎo)致的異常操作,那么它修改的位置只有鬼知道了(鬼好像不懂程序)。
比如你申請了一個數(shù)組,通過傳入的參數(shù)修改數(shù)據(jù),如果不限制參數(shù)大小,你確定它不會把你數(shù)組后所有的內(nèi)存都給清零?!
如果硬要為上面三種情況劃分處理難度等級,那么最容易也最快解決的就是全局變量的修改,為什么?因為地址比較固定,而ARM內(nèi)核有神器處理這種情況,如果出現(xiàn)概率高的話,一查一個準(zhǔn),所以魚鷹都不怎么苦惱這種問題。
最難解決的是堆的修改,這種問題比棧更難找。原因就在于,內(nèi)存動態(tài)申請和釋放,可能這次修改的是這個位置,沒出現(xiàn)問題,下次修改另一個地址,就出現(xiàn)了問題,這種是最難查的。而棧的空間一般不會太大,而且他的存取都是有規(guī)律的,要稍微好查一些。
可能你會問,參數(shù)會保存在寄存器里面,那么寄存器的數(shù)據(jù)有可能被異常修改嗎?
異常修改的可能性很小,因為對于C語言而言,寄存器是透明的,用戶很難操作這個。
但是,雖然說參數(shù)傳入之后被修改的可能性很小,但是傳入前修改的可能性還是很大的,比如你傳入的參數(shù)是一個全局變量,那么這個全局變量是可能被異常修改的啊!
所以,參數(shù)檢查,是一個健壯程序必須要有的,這是防止產(chǎn)生重大問題最重要的護城河。而越早檢查出問題,那么越容易定位問題。
蝴蝶效應(yīng)大家都知道,千里之堤毀于蟻穴大家也知道,用在程序里面也是很合適的。
可能你會說,我對自己有信心,我的技術(shù)杠杠的,絕對不會出問題。
真的是這樣嗎?
第一、時間久了自己都忘了。
工作時,常常完成了一個項目,下一個項目馬上來了,如果老項目需要維護,不需要一兩年,只要一兩個月,如果你沒有參數(shù)檢查、異常處理的好習(xí)慣,一旦你修改了代碼,那么很可能因為某些疏忽,導(dǎo)致難以發(fā)現(xiàn)的BUG,而解決這些BUG的時間,比你寫這些異常處理代碼更多。
但是在你剛開始寫這份代碼的時候,因為思路清晰,考慮的比較多,有哪些異常很清楚,那么很容易寫出那些異常處理代碼。
就比如魚鷹去年寫了一份通過位綁定地址,批量配置引腳的時鐘、寄存器信息的代碼,那么今年再復(fù)用代碼的時候,因為自己的疏忽,很可能需要大量的時間解決BUG,那我寫這份代碼的意義就不存在了(寫這份代碼就是為了在標(biāo)準(zhǔn)庫中通過端口和引腳號快速配置引腳),而如果說,一旦因為疏忽導(dǎo)致的問題,程序會自動幫你檢查,那么解決問題就很快了。
第二、維護。
不管是別人維護,還是自己維護,當(dāng)項目需要更改需求時,如果因為某些疏忽,導(dǎo)致了BUG,那么解決起來費時費力,而且即使你這次解決了,難道下次還要重蹈覆轍嗎?
第三、合作開發(fā)
一個項目可能不是一個人完成的,而是多人合作。而每個人的水平有高有低,你敢說別人不會寫出有問題的代碼?你敢說自己一定不會寫出有問題的代碼?
而且即使別人沒有寫出BUG,但因為某些原因,需要修改或屏蔽你的代碼,如果你的代碼能自動提醒出這些異常,那么定位問題也就不難了。
而魚鷹為什么寫代碼的時間會比測試長,除了掌握大量的調(diào)試技巧外,就是因為在寫的時候,會考慮很多,并且這些考慮,大部分會以代碼的形式存在,少量的會以注釋或者#warning、#error 形式存在,而其中,最好的方式是代碼形式,因為它能保證程序正常運行,即使不能正常運行,也應(yīng)該打印消息以提醒用戶問題在何處。
所以,魚鷹總是很慶幸自己當(dāng)初花了不少時間去寫異常處理代碼,而這些代碼,如果需要事后彌補的話,相信花的時間會更多(定位問題、回想當(dāng)初自己如何思考、補充異常處理代碼,這些都要時間)。
編輯:黃飛
評論
查看更多