Debug 是程式員每天要做的事情，根據我的經驗，我們大概花30%的時間寫 bug，再花剩下 70%的時間 debug。Debug 的難度常常會超過寫一個新功能，這是因為寫新功能的時候是正向思考，有确定的方向，一路向前；而排錯不僅需要正向思考，有的時候還需要逆向思考、橫向思考、縱向思考以至于四面八方的思考，比拼腦洞和靈光閃現。如果沒有和一個 bug 纏鬥幾天甚至幾周的經曆，可能難以了解 debug 給程式員帶來的血與淚。Debug 占據程式員這麼多時間，直接關系到大家的精神和身體健康，每一招、每一式都是很值得研究和總結的。我希望通過接下來的幾篇文章，記錄學習 Debugging with Xcode 的過程，并把自己的經驗分享出來；也希望借此抛磚引玉，請神牛們批評指正。
本文是系列開篇，就先說些基礎的東西。
從操作角度說，Debug 無非就是利用 IDE 的功能，在感興趣的位置設定一些斷點，執行重制bug 的步驟，在斷點附近檢視變量内容或是程式語句執行情況。如果變量的值與預期不同，或是代碼的執行路徑與預想的不一樣，就可以研究一下是什麼導緻了這些不一緻，然後一步步按圖索骥，找到最終的症結所在。雖然 IDE 不是必需的，也可以使用 LLDB 的指令在 Terminal 中調試，但是對于體積龐大、邏輯複雜的應用程式，借助 IDE 顯然是更高效的做法，畢竟工欲善其事，必先利其器。
用上面的基本操作，可以适應大多數的調試需求了。隻要保持頭腦清晰，有正确的預期值，哪怕要設定很多斷點，找到 bug 的原因也隻是一個時間上的問題。但是還有一些調試需求，用基本操作是應付不來的，比如感興趣的代碼處于一個消息循環或事件循環中，或是其他任何在重制過程中會反複進入的區域。其難點在于，程式運作過程中，斷點會被反複命中，而斷點一旦命中，程式就被中斷，無法施加下一步操作。
解決方案有二。
一是使用條件斷點，條件滿足時程式才被中斷。假設在我們的代碼中，滑鼠在視圖中的移動會反複經過斷點，但隻有在點選之後，某一個布爾值才會成為 true，那麼我們可以設定“該值為 true 再觸發中斷”這樣的條件，這樣滑鼠可以正常連續移動，直到發生點選事件程式才被中斷。
第二種方法是，首先在斷點上勾選“命中後繼續自動執行”，然後對斷點添加動作（Action），比如在命中的時候，向 console 輸出資訊，可以輸出一個字元串，也可以輸出變量的值。這樣在操作時，斷點即使命中，程式也不會停下來，而是在 console 中輸入我們想要的資訊。一邊操作，一邊關注 console 的輸出，可以獲知剛才的操作對程式的影響，判斷是否符合預期。
在條件允許時，盡量使用 IDE 的調試功能；對于在 Terminal 中使用指令進行調試的做法，我隻想說，有那時間做些有意義的事情更好。Debug 的基本操作可以歸結為：添加斷點，檢視變量和執行情況，找出與預期行為的不同，分析原因，然後重複過程直到找到問題的根本原因。對于反複進入的區域，可以采用條件斷點或者是帶輸出的不中斷斷點來調試。