程式設計除錯和診斷的五大規則

　　在程式設計過程中，除錯和診斷如影相隨，以確保程式的完美執行，這就像是一門藝術。本文詳述了除錯和診斷的五大規則，包括程式設計前後的不同事項。分享給各位程式設計師，希望能對你們有用。

　　Micheal Shallop是一位資深的Web開發者，軟體工程師。6月21號在DZone上發表文章The Top 5 Debugging and Diagnostic Rules for Programming，分享自己多年的工作經驗。下面是編譯內容。

　　在我的職業生涯中，不管是系統開發、系統設計、還是系統除錯，我都是這些方面的專家。對於我的成就，我很自豪。後來我大部分時間都花在系統檢查上。“系統崩潰了”是我經常聽到的話。

　　在一個進行了三年的專案裡，我沒有任何假期，甚至沒有脫產培訓，外出都是帶著膝上型電腦，以便於每天早上可以檢查頭天晚上的執行結果。這種緊張而有序的工作情況恐怕不是所有人都能想象得到的。花在技術支援上的時間可以幫我磨練診斷技術——想想看，您正在安裝一個你根本看不到的系統，還要和遠端專家進行交流。時間久了，技術就是這樣慢慢積累起來的。

　　還是來說說重點吧，在這些年的工作當中我已經學到了很多程式設計除錯很診斷的東西。我目前的任務是編寫一個後端資料系統，100%的可伸縮，水平和垂直方向的，使用的是開源服務專案，例如mongo，mysql，rabbitmq和memcache，框架是由我編寫的100%PHP。當別人看著我設計出來的系統的時候，我能從他的眼裡看出羨慕的眼神——這是知識的力量。可是你有沒有發現，現在的高校仍然缺乏在軟體/系統除錯和診斷方面的綜合性專業。

　　除錯的方法主要是目標訪問、執行控制以及實時跟蹤。除錯問題貫穿多種多樣的系統，整合開源系統，或者在你自己的程式碼之間，這就像是一門藝術。在過去的幾十年裡，我編譯了關於診斷技術的非正式列表，很榮幸與你分享。

　　Rule 1—最後的更改可能會讓整個專案前功盡棄

　　在我做電話技術支援（Pre-Web）的時候，我學到一件事情，如果你花足夠長的時間去聆聽客戶的話，那你就知道怎樣解決客戶的問題。在大部分情況下，如果系統或軟體突然停止工作，原因可能是你在執行環境裡做了一些改變，不論是配置還是程式碼，都會對系統的穩定性有很大的衝擊。

　　一旦你取消改變的專案，重新執行，恢復舊的資料庫，撤銷程式包，看看系統/軟體是否繼續工作？如果繼續工作，那就能知道是什麼導致系統漏洞，同時還可以找到系統崩潰的切入點。

　　你可能會很驚訝，經驗豐富的程式設計師或管理員會不會經常忽略這條規律？其實，如今的軟體是很穩定的，基本上不會自行變動。一旦它突然停止，就必須判斷原因是什麼，為什麼會出現這樣的問題。有可能是你作了一些變動。如果沒有，就詢問團隊是誰安裝了最後一段程式或誰意外的改動了檔案許可權等等。

　　最後要檢查的，就是你最先修改的東西。

　　Rule 2—複製問題

　　針對軟體開發，如果要診斷一個問題，那首要任務是重新把這個問題製造出來，才能從根本上了解並解決問題。有可能需要你真正參與進來：讓終端使用者確定他們所做的事件的確切順序，以便能夠產生同樣的錯誤。

　　作為一個軟體工程師，在不知道具體問題的時候修復程式碼的確很難。所以說，在這種情況下，你就不得不重新制造同樣的問題。

　　如果同樣的動作產生不一致的結果，比如說，工作第一次，第二次就不工作了，接著第三次第四次第五次都工作，但第六次又不工作了。問題可能出現在資料上，並且需要檢查執行時間配置選項、有效載荷、輸入和結果。程式碼不是關鍵問題，因為程式碼每次都是以同樣的方式執行的。

　　當然啦，通常情況下也會有特例，不過這些年特例變得越來越罕見了，因為電腦都已經配備了保護記憶體的功能。數十年前，我講過一堂核心崩潰分析的課程。穩定就是點動滑鼠的一系列順序，給滑鼠驅動程式重新編碼，通過記憶體分配將接收到的順序輸入印表機驅動程式，當釋出一個列印命令的時候——核心轉儲！

　　如果你能連貫地複製問題，那你就有能力處理程式碼問題。

　　Rule 3—找出原因，而不是症狀

　　因為系統都是互相聯絡的，沿著錯誤的道路診斷問題是最常見的錯誤，這被稱之為“連鎖反應”，軟體或系統裡的問題能夠體現在不同的區域，挽回軟體的質量只是問題的表面。當問題露出水面的時候，需要仔細想一想：我是要處理問題呢，還是處理看到的症狀呢？

　　當處理一個問題的時候，你只是在問題上兜圈子，你必須停止您的心理過程，只需簡單地確定你所處理的問題是表面症狀還是有因果關係的。

　　Rule 4—要有信心

　　我曾經教過非傳統的學生如何開始程式設計，他們當中的一些人認為電腦是智慧的，惡毒的，有密謀的，詭計多端的，陰險狡猾的，看上去就像是一個充滿惡作劇的盒子。

　　電影Short-Circuit（霹靂五號）裡有段臺詞：

　　它只是一個機器，施羅德。它不會生氣，沒有快樂，不知道難過，不會嘲笑你的笑話...它只會執行程式！

　　人們往往忘記了這一點，在軟體完美執行第一次之後，只要提供相同的資料和穩定的執行環境，那它就能一直完美無缺的執行下去。如果在兩個對話視窗完成了測試，卻在第三個視窗上失敗了，其實不要浪費時間檢查程式碼，因為問題不在軟體上，而在第三個對話視窗的環境配置上，或者是輸入的資料有問題。

　　不幸的是，能夠發現基於軟體問題的技術精英實在是很少，因為他們知道這方面幾乎所有的問題。

　　“伺服器有問題。”

　　“軟體有問題。”

　　有些看上去深入的觀點其實並沒有經過分析。你千萬不要因為別人這樣的評論而分心，不能被別人誤導，更不能動搖自己的立場。尤其當你是負責除錯/編寫系統或軟體的帶頭人/開發者/管理員的時候。你必須有信心，堅信你的程式碼、平臺和資料庫在給出一致的輸入和穩定環境的條件下，每次都能在相同的時間內完成執行。

　　當然，從表面上看，軟體或系統可能是“有問題的”，但這並不表明只需簡簡單單的處理程式碼塊——而是要分析問題範圍，瞭解前置條件，資料來源的完整性和輸出質量。如果所有的專案都如設計的那樣保持一致性，那你就應該看看對話方塊以外的地方，說不定問題根源就在那裡。

　　Rule 5—記錄，記錄，再記錄

　　記錄在一個開發環境不能被濫用。通過記錄,當然,我指的是診斷或提示性資訊嵌入到程式碼庫的輸出,提供一個初步的問題確定性。要有頻率、長時間的記錄。

　　記錄資訊不僅僅提供洞察程式碼的問題區域，還給你提供自信——一切都按計劃執行/處理/計算，一切都在監控中。記錄工作同樣可以告訴你這個查詢、計算和方法都是成功的。

　　就我個人而言,我總是硬編碼兩個級別的登入作為程式碼的子程式。我經常在每個方法的入口點編寫跟蹤輸出的程式碼，而且以關鍵決策點的出現作為條件編寫除錯程式碼，然後可以使用我的記錄輸出手段跟蹤程式流，同時關注臨界值。因為這些都是執行時方法，系統配置裡單獨的Boolean可以控制所有的跟蹤，所以在非開發環境中資訊傳送功能是受限制的。

　　此外，拿記錄PHP為例，有一個全域常數：__檔案__，__線性__，__方法__和__功能__，這為你提供一個資訊記錄模板，還有一些其他模板：

　　隨著開發的繼續，你的硬編碼行數將迅速變得毫無意義,除了搜尋鍵還有點用。編寫記錄程式碼要用到所有的資訊和有效程式碼相關的東西。

　　如果你想知道不同的記錄等級之間有什麼區別，那我建議你閱讀文章10-Commandments of Logging。你可能並不贊同文章裡的觀點，但我保證你肯定會下決心改變之前的記錄方法。

　　獎勵制度

　　和二十年前我們普遍使用的工具相比起來，今天年輕的程式設計師使用的先進工具是經過我們不懈的努力創造出來的，這段美好的回憶將是在這個相對年輕領域裡奮鬥過的前輩們最好的禮物。我的第一個除錯工具是printf()和(sh)，然而當印表機被廣泛使用的時候，轉存一個50000-line C-code列表到摺疊式記錄紙上，一個紅色的氈筆頭和大量的走廊空間成了我的偵錯程式。

　　現代偵錯程式是你的朋友,你的得力助手，能夠向你的老闆證明你簡直就是個天才——它允許你在開發階段分步除錯程式碼和發現問題。不但能分步除錯，附加變數監控，還能跳回堆疊，一切都是那麼簡單，聽起來有點不可思議！

　　總之，如果你不想開發使用偵錯程式，那建議你抽時間給你的IDE安裝並配置一個除錯程式包。用過你就會很驚訝，如果沒有偵錯程式，你該怎麼編碼？

　　總結

　　除錯是一個習得的技能，所有的要點都已經在上面提到了，但這也不一定對你有幫助——如果你不知道你的系統，不瞭解你的應用程式或者是不懂電腦科學的基本規律。

　　英國科幻作家Arthur C. Clarke說過：任何非常先進的技術,初看都與魔法無異。

　　對於那些才疏學淺的人來說，觀看優秀的開發人員或系統管理員解決複雜程式問題簡直就像是玩魔術！真希望那種感覺會激勵你努力學習必要的技能來加入到魔法行列。

　　英文原文：top-5-debugging-and-diagnostic