優秀程序員寫可調試的代碼
所有的程序都需要某種形式的日志記錄建立在它們之上，以便我們可以觀察到它正在做什么。這尤其在程序出錯時就顯得非常重要。一個優秀的程序員和一個糟糕的程序員之間的一個不同之處是一個優秀的程序員會增加日志或其他工具以便在程序失敗時方便調試。
當程序如同預期的一樣工作時，有日志和沒日志往往沒什么差異。然而，一旦程序失敗，或你得到一個錯誤的結果的時候，你會立即明白優秀的程序員和糟糕的程序員之間的差別。
例1：“讓我們做一個可調試的版本”
比如說，測試關于一個不能正常工作的調用case過來找我。我們查看了日志，然后發現問題貌似出在一個相鄰的模塊。對其他模塊的調用返回值為 空。然后我們在那個相鄰的模塊中做了日志記錄，重新跑了一遍測試case,卻沒有得到任何更多的有用信息。沒有任何線索表明為什么會返回空 -難道是我們下錯了參數，或者是某個外部系統導致的失敗，那個相鄰的模塊中是不是存在一個錯誤，又或者？
當我們去詢問負責這塊代碼的開發人員時，我們得到的回答是：“Oh，我們必須做一個debug的版本來看看到底發生了什么”。失敗！從某種意義 來說，從日志中找到問題所在應該是可能的，如果問題存在一個運行的系統中，添加一個調試版本將會有大量的工作要做。代碼需要包含足夠多的信息在日志，以便你至少可以對失敗的原因有一些了解。
例2：“讓我看看我們是如何走到這里的” ??
我們的一個產品在工作時會找到一個短信息傳遞到手機***的路徑。依據手機的當前位置和目標用戶所屬的運營商，有很多可能的路由選擇， 每一個都有一個給定的成本和其他特征。除此之外，可以有一些例外，比如說禁止一些路線，以促進其他路線，通常 會有成千上萬的路由被定義，在每個case中系統找到***的一個路由，加上限定條件，并且傳遞消息。
現在，假想某個SMS信息使用A路線傳遞，但是我們認為他應該使用B，為什么A會被選擇呢？如果沒有任何日志記錄信息，我們只剩下成百個可能的途徑， 他們的成本，例外，以及一個復雜的算法，那么祝你好運搞清楚為什么A會被選擇。
在我們的實現中，所有可能存在的路由以成本大小的順序羅列在日志中，當路由被不同的限制條件排除時，排除掉的路由和原因就會被列在log中。 隨著算法的輸入，以及采取的步驟信信息列在log中，就會很容易的看出為什么某個路徑會被選取。
為什么不呢？
所以，為什么不是所有的程序員都會寫可調式的代碼呢？我能想到三個原因：
1.你必須足夠謙虛的意識到你的代碼會有不按預期工作的時候。我相信很多程序員會對此比較難過。
2.如果你徹底地測試了你的代碼，你應該確保它會在很多不同場合工作或失敗。對于每個方案，很自然地加入日志記錄，如果你沒有測試 那些情況，你不太可能會在那里添加記錄。
3.很多程序員往往不會在產品系統中修復他們自己的代碼。如果在在線系統中有一個問題，但log并沒有反饋任何信息給你為什么這里會有一個問題， 你會有一個很強烈的動機去增加log,以便下次遇到相同的情況時幫助到你。
你的代碼可調試嗎？
當然會有一些情況，對于程序為什么會失敗好的日志信息也不能給你一個確切的信息。你可能還是要做出那樣的調試版本， 但是你經常做記錄至少還是會提供給你一些隱藏信息關于問題的可能性。
所以，你準備的怎么樣了？當你的程序失敗時，log會告訴你哪兒出錯了嗎？
原文鏈接： henrikwarne 翻譯： 伯樂在線 - hahakaka
