[[121646]]

所有的程序***能夠以某種形式的日志記錄下來，這樣能方便我們即時知道現在在做什么。而且一旦出現異常，其重要性就愈加明顯了。我們之所以要把程序員分成三六九等，很大一個原因就是，一個偉大的程序員會去寫日志和調試工具，這樣一旦出現問題就能調試程序。

如果程序運作正常，那么可能寫不寫日志沒啥區別。但是，不怕一萬就怕萬一，萬一程序崩潰或者出來一個錯誤的結果，那么這個程序員好不好馬上高下立現。

例1：“我們先搞一個調試版本吧。”

舉個例子，測試人員跑來告訴我說有一個調用函數不工作了。我們先查看了日志，然后發現原因可能出在相鄰的模塊上。調用這個模塊返回的卻是一連串 null 值。當我們查閱相鄰模塊的日志記錄并重新運行測試時，卻沒有獲得任何有用的信息。對于為什么會返回 null 毫無頭緒——不知道是參數錯了，還是外部系統出了故障，亦或是相鄰模塊有 bug，Who knows？

當我們去咨詢負責該段代碼的開發人員時，他們的回答是：“這個簡單，我們先搞一個調試版本吧。”最終往往還是不行！因為我們根本不知道是哪里出了問題，出了什么問題。而且要是已經到了生產階段，增加調試版本就意味著增加更多額外的工作。代碼的日志里面得包含足夠多的信息，以便于一旦出現問題我們可以找到解決的關鍵所在。

例2：告訴我我們應該怎么做

我們產品的一個作用是為 SMS（短信）找到成本***的途徑并將路徑傳達給相應的手機。由于當前手機的位置以及用戶所屬的運營商的不同，理論上存在著很多很多的可能路徑，而且每一條路徑都有一定的成本和相應的優缺點。此外，還會有各種意外會導致不得不禁止某些路徑或者加重某些路徑的權重。系統通過給定約束條件，搜索到***的路線然后返回提供給 SMS。

現在，假設某短信建議使用路徑A發送，但是我們認為路徑B更好，那么路徑A又是怎么被選上的呢？如果沒有日志資料，光看那可能的成百上千條的線路，看它們的成本和復雜的算法，我想我會瘋掉。幸虧日志里給出了之所以選擇路徑A的原因。Thank Godness！

日志里面包含了所有可能的路線，并按成本進行排序。哪怕是由于條件限制而淘汰的路線也會列在日志里，并附上之所以淘汰的原因。總之，在日志里會將如何把所有信息輸入到算法中以得出結論的各個步驟描述得一清二楚，以便于我們知道為什么要選擇相應路徑。

為什么不愿意寫可調試的代碼？

既然好處大大的，那么為什么不是所有的程序員都愿意寫可調試的代碼呢？原因有三：

1. 得有足夠的自知之明，能認識到萬一程序發生異常的情況。不過很多程序員往往要經過很長一段時間才會明白“老子并非天下***”。

2. 徹底地測試代碼才能保證它能在各種場景下都能正常運作。而且每個場景都要寫日志。如果不都測試一下，那你怎么知道哪里需要添加記錄。

3. 很多程序員往往對自己的代碼做不到精益求精。如果在現場演示的時候系統出了問題，但是在日志里又看不出是為什么，那么***能在日志里加點什么，以防下次再碰到類似的情況。

你的代碼是可調試的嗎？

當然也會有這樣的情況，那就是日志寫的很好，但是你還是不知道問題的關鍵原因。這時候，你可能還是得創建一個調試版本。但是你的日志最最起碼得能給出問題的線索。

***，請問大家，你的代碼是可調試的嗎？當代碼出現問題，你的日志能告訴你是怎么回事嗎？

本文鏈接：http://www.cocoachina.com/programmer/20141025/10038.html