[[121646]]

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

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

例1：“我們先搞一個調(diào)試版本吧。”

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

當我們?nèi)プ稍冐撠熢摱未a的開發(fā)人員時，他們的回答是：“這個簡單，我們先搞一個調(diào)試版本吧。”最終往往還是不行！因為我們根本不知道是哪里出了問題，出了什么問題。而且要是已經(jīng)到了生產(chǎn)階段，增加調(diào)試版本就意味著增加更多額外的工作。代碼的日志里面得包含足夠多的信息，以便于一旦出現(xiàn)問題我們可以找到解決的關(guān)鍵所在。

例2：告訴我我們應(yīng)該怎么做

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

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

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

為什么不愿意寫可調(diào)試的代碼？

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

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

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

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

你的代碼是可調(diào)試的嗎？

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

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

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