什么是BUG，簡(jiǎn)單點(diǎn)說就是，程序沒有按照我們預(yù)想的方式運(yùn)行。我比較喜歡把BUG分成兩類：

1. Crash掉的

2. 沒有Crash掉的

可能在平時(shí)的編程實(shí)踐中，往往簡(jiǎn)單的把BUG與Crash基本等價(jià)了。而且我們很多精力也都放在解決Crash的Bug上面。而對(duì)于沒有Crash掉的BUG，似乎沒有過多的關(guān)注。但是，實(shí)際情況上那些讓人痛徹心扉的“天坑”往往是那些沒有Crash掉的BUG造成的，比如前一段時(shí)間OpenSSL心臟大出血。為什么這么說呢？且聽我慢慢道來。

如何合理的制造BUG

Crash掉的BUG，用程序的死證明了你的程序存在問題，你必須抓緊時(shí)間來解決程序的問題了。而沒有Crash掉的Bug，像是一個(gè)善于撒謊的人，偽裝成可以正常運(yùn)轉(zhuǎn)的樣子，讓整個(gè)程序運(yùn)行在一個(gè)不穩(wěn)定的狀態(tài)下。雖然外表看起來好好地（沒有crash），但是里子早就爛透了，一旦報(bào)露出問題往往是致命的，比如OpenSSL的心臟大出血。這就是前人總結(jié)的“死程序不說謊”。

Crash不可怕，可怕的是程序沒有Crash而是運(yùn)行在一個(gè)不穩(wěn)定的狀態(tài)下，如果程序還操作了數(shù)據(jù)，那帶來的危害將是災(zāi)難性的。

所以放心的讓程序Crash掉吧，因?yàn)楫?dāng)他Crash掉的時(shí)候，你還有機(jī)會(huì)去修正自己的錯(cuò)誤。如果沒有Crash，那就有可能要給整個(gè)程序和產(chǎn)品收尸了。因此合理制造“BUG”的原則之一，也是最大的原則就是：盡量制造Crash的BUG，減少?zèng)]有Crash的BUG，如果有可能將沒有Crash掉的Bug轉(zhuǎn)換成Crash的BUG以方便查找。

NSAssert

這個(gè)應(yīng)該都比較熟悉，他的名字叫做“斷言”。斷言（assertion）是指在開發(fā)期間使用的、讓程序在運(yùn)行時(shí)進(jìn)行自檢的代碼（通常是一個(gè)子程序或宏）。斷言為真，則表明程序運(yùn)行正常，而斷言為假，則意味著它已經(jīng)在代碼中發(fā)現(xiàn)了意料之外的錯(cuò)誤。斷言對(duì)于大型的復(fù)雜程序或可靠性要求極高的程序來說尤其有用。而當(dāng)斷言為假的時(shí)候，幾乎所有的系統(tǒng)的處理策略都是，讓程序死掉，即Crash掉。方便你知道，程序出現(xiàn)了問題。

斷言其實(shí)是“防御式編程”的常用的手段。防御式編程的主要思想是：子程序應(yīng)該不因傳入錯(cuò)誤數(shù)據(jù)而被破壞，哪怕是由其他子程序產(chǎn)生的錯(cuò)誤數(shù)據(jù)。這種思想是將可能出現(xiàn)的錯(cuò)誤造成的影響控制在有限的范圍內(nèi)。斷言能夠有效的保證數(shù)據(jù)的正確性，防止因?yàn)榕K數(shù)據(jù)讓整個(gè)程序運(yùn)行在不穩(wěn)定的狀態(tài)下面。

關(guān)于如何使用斷言，還是參考《代碼大全2》中“防御式編程”一章。這里簡(jiǎn)單的做了一點(diǎn)摘錄，概括其大意：

1. 用錯(cuò)誤處理代碼來處理預(yù)期會(huì)發(fā)生的狀況，用斷言來處理絕不應(yīng)該發(fā)生的狀況。
2. 避免把需要執(zhí)行的代碼放到斷言中
3. 用斷言來注解并驗(yàn)證前條件和后條件
4. 對(duì)于高健壯性的代碼，應(yīng)該先使用斷言再處理錯(cuò)誤
5. 對(duì)來源于內(nèi)部系統(tǒng)的可靠的數(shù)據(jù)使用斷言，而不要對(duì)外部不可靠的數(shù)據(jù)使用斷言，對(duì)于外部不可靠數(shù)據(jù)，應(yīng)該使用錯(cuò)誤處理代碼。

而在IOS編程中，我們可以使用NSAssert來處理斷言。比如：

- (void)printMyName:(NSString *)myName    
{    
    NSAssert(myName == nil, @"名字不能為空！");    
    NSLog(@"My name is %@.",myName);    
}  

我們驗(yàn)證myName的安全性，需要保證其不能為空。NSAssert會(huì)檢查其內(nèi)部的表達(dá)式的值，如果為假則繼續(xù)執(zhí)行程序，如果不為假讓程序Crash掉。

每一個(gè)線程都有它自己的斷言捕獲器（一個(gè)NSAssertionHanlder的實(shí)例），當(dāng)斷言發(fā)生時(shí)，捕獲器會(huì)打印斷言信息和當(dāng)前的類名、方法名等信息。然后拋出一個(gè)NSInternalInconsistencyException異常讓整個(gè)程序Crash掉。并且在當(dāng)前線程的斷言捕獲器中執(zhí)行handleFailureInMethod:object:file:lineNumber:description:以上述信息為輸出。

當(dāng)時(shí)，當(dāng)程序發(fā)布的時(shí)候，不能把斷言帶入安裝包，你不想讓程序在用戶機(jī)器上Crash掉吧。打開和關(guān)閉斷言可以在項(xiàng)目設(shè)置中設(shè)置：

在release版本中設(shè)置了NS_BLOCK_ASSERTIONS之后斷言失效。

盡可能不要用Try-Catch

并不是說Try-Catch這樣的異常處理機(jī)制不好。而是，很多人在編程中，錯(cuò)誤了使用了Try-Catch，把異常處理機(jī)制用在了核心邏輯中。把其當(dāng)成了一個(gè)變種的GOTO使用。把大量的邏輯寫在了Catch中。弱弱的說一句，這種情況干嘛不用ifelse呢。

而實(shí)際情況是，異常處理只是用戶處理軟件中出現(xiàn)異常的情況。常用的情況是子程序拋出錯(cuò)誤，讓上層調(diào)用者知道，子程序發(fā)生了錯(cuò)誤，并讓調(diào)用者使用合適的策略來處理異常。一般情況下，對(duì)于異常的處理策略就是Crash，讓程序死掉，并且打印出堆棧信息。

而在IOS編程中，拋出錯(cuò)誤的方式，往往采用更直接的方式。如果上層需要知道錯(cuò)誤信息，一半會(huì)傳入一個(gè)NSError的指針的指針：

- (void) doSomething:(NSError* __autoreleasing*)error  
{  
    ...  
    if(error != NULL)  
    {  
        *error = [NSError new];  
    }  
    ....  
}  

而能夠留給異常處理的場(chǎng)景就極少了，所以在IOS編程中盡量不要使用Try-Catch。

（PS：見到過使用Try-Catch來防止程序Crash的設(shè)計(jì)，如果不是迫不得已，盡量不要使用這種策略）

盡量將沒有Crash掉的BUG，讓它Crash掉

上面主要講的是怎么知道Crash的“BUG”。對(duì)于合理的制造“BUG”還有一條就是盡量把沒有Crash掉的“BUG”，讓他Crash掉。這個(gè)沒有比較靠譜的方法，靠暴力吧。比如寫一些數(shù)組越界在里面之類的。比如那些難調(diào)的多線程BUG，想辦法讓他Crash掉吧，crash掉查找起來就比較方便了。

總之，就是抱著讓程序“死掉”的心態(tài)去編程，向死而生。

如何查找BUG

其實(shí)查找BUG這個(gè)說法，有點(diǎn)不太靠譜。因?yàn)锽UG從來都不需要你去找，他就在那里，只增不減。都是BUG來找你，你很少主動(dòng)去找BUG。程序死了，然后我們就得加班加點(diǎn)。其實(shí)我們找的是發(fā)生BUG的原因。找到引發(fā)BUG的罪魁禍?zhǔn)?。說的比較理論化一點(diǎn)就是：在一堆可能的原因中，找到那些與BUG有因果性的原因（注意，是因果性，不是相關(guān)性）。

于是解決BUG一般可以分兩步進(jìn)行：

1. 合理性假設(shè)，找到可能性最高的一系列原因。

2. 對(duì)上面找到的原因與BUG之間的因果性進(jìn)行分析。必須確定，這個(gè)BUG是由某個(gè)原因引起的，而且只由改原因引起。即確定特定原因是BUG的充分必要條件。

找到原因之后，剩下的事情就比較簡(jiǎn)單了，改代碼解決掉。

#p#

合理性假設(shè)

其實(shí)，BUG發(fā)生的原因可以分成兩類：

1. 我們自己程序的問題。

2. 系統(tǒng)環(huán)境，包括OS、庫(kù)、框架等的問題。

前者找到了，我們可以改。后者就比較無能為力了，要么發(fā)發(fā)牢騷，要么email開發(fā)商，最后能不能被改掉就不得而知了。比如IOS制作framework的時(shí)候，category會(huì)報(bào)方法無法找的異常，到現(xiàn)在都沒有解決掉。

當(dāng)然，一般情況下導(dǎo)致程序出問題的原因的99.999999%都是我們自己造成的。所以合理性假設(shè)第一條：

首先懷疑自己和自己的程序，其次懷疑一切。

而程序的問題，其實(shí)就是開發(fā)者自己的問題。畢竟BUG是程序員的親子親孫，我們一手創(chuàng)造了BUG。而之所以能夠創(chuàng)造BUG，開發(fā)者的原因大致有三：

1. 知識(shí)儲(chǔ)備不足，比如IOS常見的空指針問題，發(fā)現(xiàn)很多時(shí)候就是因?yàn)閷?duì)于IOS的內(nèi)存管理模型不熟悉導(dǎo)致。

2. 錯(cuò)心大意，比較典型的就是數(shù)組越界錯(cuò)誤。還有在類型轉(zhuǎn)化的時(shí)候沒注意。比如下面這個(gè)程序：

//array.count = 9  
for (int i = 100; array.count - (unsigned int)i > 10 ; )  
{  
    i++  
    .....  
} 

首先懷疑基礎(chǔ)性的原因，比如自己知識(shí)儲(chǔ)備和粗心大意等人為因素，通過這些原因查找具體的問題。之后再去懷疑難處理的邏輯錯(cuò)誤。

相關(guān)性：在概率論和統(tǒng)計(jì)學(xué)中，相關(guān)（Correlation，或稱相關(guān)系數(shù)或關(guān)聯(lián)系數(shù)），顯示兩個(gè)隨機(jī)變量之間線性關(guān)系的強(qiáng)度和方向。在統(tǒng)計(jì)學(xué)中，相關(guān)的意義是用來衡量?jī)蓚€(gè)變量相對(duì)于其相互獨(dú)立的距離。在這個(gè)廣義的定義下，有許多根據(jù)數(shù)據(jù)特點(diǎn)而定義的用來衡量數(shù)據(jù)相關(guān)的系數(shù)。  

因果性：因果是一個(gè)事件（即“因”）和第二個(gè)事件（即“果”）之間的關(guān)系，其中后一事件被認(rèn)為是前一事件的結(jié)果。