如果你的代码悲剧了,你的日志能帮你成为福尔摩斯吗?
收藏

 作者:Henrik Warne

翻译:童角大王


所有程序都需要一些记录日志的方法,这样我们才可以观察它的运作状况。当程序出现错误时,这样的未雨绸缪就非常重要了。


好程序员和坏程序员之间的一个不同点在于,优秀的程序员会记录有用的日志以及增加方便调试程序的工具


当程序工作如常,通常无法体现出日志的重要性。可是一旦程序出错,或者得到了错误结果,优秀的程序员就会脱颖而出。


案例1


一个测试人员跑来向我报告一个测试用例失败,我们一起检查日志,发现问题似乎出在另一个模块之中。一个本该返回数组的函数却只返回了null值。


当我们把嫌疑模块的日志打开,再次运行测试用例,却没有发现新的线索——是因为传递了错误的参数,还是外部系统的运行失败,或是一个被引用的模块出现错误?或者是什么别的原因?


我们去询问这段代码的责任人,他会回答到:“奥,那我们得加上日志,弄一个调试版本,再部署一次,看看到底是怎么回事。


这是大错特错的,对于已经部署到生产环境的程序,增加,部署调试版本可能是一件工程量浩大的工作!代码需要包含足够的日志信息,当调试模式打开时,就可以通过日志来判断为什么出错了。


案例2


我曾经开发过一个软件,它可以根据你手机目前所处的位置以及接收者运营商的不同,帮助你找到发送短信的最短(代价最低)路径。


有些时候运营商会限制或推广一些传输路径,在这潜在的千百条路径中,我们的系统可以考虑到这些限制,并帮你找到最便宜的那一条。


假设有一条本该使用路径B的短信意外地通过路径A传输了,是什么原因导致的呢?如果没有其他的日志信息(除了“嘿兄弟,路径A被使用了”),我们就只能面对着上百种可能的路径,不同的花销,特别的限制和复杂的算法,傻眼了。


而在我们的产品实现中,会以花费的多寡为顺序,将可能路径都记录在日志之中。因为各种限制的存在,有些路径会被筛选掉,这些路径以及被筛选的原因也会被记录在日志中。根据算法所接受的输入,以及在日志中列出的步骤,你可以更容易地看出为什么一条路径会被选中。



那么问题来了, 为什么有些程序员不写包含足够日志的代码呢?我觉得有三条原因:


1. 可能没有意识到代码总是会出错,我相信很多程序员都需要经历一些事情才会认清这个现实。


2.  自己没有做彻底的测试,如果你做过的话,你可以确定代码在哪些场景成功,在哪些场景“优雅地”失败。在这些场景,你自然会添加有效的调试日志。如果你没有做足够的测试,你也不大可能会添加日志。


3. 许多程序员还没有在生产环境中给代码排错的经历,如果生产环境有问题,而日志却不能给你提供线索,这样的血与泪会激励你以后一定要乖乖写日志。


当然,在不少情况下,就算拥有记录良好的日志信息,你也无法彻底了解为啥事情失败了。也许你还是需要部署一个新的调试版本。但是如果你的调试日志足够好,至少可以帮你缩小问题的范围。


所以大兄弟,你准备好了吗?如果你的代码悲剧了,你的日志能助你成为名侦探吗?欢迎里留言讨论!


原文地址:

https://henrikwarne.com/2013/05/05/great-programmers-write-debuggable-code/



码农翻身公众号开放投稿,可能是全网最高片酬:

用故事讲技术 ,稿费1000

技术/职场/感悟/面试等,稿费700

翻译类文章,每千字200

联系方式:onlyliuxin97(微信)

详情猛戳: 可能是全网最高片酬,速来!



往期精彩回顾

我是一个线程

我是一个Java Class

面向对象圣经

函数式编程圣经

TCP/IP之大明邮差

CPU阿甘

我是一个网卡

我是一个路由器

一个故事讲完HTTPs

编程语言的巅峰

Java:一个帝国的诞生

JavaScript:一个屌丝的逆袭

负载均衡的原理

阅读源码的三种境界

官方公众号