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