優秀程式設計師寫可除錯的程式碼

　　所有的程式都需要某種形式的日誌記錄建立在它們之上，以便我們可以觀察到它正在做什麼。這尤其在程式出錯時就顯得非常重要。一個優秀的程式設計師和一個糟糕的程式設計師之間的一個不同之處是一個優秀的程式設計師會增加日誌或其他工具以便在程式失敗時方便除錯。

　　當程式如同預期的一樣工作時，有日誌和沒日誌往往沒什麼差異。然而，一旦程式失敗，或你得到一個錯誤的結果的時候，你會立即明白優秀的程式設計師和糟糕的程式設計師之間的差別。

　　例1：“讓我們做一個可除錯的版本”

　　比如說，測試關於一個不能正常工作的呼叫case過來找我。我們檢視了日誌，然後發現問題貌似出在一個相鄰的模組。對其他模組的呼叫返回值為 空。然後我們在那個相鄰的模組中做了日誌記錄，重新跑了一遍測試case,卻沒有得到任何更多的有用資訊。沒有任何線索表明為什麼會返回空 -難道是我們下錯了引數，或者是某個外部系統導致的失敗，那個相鄰的模組中是不是存在一個錯誤，又或者？

　　當我們去詢問負責這塊程式碼的開發人員時，我們得到的回答是：“Oh，我們必須做一個debug的版本來看看到底發生了什麼”。失敗！從某種意義 來說，從日誌中找到問題所在應該是可能的，如果問題存在一個執行的系統中，新增一個除錯版本將會有大量的工作要做。程式碼需要包含足夠多的資訊在日誌，以便你至少可以對失敗的原因有一些瞭解。

　　例2：“讓我看看我們是如何走到這裡的” ??

　　我們的一個產品在工作時會找到一個簡訊息傳遞到手機最便宜的路徑。依據手機的當前位置和目標使用者所屬的運營商，有很多可能的路由選擇， 每一個都有一個給定的成本和其他特徵。除此之外，可以有一些例外，比如說禁止一些路線，以促進其他路線，通常 會有成千上萬的路由被定義，在每個case中系統找到最便宜的一個路由，加上限定條件，並且傳遞訊息。

　　現在，假想某個SMS資訊使用A路線傳遞，但是我們認為他應該使用B，為什麼A會被選擇呢？如果沒有任何日誌記錄資訊，我們只剩下成百個可能的途徑， 他們的成本，例外，以及一個複雜的演算法，那麼祝你好運搞清楚為什麼A會被選擇。

　　在我們的實現中，所有可能存在的路由以成本大小的順序羅列在日誌中，當路由被不同的限制條件排除時，排除掉的路由和原因就會被列在log中。 隨著演算法的輸入，以及採取的步驟信資訊列在log中，就會很容易的看出為什麼某個路徑會被選取。

　　為什麼不呢？

　　所以，為什麼不是所有的程式設計師都會寫可調式的程式碼呢？我能想到三個原因：

1. 你必須足夠謙虛的意識到你的程式碼會有不按預期工作的時候。我相信很多程式設計師會對此比較難過。
2. 如果你徹底地測試了你的程式碼，你應該確保它會在很多不同場合工作或失敗。對於每個方案，很自然地加入日誌記錄，如果你沒有測試 那些情況，你不太可能會在那裡新增記錄。
3. 很多程式設計師往往不會在產品系統中修復他們自己的程式碼。如果在線上系統中有一個問題，但log並沒有反饋任何資訊給你為什麼這裡會有一個問題， 你會有一個很強烈的動機去增加log,以便下次遇到相同的情況時幫助到你。

　　你的程式碼可除錯嗎？

　　當然會有一些情況，對於程式為什麼會失敗好的日誌資訊也不能給你一個確切的資訊。你可能還是要做出那樣的除錯版本， 但是你經常做記錄至少還是會提供給你一些隱藏資訊關於問題的可能性。

　　所以，你準備的怎麼樣了？當你的程式失敗時，log會告訴你哪兒出錯了嗎？

　　原文連結： henrikwarne   翻譯： 伯樂線上 - hahakaka