寫一天程式碼，找半天bug？那還用說，肯定是你程式設計能力出了問題。

程式碼

產生程式碼型別的bug，一般是自己編碼不夠規範，或者不夠嚴謹導致的。要不怎麼說良好的程式碼書寫習慣，是判定一個程式設計師是否優秀的呢。

這類bug的出現，絕對是最頭疼的，而且往往出現的bug非常奇葩。想要猜出這類bug，需要結合更多的資訊，不如log、場景、時機、資料等等，還需要一點經驗。

產生這種bug，真的非常頭疼，絕大部分情況下寫“寫一天程式碼，找半天bug”就是源於此。所以，最佳化一下自己的程式設計習慣吧。

策略

有一種型別的bug，就是自己的策略出了問題，自身程式碼設計有缺陷。這說明你的程式碼區域性，或者全域性構造能力出了問題。

這類bug，功能對映到的程式碼設計有缺陷，猜這類bug也不簡單。要找這類bug，要回想自己整體的設計似乎，或者根據bug發生的場景、時機，推算可能存在錯誤的設計思路。

悲催的是，如果存在很大的錯誤，那基本上就要重新調整了，會很痛苦。

以上兩種情況，就是我們說的，程式設計師的程式設計能力出現了問題。另外還有一種原因：

業務

對業務流程、需求邏輯的理解，或者業務程式碼設計出現偏差，都會導致出現業務型別的bug。

這類bug，相對而言比較好解決，要麼就是文案錯誤、資訊空缺、要麼就是集合元素缺失等等。重新理解業務邏輯，比較好猜出問題所在。

所以，要想不出現“寫一天程式碼，改半天bug”的情況，就儘量不要出現程式碼型別的bug，少出現策略型別的bug，業務型別的稍微多些。當然bug還是越少越好……

建立自己的bug庫

要想快速找到bug，必須建立自己的bug庫，這裡所說的庫，不是說做做筆記什麼的，而是對各種bug理解認知之後的集合。

你要明白，一個人在開發過程中，遇到bug很侷限的，所以，你最好和你的同事組隊。當同事出現bug，如果你不是非常忙，最好幫他參謀參謀，這是擴大自己bug庫的好時機。

除了自己的bug和同事的bug外， 還有很多bug是我們不熟悉的。 當自己的bug庫有了一定的積累， 定位bug有了一定的經驗和心得後，可以去逛逛論壇、交流群、部落格等，見識見識別人的疑難雜症和解決方案， 這會有助於提高自己bug定位能力和解決能力。

如果能有上述或類似的一些習慣，我相信用不了多久， 你們程式碼中的bug會越來越少，定位bug也將會輕車熟路， 個人能力會得到很大的提升。

如果從平均時間的角度考慮，寫一天程式碼排錯半天，如果最後交的程式碼缺陷很少，說明你已經很很NB了！

對於有經驗的程式設計師，程式碼寫完，跑起來，語法錯誤是不會太多的，有問題的一般是邏輯及細節，記憶體，物件，效能指標等，任何地方出問題，都應該歸到“bug”去，不是說程式跑起來就OK了，解決這些問題其實比寫程式的時間多，有些程式甚至寫程式碼的時間並不多，除錯才佔時間大頭。

我覺得還是程式設計經驗不足的表現。因為寫程式碼時，當你把每個程式碼模組，每個分層都分清楚，理清楚再動手，就可以達到事半功倍的效果。每個程式設計師都不敢保證的說出他寫的程式碼沒有bug。關於找半天bug這事，只能說該名程式設計師除錯程式碼的能力不足。每個人都是從不熟悉到熟悉的過程走的，所以，努力加油，讓自己變的強大。

所謂找BUG是指做單體測試和除錯的時間吧，這個時間是編碼時間的1-2倍比較合理，如果只有一半，程式設計能力就有點讓人懷疑了。即便是測試覆蓋率只需達到C0水平，測試程式碼的數量也會和處理程式碼的數量相當。更不用說C1，C2以及更高水平了。順便科普一下，所謂C0~C4是指測試時跑過的程式碼覆蓋率，C0是指每行程式碼都跑到了，C1是指每個分支都跑到了。C2/C3是指每個邏輯判斷條件都跑到了。C4的級別最高，是指所有可能的路徑都跑到了。

這款視覺化神器查詢Bug更容易——Anteater追蹤程式執行過程，讓Bug定位更迅速

程式碼除錯一直是讓廣大程式設計師頭疼不已的工作，新人尤其容易中招。最讓程式設計師們抓狂的情況莫過於程式沒有報錯，輸出的結果卻不符合預期，如果面對的是一個冗長複雜的程式，則更是無從下手。

程式除錯的一種常見做法是手動檢測程式，收集可疑變數x（下圖第一行）並打印出x的值，透過觀察x值來發現bug，但這種方法本身很容易出錯；另一種常見的做法是設斷點除錯（下圖第二行），使用偵錯程式自動停止程式執行，並單獨檢視x每次的賦值，但斷點除錯往往只能逐次提供一個小的值檢視，不方便觀察分析。

已有的大部分視覺化除錯工具都有一個明顯的缺點：缺少變數和表示式的全域性值檢視，而Anteater這個用於跟蹤和探索程式執行的互動式視覺化系統則克服了這個困難。Anteater能夠自動檢測原始碼，捕獲程式執行的行為以及使用者指定的變數和表示式，然後透過互動式視覺化呈現程式執行的資訊。

Antater能自動插入程式碼，跟蹤變數及其執行結構的上下文。它向程式設計師提供了互動式視覺化功能，並提供了值的全域性檢視，從而可以輕鬆地檢測錯誤值並進行互動；縮小視覺化範圍，從而可以檢查特定的值，更容易發現bug。

下圖展示了Anteater系統的工作流程。首先，使用者使用Anteater介面選擇要跟蹤的變數，定義跟蹤規範。這個跟蹤規範與原始碼一起，透過Web介面傳送到Python後端。然後，Anteater跟蹤程式，檢測原始碼，以收集執行資訊以及指定的值。下圖右側顯示了該系統的簡化版本，在對程式碼進行檢測之後，使用python來建立程式跟蹤。這個跟蹤透過Web介面傳回到Anteater前端，進行視覺化並呈現給使用者。

Anteater可提供跟蹤變數的介面。比如，在下面的Python程式碼中，使用者可以選擇想進行跟蹤的變數和表示式，右鍵單擊，進行跟蹤。使用者還可以選擇函式呼叫和庫匯入，將它們從跟蹤中排除。

為了展示Anteater在變數跟蹤中的強大功能，用Anteater來分析一下六種梯度下降演算法的效果。觀察的六種方法依次是Vanilla, Momentum, Nesterov, Adagrad, Rmsprop, 和Adam。交叉點的數量（變數num_intersections）以及最小交叉角度（變數min_angle）這兩個變數在梯度下降演算法的每次迭代中都會改變，透過觀察這兩個變數值的變化來判斷幾種演算法的效果。

下圖展示了透過觀察變數num_intersections的變化來選擇梯度下降演算法的過程。（目標：最小化num_intersections） （A）圖概述了6種梯度下降法的行為，觀察散點圖可知，最後三種方法（Adagrad, Rmsprop, 和Adam）會立刻卡住。因此，下一步只需比較Vanilla, Momentum和Nesterov這三種方法的效果。（B）圖中的Vanilla梯度最初朝著一個較差的值（一個大的值）移動，但在最後下降到了一個較好的值（一個小的值）。（C）圖顯示了在Momentum法中，每次num_intersections下降到一個較好的小數值時，又會重新跳到一個較差的大數值上，而（D）圖中的Nesterov方法也有這樣的特點。因此，從最佳化num_intersections值的角度考慮，Vanilla梯度下降法效果最好。下圖則展示了透過觀察變數min_angle的變化來選擇梯度下降演算法的過程。（目標：最大化min_angle）（A）圖概述了6種梯度下降法的行為，觀察散點圖可知，最後三種方法（Adagrad, Rmsprop, 和Adam）要麼立即卡住，要麼只是略有增加。（B）圖中的Vanilla梯度一開始表現較差，但經過一段時間的迭代，最終達到了一個較好的大數值。（C）圖所示的Momentum法，每當min_angle達到一個較好的大數值時，就會迅速開始下降。（D）圖中的Nesterov也表現出類似的規律。因此，從最佳化min_angle值的角度考慮，仍然是Vanilla梯度下降法效果最好。

Anteater的開發者還在TE問題（Tennessee Eastman）上進行了挑戰，提出了一個化工廠的開放基準，考慮了真實世界中的各種複雜因素，以此來展示Anteater在工業應用中的可行性。

（F,G,H表示三種產物，NaN值代表裝置爆炸的設定值，即當反應堆壓力超過3000kPa時,會發生爆炸。）

上圖是使用Anteater系統進行的展示。（A）圖表明成本（Cost）和總產量（Total Production）相關，可以找到低成本且高產量的解決方案。 黑點表示在最佳化的最後一次迭代中達到的解決方案。 在（B）圖中，反應器溫度（Reactor Temperature）引數中較高的值對應更高的總產量（Total Production），爆炸可能性較小。 （C）圖表明在最佳化過程中，H和G是相互競爭的關係，高G值對應低H值。 在（D）圖中，反應器水平（Reactor Level）值影響產物F的產生，低反應器水平對應於高F產量，並且在更高的反應水平下，發生的爆炸更少。

上面這兩個案例展示了Anteater視覺化程式執行和發現程式問題方面獨有的優勢。至於如何更充分地利用這個神器，各位程式猿可參考：Anteater: Interactive Visualization for Program Understanding，用好bug查詢神器，讓程式碼除錯更高效！