如果你的代碼悲劇了，你的日志能幫你成為福爾摩斯嗎？
作者：Henrik Warne
翻譯：童角大王
所有程序都需要一些記錄日志的方法，這樣我們才可以觀察它的運作狀況。當程序出現錯誤時，這樣的未雨綢繆就非常重要了。
好程序員和壞程序員之間的一個不同點在于，優秀的程序員會記錄有用的日志以及增加方便調試程序的工具。
當程序工作如常，通常無法體現出日志的重要性。可是一旦程序出錯，或者得到了錯誤結果，優秀的程序員就會脫穎而出。
案例1
一個測試人員跑來向我報告一個測試用例失敗，我們一起檢查日志，發現問題似乎出在另一個模塊之中。一個本該返回數組的函數卻只返回了null值。
當我們把嫌疑模塊的日志打開，再次運行測試用例，卻沒有發現新的線索——是因為傳遞了錯誤的參數，還是外部系統的運行失敗，或是一個被引用的模塊出現錯誤?或者是什么別的原因?
我們去詢問這段代碼的責任人，他會回答到：“奧，那我們得加上日志，弄一個調試版本，再部署一次，看看到底是怎么回事。
這是大錯特錯的，對于已經部署到生產環境的程序，增加，部署調試版本可能是一件工程量浩大的工作!代碼需要包含足夠的日志信息，當調試模式打開時，就可以通過日志來判斷為什么出錯了。
案例2
我曾經開發過一個軟件，它可以根據你手機目前所處的位置以及接收者運營商的不同，幫助你找到發送短信的最短(代價最低)路徑。
有些時候運營商會限制或推廣一些傳輸路徑，在這潛在的千百條路徑中，我們的系統可以考慮到這些限制，并幫你找到最便宜的那一條。
假設有一條本該使用路徑B的短信意外地通過路徑A傳輸了，是什么原因導致的呢?如果沒有其他的日志信息(除了“嘿兄弟，路徑A被使用了”)，我們就只能面對著上百種可能的路徑，不同的花銷，特別的限制和復雜的算法，傻眼了。
而在我們的產品實現中，會以花費的多寡為順序，將可能路徑都記錄在日志之中。因為各種限制的存在，有些路徑會被篩選掉，這些路徑以及被篩選的原因也會被記錄在日志中。根據算法所接受的輸入，以及在日志中列出的步驟，你可以更容易地看出為什么一條路徑會被選中。
那么問題來了， 為什么有些程序員不寫包含足夠日志的代碼呢?我覺得有三條原因：
1. 可能沒有意識到代碼總是會出錯，我相信很多程序員都需要經歷一些事情才會認清這個現實。
2. 自己沒有做徹底的測試，如果你做過的話，你可以確定代碼在哪些場景成功，在哪些場景“優雅地”失敗。在這些場景，你自然會添加有效的調試日志。如果你沒有做足夠的測試，你也不大可能會添加日志。
3. 許多程序員還沒有在生產環境中給代碼排錯的經歷，如果生產環境有問題，而日志卻不能給你提供線索，這樣的血與淚會激勵你以后一定要乖乖寫日志。
當然，在不少情況下，就算擁有記錄良好的日志信息，你也無法徹底了解為啥事情失敗了。也許你還是需要部署一個新的調試版本。但是如果你的調試日志足夠好，至少可以幫你縮小問題的范圍。
所以大兄弟，你準備好了嗎?如果你的代碼悲劇了，你的日志能助你成為名偵探嗎?歡迎里留言討論!
原文地址：
https://henrikwarne.com/2013/05/05/great-programmers-write-debuggable-code/
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
