iOS開發(fā)中如何合理地制造BUG
什么是BUG，簡單點(diǎn)說就是，程序沒有按照我們預(yù)想的方式運(yùn)行。我比較喜歡把BUG分成兩類：
- Crash掉的
- 沒有Crash掉的
可能在平時的編程實(shí)踐中，往往簡單的把BUG與Crash基本等價了。而且我們很多精力也都放在解決Crash的Bug上面。而對于沒有Crash掉的BUG，似乎沒有過多的關(guān)注。但是，實(shí)際情況上那些讓人痛徹心扉的“天坑”往往是那些沒有Crash掉的BUG造成的，比如前一段時間OpenSSL心臟大出血。為什么這么說呢？且聽我慢慢道來。
如何合理地制造BUG
Crash掉的BUG，用程序的死證明了你的程序存在問題，你必須抓緊時間來解決程序的問題了。而沒有Crash掉的Bug，像是一個善于撒謊的人，偽裝成可以正常運(yùn)轉(zhuǎn)的樣子，讓整個程序運(yùn)行在一個不穩(wěn)定的狀態(tài)下。雖然外表看起來好好地（沒有crash），但是里子早就爛透了，一旦報露出問題往往是致命的，比如OpenSSL的心臟大出血。這就是前人總結(jié)的“死程序不說謊”。
Crash不可怕，可怕的是程序沒有Crash而是運(yùn)行在一個不穩(wěn)定的狀態(tài)下，如果程序還操作了數(shù)據(jù)，那帶來的危害將是災(zāi)難性的。
所以放心的讓程序Crash掉吧，因?yàn)楫?dāng)他Crash掉的時候，你還有機(jī)會去修正自己的錯誤。如果沒有Crash，那就有可能要給整個程序和產(chǎn)品收尸了。因此合理制造“BUG”的原則之一，也是最大的原則就是：盡量制造Crash的BUG，減少沒有Crash的BUG，如果有可能將沒有Crash掉的Bug轉(zhuǎn)換成Crash的BUG以方便查找。
NSAssert
這個應(yīng)該都比較熟悉，他的名字叫做“斷言”。斷言（assertion）是指在開發(fā)期間使用的、讓程序在運(yùn)行時進(jìn)行自檢的代碼（通常是一個子程序或宏）。斷言為真，則表明程序運(yùn)行正常，而斷言為假，則意味著它已經(jīng)在代碼中發(fā)現(xiàn)了意料之外的錯誤。斷言對于大型的復(fù)雜程序或可靠性要求極高的程序來說尤其有用。而當(dāng)斷言為假的時候，幾乎所有的系統(tǒng)的處理策略都是，讓程序死掉，即Crash掉。方便你知道，程序出現(xiàn)了問題。
斷言其實(shí)是“防御式編程”的常用的手段。防御式編程的主要思想是：子程序應(yīng)該不因傳入錯誤數(shù)據(jù)而被破壞，哪怕是由其他子程序產(chǎn)生的錯誤數(shù)據(jù)。這種思想是將可能出現(xiàn)的錯誤造成的影響控制在有限的范圍內(nèi)。斷言能夠有效的保證數(shù)據(jù)的正確性，防止因?yàn)榕K數(shù)據(jù)讓整個程序運(yùn)行在不穩(wěn)定的狀態(tài)下面。
關(guān)于如何使用斷言，還是參考《代碼大全2》中“防御式編程”一章。這里簡單的做了一點(diǎn)摘錄，概括其大意：
- 用錯誤處理代碼來處理預(yù)期會發(fā)生的狀況，用斷言來處理絕不應(yīng)該發(fā)生的狀況。
- 避免把需要執(zhí)行的代碼放到斷言中
- 用斷言來注解并驗(yàn)證前條件和后條件
- 對于高健壯性的代碼，應(yīng)該先使用斷言再處理錯誤
- 對來源于內(nèi)部系統(tǒng)的可靠的數(shù)據(jù)使用斷言，而不要對外部不可靠的數(shù)據(jù)使用斷言，對于外部不可靠數(shù)據(jù)，應(yīng)該使用錯誤處理代碼。 而在IOS編程中，我們可以使用NSAssert來處理斷言。比如：
- - (void)printMyName:(NSString *)myName
- {
- NSAssert(myName == nil, @"名字不能為空！");
- NSLog(@"My name is %@.",myName);
- }
我們驗(yàn)證myName的安全性，需要保證其不能為空。NSAssert會檢查其內(nèi)部的表達(dá)式的值，如果為假則繼續(xù)執(zhí)行程序，如果不為假讓程序Crash掉。
每一個線程都有它自己的斷言捕獲器（一個NSAssertionHanlder的實(shí)例），當(dāng)斷言發(fā)生時，捕獲器會打印斷言信息和當(dāng)前的類名、方法名等信息。然后拋出一個NSInternalInconsistencyException異常讓整個程序Crash掉。并且在當(dāng)前線程的斷言捕獲器中執(zhí)行handleFailureInMethod:object:file:lineNumber:description:以上述信息為輸出。
當(dāng)時，當(dāng)程序發(fā)布的時候，不能把斷言帶入安裝包，你不想讓程序在用戶機(jī)器上Crash掉吧。打開和關(guān)閉斷言可以在項(xiàng)目設(shè)置中設(shè)置assert ,在release版本中設(shè)置了NS_BLOCK_ASSERTIONS之后斷言失效。
盡可能不要用Try-Catch
并不是說Try-Catch這樣的異常處理機(jī)制不好。而是，很多人在編程中，錯誤了使用了Try-Catch，把異常處理機(jī)制用在了核心邏輯中。把其當(dāng)成了一個變種的GOTO使用。把大量的邏輯寫在了Catch中。弱弱的說一句，這種情況干嘛不用ifelse呢。
而實(shí)際情況是，異常處理只是用戶處理軟件中出現(xiàn)異常的情況。常用的情況是子程序拋出錯誤，讓上層調(diào)用者知道，子程序發(fā)生了錯誤，并讓調(diào)用者使用合適的策略來處理異常。一般情況下，對于異常的處理策略就是Crash，讓程序死掉，并且打印出堆棧信息。
而在IOS編程中，拋出錯誤的方式，往往采用更直接的方式。如果上層需要知道錯誤信息，一半會傳入一個NSError的指針的指針：
- - (void) doSomething:(NSError* __autoreleasing*)error
- {
- ...
- if(error != NULL)
- {
- *error = [NSError new];
- }
- ....
- }
而能夠留給異常處理的場景就極少了，所以在IOS編程中盡量不要使用Try-Catch。
（PS：見到過使用Try-Catch來防止程序Crash的設(shè)計(jì)，如果不是迫不得已，盡量不要使用這種策略）
盡量將沒有Crash掉的BUG，讓它Crash掉
上面主要講的是怎么知道Crash的“BUG”。對于合理的制造“BUG”還有一條就是盡量把沒有Crash掉的“BUG”，讓他Crash掉。這個沒有比較靠譜的方法，靠暴力吧。比如寫一些數(shù)組越界在里面之類的。比如那些難調(diào)的多線程BUG，想辦法讓他Crash掉吧，crash掉查找起來就比較方便了。
總之，就是抱著讓程序“死掉”的心態(tài)去編程，向死而生。
如何查找BUG
其實(shí)查找BUG這個說法，有點(diǎn)不太靠譜。因?yàn)锽UG從來都不需要你去找，他就在那里，只增不減。都是BUG來找你，你很少主動去找BUG。程序死了，然后我們就得加班加點(diǎn)。其實(shí)我們找的是發(fā)生BUG的原因。找到引發(fā)BUG的罪魁禍?zhǔn)?。說的比較理論化一點(diǎn)就是：在一堆可能的原因中，找到那些與BUG有因果性的原因（注意，是因果性，不是相關(guān)性）。
于是解決BUG一般可以分兩步進(jìn)行：
- 合理性假設(shè)，找到可能性最高的一系列原因。
- 對上面找到的原因與BUG之間的因果性進(jìn)行分析。必須確定，這個BUG是由某個原因引起的，而且只由改原因引起。即確定特定原因是BUG的充分必要條件。 找到原因之后，剩下的事情就比較簡單了，改代碼解決掉。
合理性假設(shè)
其實(shí)，BUG發(fā)生的原因可以分成兩類：
- 我們自己程序的問題。
- 系統(tǒng)環(huán)境，包括OS、庫、框架等的問題。 前者找到了，我們可以改。后者就比較無能為力了，要么發(fā)發(fā)牢騷，要么email開發(fā)商，最后能不能被改掉就不得而知了。比如IOS制作framework的時候，category會報方法無法找的異常，到現(xiàn)在都沒有解決掉。
當(dāng)然，一般情況下導(dǎo)致程序出問題的原因的99.999999%都是我們自己造成的。所以合理性假設(shè)第一條：
首先懷疑自己和自己的程序，其次懷疑一切
而程序的問題，其實(shí)就是開發(fā)者自己的問題。畢竟BUG是程序員的親子親孫，我們一手創(chuàng)造了BUG。而之所以能夠創(chuàng)造BUG，開發(fā)者的原因大致有三：
知識儲備不足，比如IOS常見的空指針問題，發(fā)現(xiàn)很多時候就是因?yàn)閷τ贗OS的內(nèi)存管理模型不熟悉導(dǎo)致。
錯心大意，比較典型的就是數(shù)組越界錯誤。還有在類型轉(zhuǎn)化的時候沒注意。比如下面這個程序：
- //array.count = 9
- for (int i = 100; array.count - (unsigned int)i > 10 ; )
- {
- i++
- .....
- }
按道理講，這應(yīng)該是個可以正常執(zhí)行的程序，但是你運(yùn)行的話是個死循環(huán)?？赡芩姥h(huán)的問題，你改了很多天也沒解決。直到同事和你說array.count返回的是NSUInterge，當(dāng)與無符號整形相間的時候，如果出現(xiàn)負(fù)值是回越界的啊。你才恍然大悟：靠，類型的問題。
邏輯錯誤
這個就是思維方式的問題，但是也是問題最嚴(yán)重的。一旦發(fā)生，很難查找。人總是最難懷疑自己的思維方式。比如死循環(huán)的問題，最嚴(yán)重的是函數(shù)間的循環(huán)引用，還有多線程的問題。 但是慶幸的是絕大多數(shù)的BUG都是由于知識儲備不足和粗心大意造成的。所以合理性假設(shè)的第二條：
首先懷疑基礎(chǔ)性的原因，比如自己知識儲備和粗心大意等人為因素，通過這些原因查找具體的問題。之后再去懷疑難處理的邏輯錯誤。 有了上面的合理性懷疑的一些基本策略，也不能缺少一些基本的素材啊。就是常見的Crash原因，最后我們還是得落地到這些具體的原因或者代碼上，卻找與BUG的因果性聯(lián)系。
- 訪問了一個已經(jīng)被釋放的對象，比如：NSObject * aObj = [[NSObject alloc] init]; [aObj release]; NSLog(@”%@”, aObj);
- 訪問數(shù)組類對象越界或插入了空對象
- 訪問了不存在的方法
- 字節(jié)對齊,(類型轉(zhuǎn)換錯誤)
- 堆棧溢出
- 多線程并發(fā)操作
- Repeating NSTimer
合理性假設(shè)第三條：盡可能的查找就有可能性的具體原因。
因果性分析
首先必須先說明的是，我們要找的是“因果性”而不是“相關(guān)性“。這是兩個極度被混淆的概念。而且，很多時候我們錯誤的把相關(guān)性當(dāng)成了因果性。比如，在解決一個多線程問題的時候，發(fā)現(xiàn)了一個數(shù)據(jù)混亂的問題，但是百思不得其解。終于，有一天你意外的給某個對象加了個鎖，數(shù)據(jù)就正常了。然后你就說這個問題是這個對象沒有枷鎖導(dǎo)致的。
但是，根據(jù)上述你的分析，只能夠得出該對象枷鎖與否與數(shù)據(jù)異常有關(guān)系，而不能得出就是數(shù)據(jù)異常的原因。因?yàn)槟銢]能證明對象加鎖是數(shù)據(jù)異常的充分必要條件，而只是使用了一個單因變量實(shí)驗(yàn)，變量是枷鎖狀態(tài)，取值x=[0，1],x為整形。然后實(shí)驗(yàn)結(jié)果是枷鎖與否與數(shù)據(jù)異常呈現(xiàn)正相關(guān)性。
相關(guān)性：在概率論和統(tǒng)計(jì)學(xué)中，相關(guān)（Correlation，或稱相關(guān)系數(shù)或關(guān)聯(lián)系數(shù)），顯示兩個隨機(jī)變量之間線性關(guān)系的強(qiáng)度和方向。在統(tǒng)計(jì)學(xué)中，相關(guān)的意義是用來衡量兩個變量相對于其相互獨(dú)立的距離。在這個廣義的定義下，有許多根據(jù)數(shù)據(jù)特點(diǎn)而定義的用來衡量數(shù)據(jù)相關(guān)的系數(shù)。
因果性：因果是一個事件（即“因”）和第二個事件（即“果”）之間的關(guān)系，其中后一事件被認(rèn)為是前一事件的結(jié)果。 錯誤的把相關(guān)性等價于因果性。不止是程序員，幾乎所有人常見的邏輯錯誤。為了加深認(rèn)識，可以看一下這篇小科普：相關(guān)性 ≠ 因果性。
因果性分析的首要問題就是，別被自己的邏輯錯誤欺騙，正確的分辨出相關(guān)性和因果性之間的區(qū)別。不要把相關(guān)性等價于因果性。
之后便是因果性分析的內(nèi)容了，之前一直反復(fù)說，因果性分析的目的就是確定特定原因是BUG發(fā)生的充分必要條件。那么確定這個事情，就需要兩步：
- 充分性證明
- 必要性證明
關(guān)于充分性證明，這個基本上就是正常的邏輯推理?；舅悸肪褪牵軌蜻€原出BUG出現(xiàn)的路徑，從原因到BUG發(fā)生處的代碼，走了怎樣的函數(shù)調(diào)用和控制邏輯。確定了這個基本上就能夠證明充分性。一般情況下根據(jù)Crash的堆棧信息能夠，非常直接的證明充分性。
關(guān)于必要性證明，這個就比較困難了。充分性和必要性的定義如下：當(dāng)命題“若A則B”為真時，A稱為B的充分條件，B稱為A的必要條件。那么必要性就是，BUG能夠作為導(dǎo)致BUG的原因的原因。這個說法比較拗口。換種說法，就是你得確認(rèn)這個BUG能夠解釋原因，這個BUG就是而且只是這個原因造成的。
只有證明了充分必要性，才能算是真正找到了BUG的原因。
