如何优雅的debug

Home

如何优雅的debug

谋定而后动

Directory

生产环境遇到一个奇怪的bug,登录到某个页面下载数据,会从后端抛出一个错误。

反思1:评估如何debug,先判断项目规模

在面对未知错误的时候,我第一步就做错了:试图依据报错回调信息,直接在生产环境修改源码。这样做的,理想效果是直接完成调试,速战速决。 小型项目还行,但是一旦遇到大型项目,调用链实在太过复杂。基本就是靠运气和猜了。

反思2:尽快复刻环境

线上debug走了弯路后,非常需要进到IDE环境下调试,这里又会产生一个误判,究竟是IDE remote debug还是吭哧吭哧搭个虚拟环境。 我的踩坑总结是:复杂点,赶紧复刻环境吧。复刻环境不仅仅是为了调试,还可以快速熟悉项目的生态链,对整体有个认知。

反思3:列出假设,不要迷失,用思维导图

面对复杂的问题时候,总是手足无措。我对这个报错,有若干个猜想,只能挨个验证,但是逐个验证过程中,肯定会产生新的问题,一生二,二生三,这样肯定会陷入迷茫。 结果肯定是愈发迷失方向。 面对这个痛点,我的反思是:用思维导图。借助思维导图理清思路是重要的。控制大脑里的“猴子”乱窜,可以梳理清楚脉络。

反思4:熬夜

面对问题,从工作第一年开始我就很迷茫,面对生产环境bug,紧急又重要,发生问题,深夜debug有很多好处,比如允许小代价的试错。 熬夜双刃剑的另一面是,对身体的伤害是不可逆的。 现在遇到的很多问题,我都试图倾尽全力,大不了花一晚上解决。 但是终于有一天,我可能会遇到一晚上无法解决的问题。 我发现自己不再有熬夜的精力了,熬夜后,一周都很难恢复到清爽的状态,头顶闷闷的。

反思5:上医治未病

测试很重要。 如果一个问题,轻轻松松解决,那说明背后有更大更多的问题。求稳不求快。 如果被迫求快,需要申明,逼着你尽快上线的人,应该承担责任。 如果你不好意思开口,就把这篇文档发给TA看。