iOS開發中如何合理地製造BUG

如何合理地製造BUG

Crash掉的BUG，用程序的死證實了你的程序存在問題，你必須抓緊時間來解決程序的問題了。而沒有Crash掉的Bug，像是一個善於撒謊的人，假裝成能夠正常運轉的樣子，讓整個程序運行在一個不穩定的狀態下。雖然外表看起來好好地（沒有crash），可是裏子早就爛透了，一旦報露出問題每每是致命的，好比OpenSSL的心臟大出血。這就是前人總結的「死程序不說謊」。

Crash不可怕，可怕的是程序沒有Crash而是運行在一個不穩定的狀態下，若是程序還操做了數據，那帶來的危害將是災難性的。

因此放心的讓程序Crash掉吧，由於當他Crash掉的時候，你還有機會去修正本身的錯誤。若是沒有Crash，那就有可能要給整個程序和產品收屍了。所以合理製造「BUG」的原則之一，也是最大的原則就是：儘可能製造Crash的BUG，減小沒有Crash的BUG，若是有可能將沒有Crash掉的Bug轉換成Crash的BUG以方便查找。

NSAssert

這個應該都比較熟悉，他的名字叫作「斷言」。斷言（assertion）是指在開發期間使用的、讓程序在運行時進行自檢的代碼（一般是一個子程序或宏）。斷言爲真，則代表程序運行正常，而斷言爲假，則意味着它已經在代碼中發現了意料以外的錯誤。斷言對於大型的複雜程序或可靠性要求極高的程序來講尤爲有用。而當斷言爲假的時候，幾乎全部的系統的處理策略都是，讓程序死掉，即Crash掉。方便你知道，程序出現了問題。

斷言實際上是「防護式編程」的經常使用的手段。防護式編程的主要思想是：子程序應該不因傳入錯誤數據而被破壞，哪怕是由其餘子程序產生的錯誤數據。這種思想是將可能出現的錯誤形成的影響控制在有限的範圍內。斷言可以有效的保證數據的正確性，防止由於髒數據讓整個程序運行在不穩定的狀態下面。

關於如何使用斷言，仍是參考《代碼大全2》中「防護式編程」一章。這裏簡單的作了一點摘錄，歸納其大意：

1. 用錯誤處理代碼來處理預期會發生的情況，用斷言來處理毫不應該發生的情況。

2. 避免把須要執行的代碼放到斷言中

3. 用斷言來註解並驗證前條件和後條件

4. 對於高健壯性的代碼，應該先使用斷言再處理錯誤

5. 對來源於內部系統的可靠的數據使用斷言，而不要對外部不可靠的數據使用斷言，對於外部不可靠數據，應該使用錯誤處理代碼。 而在IOS編程中，咱們可使用NSAssert來處理斷言。好比：

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

咱們驗證myName的安全性，須要保證其不能爲空。NSAssert會檢查其內部的表達式的值，若是爲假則繼續執行程序，若是不爲假讓程序Crash掉。

每個線程都有它本身的斷言捕獲器（一個NSAssertionHanlder的實例），當斷言發生時，捕獲器會打印斷言信息和當前的類名、方法名等信息。而後拋出一個NSInternalInconsistencyException異常讓整個程序Crash掉。而且在當前線程的斷言捕獲器中執行handleFailureInMethod:object:file:lineNumber:description:以上述信息爲輸出。

當時，當程序發佈的時候，不能把斷言帶入安裝包，你不想讓程序在用戶機器上Crash掉吧。打開和關閉斷言能夠在項目設置中設置assert ,在release版本中設置了NS_BLOCK_ASSERTIONS以後斷言失效。

儘量不要用Try-Catch

並非說Try-Catch這樣的異常處理機制很差。而是，不少人在編程中，錯誤了使用了Try-Catch，把異常處理機制用在了核心邏輯中。把其當成了一個變種的GOTO使用。把大量的邏輯寫在了Catch中。弱弱的說一句，這種狀況幹嗎不用ifelse呢。

而實際狀況是，異常處理只是用戶處理軟件中出現異常的狀況。經常使用的狀況是子程序拋出錯誤，讓上層調用者知道，子程序發生了錯誤，並讓調用者使用合適的策略來處理異常。通常狀況下，對於異常的處理策略就是Crash，讓程序死掉，而且打印出堆棧信息。

而在IOS編程中，拋出錯誤的方式，每每採用更直接的方式。若是上層須要知道錯誤信息，一半會傳入一個NSError的指針的指針：

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

而可以留給異常處理的場景就極少了，因此在IOS編程中儘可能不要使用Try-Catch。

（PS：見到過使用Try-Catch來防止程序Crash的設計，若是不是無可奈何，儘可能不要使用這種策略）

儘可能將沒有Crash掉的BUG，讓它Crash掉

上面主要講的是怎麼知道Crash的「BUG」。對於合理的製造「BUG」還有一條就是儘可能把沒有Crash掉的「BUG」，讓他Crash掉。這個沒有比較靠譜的方法，靠暴力吧。好比寫一些數組越界在裏面之類的。好比那些難調的多線程BUG，想辦法讓他Crash掉吧，crash掉查找起來就比較方便了。

總之，就是抱着讓程序「死掉」的心態去編程，向死而生。

如何查找BUG

其實查找BUG這個說法，有點不太靠譜。由於BUG歷來都不須要你去找，他就在那裏，只增不減。都是BUG來找你，你不多主動去找BUG。程序死了，而後咱們就得加班加點。其實咱們找的是發生BUG的緣由。找到引起BUG的罪魁禍首。說的比較理論化一點就是：在一堆可能的緣由中，找到那些與BUG有因果性的緣由（注意，是因果性，不是相關性）。

因而解決BUG通常能夠分兩步進行：

1. 合理性假設，找到可能性最高的一系列緣由。

2. 對上面找到的緣由與BUG之間的因果性進行分析。必須肯定，這個BUG是由某個緣由引發的，並且只由改緣由引發。即肯定特定緣由是BUG的充分必要條件。 找到緣由以後，剩下的事情就比較簡單了，改代碼解決掉。

合理性假設

其實，BUG發生的緣由能夠分紅兩類：

1. 咱們本身程序的問題。

2. 系統環境，包括OS、庫、框架等的問題。 前者找到了，咱們能夠改。後者就比較無能爲力了，要麼發發牢騷，要麼email開發商，最後能不能被改掉就不得而知了。好比IOS製做framework的時候，category會報方法沒法找的異常，到如今都沒有解決掉。

固然，通常狀況下致使程序出問題的緣由的99.999999%都是咱們本身形成的。因此合理性假設第一條：

首先懷疑本身和本身的程序，其次懷疑一切

而程序的問題，其實就是開發者本身的問題。畢竟BUG是程序員的親子親孫，咱們一手創造了BUG。而之因此可以創造BUG，開發者的緣由大體有三：

知識儲備不足，好比IOS常見的空指針問題，發現不少時候就是由於對於IOS的內存管理模型不熟悉致使。

錯心大意，比較典型的就是數組越界錯誤。還有在類型轉化的時候沒注意。好比下面這個程序：

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

按道理講，這應該是個能夠正常執行的程序，可是你運行的話是個死循環。可能死循環的問題，你改了數日也沒解決。直到同事和你說array.count返回的是NSUInterge，當與無符號整形相間的時候，若是出現負值是回越界的啊。你才恍然大悟：靠，類型的問題。

邏輯錯誤

這個就是思惟方式的問題，可是也是問題最嚴重的。一旦發生，很難查找。人老是最難懷疑本身的思惟方式。好比死循環的問題，最嚴重的是函數間的循環引用，還有多線程的問題。 可是慶幸的是絕大多數的BUG都是因爲知識儲備不足和粗枝大葉形成的。因此合理性假設的第二條：

首先懷疑基礎性的緣由，好比本身知識儲備和粗枝大葉等人爲因素，經過這些緣由查找具體的問題。以後再去懷疑難處理的邏輯錯誤。 有了上面的合理性懷疑的一些基本策略，也不能缺乏一些基本的素材啊。就是常見的Crash緣由，最後咱們仍是得落地到這些具體的緣由或者代碼上，卻找與BUG的因果性聯繫。

1. 訪問了一個已經被釋放的對象，好比：NSObject * aObj = [[NSObject alloc] init]; [aObj release]; NSLog(@」%@」, aObj); 

2. 訪問數組類對象越界或插入了空對象

3. 訪問了不存在的方法

4. 字節對齊,(類型轉換錯誤)

5. 堆棧溢出

6. 多線程併發操做

7. Repeating NSTimer

合理性假設第三條：儘量的查找就有可能性的具體緣由。

因果性分析

首先必須先說明的是，咱們要找的是「因果性」而不是「相關性「。這是兩個極度被混淆的概念。並且，不少時候咱們錯誤的把相關性當成了因果性。好比，在解決一個多線程問題的時候，發現了一個數據混亂的問題，可是百思不得其解。終於，有一天你意外的給某個對象加了個鎖，數據就正常了。而後你就說這個問題是這個對象沒有枷鎖致使的。

可是，根據上述你的分析，只可以得出該對象枷鎖與否與數據異常有關係，而不能得出就是數據異常的緣由。由於你沒能證實對象加鎖是數據異常的充分必要條件，而只是使用了一個單因變量實驗，變量是枷鎖狀態，取值x=[0，1],x爲整形。而後實驗結果是枷鎖與否與數據異常呈現正相關性。

相關性：在機率論和統計學中，相關（Correlation，或稱相關係數或關聯繫數），顯示兩個隨機變量之間線性關係的強度和方向。在統計學中，相關的意義是用來衡量兩個變量相對於其相互獨立的距離。在這個廣義的定義下，有許多根據數據特色而定義的用來衡量數據相關的係數。

因果性：因果是一個事件（即「因」）和第二個事件（即「果」）之間的關係，其中後一事件被認爲是前一事件的結果。 錯誤的把相關性等價於因果性。不止是程序員，幾乎全部人常見的邏輯錯誤。爲了加深認識，能夠看一下這篇小科普：相關性 ≠ 因果性。

因果性分析的首要問題就是，別被本身的邏輯錯誤欺騙，正確的分辨出相關性和因果性之間的區別。不要把相關性等價於因果性。

以後即是因果性分析的內容了，以前一直反覆說，因果性分析的目的就是肯定特定緣由是BUG發生的充分必要條件。那麼肯定這個事情，就須要兩步：

1. 充分性證實

2. 必要性證實

關於充分性證實，這個基本上就是正常的邏輯推理。基本思路就是，可以還原出BUG出現的路徑，從緣由到BUG發生處的代碼，走了怎樣的函數調用和控制邏輯。肯定了這個基本上就可以證實充分性。通常狀況下根據Crash的堆棧信息可以，很是直接的證實充分性。

關於必要性證實，這個就比較困難了。充分性和必要性的定義以下：當命題「若A則B」爲真時，A稱爲B的充分條件，B稱爲A的必要條件。那麼必要性就是，BUG可以做爲致使BUG的緣由的緣由。這個說法比較拗口。換種說法，就是你得確認這個BUG可以解釋緣由，這個BUG就是並且只是這個緣由形成的。

只有證實了充分必要性，才能算是真正找到了BUG的緣由。