<< ..
如何优雅的debug
发布时间:生产环境遇到一个奇怪的bug，登录到某个页面下载数据，会从后端抛出一个错误。
反思1：评估如何debug，先判断项目规模
在面对未知错误的时候，我第一步就做错了：试图依据报错回调信息，直接在生产环境修改源码。这样做的，理想效果是直接完成调试，速战速决。 小型项目还行，但是一旦遇到大型项目，调用链实在太过复杂。基本就是靠运气和猜了。
反思2：尽快复刻环境
线上debug走了弯路后，非常需要进到IDE环境下调试，这里又会产生一个误判，究竟是IDE remote debug还是吭哧吭哧搭个虚拟环境。 我的踩坑总结是：复杂点，赶紧复刻环境吧。复刻环境不仅仅是为了调试，还可以快速熟悉项目的生态链，对整体有个认知。
反思3：列出假设，不要迷失，用思维导图
面对复杂的问题时候，总是手足无措。我对这个报错，有若干个猜想，只能挨个验证，但是逐个验证过程中，肯定会产生新的问题，一生二，二生三，这样肯定会陷入迷茫。 结果肯定是愈发迷失方向。 面对这个痛点，我的反思是：用思维导图。借助思维导图理清思路是重要的。控制大脑里的“猴子”乱窜，可以梳理清楚脉络。
反思4：熬夜
面对问题，从工作第一年开始我就很迷茫，面对生产环境bug，紧急又重要，发生问题，深夜debug有很多好处，比如允许小代价的试错。 熬夜双刃剑的另一面是，对身体的伤害是不可逆的。 现在遇到的很多问题，我都试图倾尽全力，大不了花一晚上解决。 但是终于有一天，我可能会遇到一晚上无法解决的问题。 我发现自己不再有熬夜的精力了，熬夜后，一周都很难恢复到清爽的状态，头顶闷闷的。
反思5：上医治未病
测试很重要。 如果一个问题，轻轻松松解决，那说明背后有更大更多的问题。求稳不求快。 如果被迫求快，需要申明，逼着你尽快上线的人，应该承担责任。 如果你不好意思开口，就把这篇文档发给TA看。