如果程式運作正常，那麼可能寫不寫日誌沒啥區別。但是，不怕一萬就怕萬一，萬一程式崩潰或者出來一個錯誤的結果，那麼這個程式設計師好不好馬上高下立現。
例1：“我們先搞一個除錯版本吧。”
舉個例子，測試人員跑來告訴我說有一個呼叫函式不工作了。我們先檢視了日誌，然後發現原因可能出在相鄰的模組上。呼叫這個模組返回的卻是一連串null值。當我們查閱相鄰模組的日誌記錄並重新執行測試時，卻沒有獲得任何有用的資訊。對於為什麼會返回null毫無頭緒——不知道是引數錯了，還是外部系統出了故障，亦或是相鄰模組有bug，Who knows？
當我們去諮詢負責該段程式碼的開發人員時，他們的回答是：“這個簡單，我們先搞一個除錯版本吧。”最終往往還是不行！因為我們根本不知道是哪裡出了問題，出了什麼問題。而且要是已經到了生產階段，增加除錯版本就意味著增加更多額外的工作。程式碼的日誌裡面得包含足夠多的資訊，以便於一旦出現問題我們可以找到解決的關鍵所在。
例2：告訴我我們應該怎麼做
我們產品的一個作用是為SMS（簡訊）找到成本最低的途徑並將路徑傳達給相應的手機。由於當前手機的位置以及使用者所屬的運營商的不同，理論上存在著很多很多的可能路徑，而且每一條路徑都有一定的成本和相應的優缺點。此外，還會有各種意外會導致不得不禁止某些路徑或者加重某些路徑的權重。系統通過給定約束條件，搜尋到最便宜的路線然後返回提供給SMS。
現在，假設某簡訊建議使用路徑A傳送，但是我們認為路徑B更好，那麼路徑A又是怎麼被選上的呢？如果沒有日誌資料，光看那可能的成百上千條的線路，看它們的成本和複雜的演算法，我想我會瘋掉。幸虧日誌裡給出了之所以選擇路徑A的原因。Thank Godness！
日誌裡面包含了所有可能的路線，並按成本進行排序。哪怕是由於條件限制而淘汰的路線也會列在日誌裡，並附上之所以淘汰的原因。總之，在日誌裡會將如何把所有資訊輸入到演算法中以得出結論的各個步驟描述得一清二楚，以便於我們知道為什麼要選擇相應路徑。
為什麼不願意寫可除錯的程式碼？
既然好處大大的，那麼為什麼不是所有的程式設計師都願意寫可除錯的程式碼呢？原因有三：
- 1.得有足夠的自知之明，能認識到萬一程式發生異常的情況。不過很多程式設計師往往要經過很長一段時間才會明白“老子並非天下第一”。
- 2.徹底地測試程式碼才能保證它能在各種場景下都能正常運作。而且每個場景都要寫日誌。如果不都測試一下，那你怎麼知道哪裡需要新增記錄。
- 3.很多程式設計師往往對自己的程式碼做不到精益求精。如果在現場演示的時候系統出了問題，但是在日誌裡又看不出是為什麼，那麼最好能在日誌里加點什麼，以防下次再碰到類似的情況。
當然也會有這樣的情況，那就是日誌寫的很好，但是你還是不知道問題的關鍵原因。這時候，你可能還是得建立一個除錯版本。但是你的日誌最最起碼得能給出問題的線索。
最後，請問大家，你的程式碼是可除錯的嗎？當程式碼出現問題，你的日誌能告訴你是怎麼回事嗎？
英文原文：Great Programmers Write Debuggable Code
翻譯作者：碼農網 – 小峰
來自：程式師
相關閱讀
評論(1)