程式設計是最好的邏輯能力訓練方法！ - thoughtbot

類推推理
這是我最喜歡的方法之一！類推推理是一個三步過程：

1. 將您的難題轉化為等效的難題（稱為 模擬）。
2. 解決簡單的問題。
3. 將簡單的解決方案轉換為針對您的難題的解決方案。

在類比除錯過程中，一種特別有用的方法是將錯誤減少到 最簡單的形式。在您的上下文中，“最小”的含義可能並不總是很明顯。沒關係。您可以一次慢慢地消除一些複雜性，同時確認該錯誤仍然存​​在。最終，您將剩下一小段程式碼。現在應該更容易找到導致錯誤的原因。對於整個問題，解決方案可能是相同的。
當處理較大系統中的錯誤而不是單個檔案中的錯誤時，這樣做可能會更困難，因為此類錯誤通常是由多個元件之間的互動產生的 。假設您在新增影像處理gem之後注意到了Rails應用程式中的損壞行為。Ruby壞了嗎？您配置不正確嗎？您現有的其他一些程式碼是否與新的gem不相容？
您如何簡化這個問題？一種方法可能是生成全新的空白Rails應用程式並新增可疑的gem。如果問題仍然存在，您現在可以除錯一個小得多的應用程式。找到解決方案後，可以將其移植回您的真實應用程式。
除了簡化現有上下文之外，類比還允許您將錯誤轉移到共享一些相似之處並且可以更好地進行除錯的其他上下文中。
 

排除法
有時，消除錯誤答案比找到正確答案要容易。消除過程屬於歸納推理類別。
在除錯中，這種方法的一種特別有用的形式是二進位制搜尋。這個想法是您進行了一系列實驗來驗證錯誤是否是由特定的程式碼段引起的。設計實驗時，無論結果如何，您都可以消除大約一半的可能性。不斷重複，直到找到錯誤的根源。
儘管名字花哨，但可以很簡單地完成。例如，我正在嘗試查詢特定檔案中發生的錯誤。我可以使用註釋或條件語句來阻止一半檔案執行。我還能重現該錯誤嗎？如果是這樣，那麼我知道該錯誤在活動的另外一半檔案中。如果不是，它必須位於檔案的非活動部分。無論哪種方式，我都消除了一半的可能性，並且更接近於發現錯誤的來源。

許多程式不只是一個又一個線性的指令集。我們有條件和分支邏輯，導致流看起來更像樹而不是列表。我們仍然可以使用二進位制搜尋方法。與其使用“將列表分成兩半”的思維模型，不如從樹上修剪樹枝方面進行思考。您可以消除的每個分支都縮小了繼續尋找錯誤來源所需的區域。

二進位制搜尋不僅可以發現空間中的錯誤，還可以及時發現錯誤！git bisect命令使您可以在git歷史上使用相同的方法來有效地找出何時引入了特定的錯誤。
 

演繹推理
人們通常在談論“邏輯”或“推理”時會想到這些。除錯時，我們始終在頭腦中進行此操作。給定一系列起始事實（稱為前提），我們構建了一個邏輯鏈以得出結論。可能看起來像：

1. 鑑於在驗證唯一性約束時Postgres會引發重複的鍵錯誤
2. 鑑於唯一性約束違規僅發生在INSERT或UPDATE 語句上
3. 鑑於唯一的資料庫寫入發生在CreateOrderService 物件中
4. 因此，錯誤必然在CreateOrderService物件中發生。

duplicate_error ⇒ index_violation
index_volation  ⇒ db_write
db_write        ⇒ create_order_invoked

這裡特別令人關注的是傳遞屬性。它宣告瞭if.then.then的長鏈，例如x ⇒ y ⇒ z可以簡化為一個if..then x ⇒ z。在上面的示例中，這意味著：

duplicate_error ⇒ create_order_invoked

矛盾證明
在拉丁語短語中矛盾證明也稱為“ reducio ad absurdum ”，意思是“減少到荒謬”。這是演繹推理的一種變體，但是不是去嘗試證明事實是正確的，而是試圖證明它是相反的，是錯誤的。
該過程通常如下所示：
選擇一個您想證明是正確的假設。現在，假設相反的說法是正確的。使用演繹推理從相反的假設中得出合理的結論。得出一個不可能或荒謬的結論。
目的是得出不可能正確的結論（矛盾）。因為它不能成立，所以您的相反假設不能成立，因此原始假設必須成立。用命題邏輯表示法：

P ⇒ Q
¬Q
∴ ¬P

1. 鑑於資料，我們試圖儲存與現有資料重複的資料
2. 鑑於我們的資料庫具有唯一索引
3. 鑑於將重複資料儲存到資料庫會導致唯一索引異常
4. 鑑於我們沒有看到唯一的索引異常
5. 假設錯誤發生在資料庫中（我們的相反結論）
6. 因此，我們的資料庫不強制執行唯一索引（矛盾）

歸納推理
當我們看一堆具體示例並嘗試推匯出更廣泛的原理時，將使用歸納推理。在除錯中通常是這種情況。我們並非總有一套“真相”可以作為推理依據。相反，我們只有：“在情況X中，發生這種奇怪的行為，但在情況Y中，發生了另一種奇怪的行為”。
有更多的樣本案例可以進行推理特別有用。因此，我們嘗試在本地重現問題。我們更改一些輸入，然後看它如何影響結果。我們做很多筆記。我們甚至可能在生產中累積日誌。然後，我們嘗試檢測模式。
17世紀的科學名稱是“自然哲學”，這並非毫無道理。一旦我們認為我們看到了一些模式，我們就會嘗試證明我們的直覺是錯誤的。為此，我們可以進行建議的修復，然後嘗試手動重現該錯誤。我們還可以新增一些自動化測試用例，以檢查觸發問題的一系列已知方法。如果我們始終無法透過更改觸發該錯誤，則我們的修復很可能是正確的。
請注意，與科學一樣，歸納推理並不能證明 任何東西。相反，它是給定我們可以訪問的方案的最佳解決方案的最佳近似值。可能有一些我們未曾考慮過的極端情況。我們的“解決方案”可能只是掩蓋了症狀，而沒有解決根本問題。最終，我們可能會得到更多表明我們錯了的示例案例。
我在一段程式碼中丟擲了很多不同的資料，然後看它們如何反應。我甚至可以對程式碼本身進行一堆半隨機的更改，然後看看它如何改變結果。我們的目標不是要找到解決方案，而是要生成一系列示例案例，以便我有足夠的資料點來開始觀察模式。
 

謬論謬誤
當我們探索每種型別的推理時，總是存在陷阱，推理會錯誤地將我們引向錯誤的道路。但是，僅僅因為您的推理存在缺陷並不一定意味著您的結論是錯誤的。這就是謬論謬誤。有時候你會很幸運。在其他時候，即使您用來證明其合理性的邏輯是錯誤的，您的直覺也會引導您找到正確的解決方案。
始終驗證您的假設，前提和結論！
 

總結
這裡的推理形式並非彼此排斥。在典型的除錯會話中，您可能希望將它們全部一起使用。實際上，即使閱讀本文，您可能也認為所描述的某些技術來自其他部分的推理方法。
我們直觀地使用所有這些推理方法，並且每天進行除錯時都會使用更多方法。但是，對我們使用的方法有一個清晰的瞭解，可以使我們以更加結構化的方式來尋求解決方案，並且避免四處走動。知道我們正在使用的技術的陷阱也可以使我們保持警惕並避免某些邏輯上的死衚衕。
 
這篇文章是我們正在進行的2021年除錯系列的一部分。