怎么办_发版后报错指数级上升！代码出bug了怎么办？怎样才能少出bug？

你是否有过这样的经历&＃xff1f;周五的午后&＃xff0c;你完成了手头的工作&＃xff0c;边摸鱼边考虑晚上下班去哪吃饭。突然同事的一条消息把你从轻松愉悦的氛围里拽了出来&＃xff1a;“线上出现大量报错&＃xff0c;赶紧看看&＃xff01;”。

你心想&＃xff1a;“不应该啊&＃xff0c;明明上线前测试的很充分&＃xff0c;怎么会出问题呢&＃xff1f;”。带着疑惑的心情点开了报错链接&＃xff0c;推栈显示确实是你新版本里上线的代码&＃xff0c;报错量呈指数上升。你心里一沉&＃xff0c;心跳开始加速&＃xff0c;赶紧打开问题代码的仓库&＃xff0c;排查问题原因。好在发现上线前预留了一个动态配置控制这里的逻辑&＃xff0c;赶紧配置好回滚&＃xff0c;联系相关同学进行发布。发布完成后不久报错量果然下降了&＃xff0c;面红耳赤的你终于松了一口气&＃xff0c;擦了擦额头的汗。心想&＃xff1a;“还好上线前预留了开关&＃xff0c;不然这次就要出大锅了”。这种场景在我工作的前几年时常发生&＃xff0c;有时候在重大功能上线之前我还会担心的睡不着觉。不过随着处理 bug 的经验越来越多&＃xff0c;遇到 bug 的场景反而越来越少了。

现在回想起来&＃xff0c;自己编程能力的提升很大一部分来自处理 bug 时学到的经验。我曾经遇到过非常严重的 bug&＃xff0c;严重到把整个开发团队辞退都不过分的那种&＃xff08;虽然公司并没有这么做&＃xff09;。那段时间顶着巨大的压力&＃xff0c;没日没夜的工作。从紧急止损&＃xff0c;评估影响面&＃xff0c;到开复盘会&＃xff0c;落实改善措施等等。虽然过程很煎熬&＃xff0c;但是这件事之后&＃xff0c;我发现我再遇到的 bug 真的是不值一提&＃xff0c;再出 bug 时也总是能冷静处理。想想也很合理&＃xff0c;跟最严重的 bug 交过手之后&＃xff0c;你还会怕那些小 bug 吗&＃xff1f;相信大部分程序员都不希望自己写的代码出 bug。但是 bug 往往无法避免&＃xff0c;如何正确的处理 bug&＃xff0c;也是成为优秀程序员的必备技能。所以我把我的经验总结下来&＃xff0c;希望可以跟大家分享我处理 bug 的经验&＃xff0c;以及怎样才能少出 bug。

线上出 bug 之后该怎么办&＃xff1f;

1. **紧急止损。**遇到 bug 的第一件事一定是紧急止损。无论是用配置开关&＃xff0c;后端兼容&＃xff0c;hotfix&＃xff0c;发版本等等手段。只有先止损&＃xff0c;对用户/公司/你自身的影响才会最小&＃xff0c;有的人遇到 bug 之后就开始推诿塞责&＃xff0c;敷衍了事&＃xff0c;总想着去甩锅。遇到这种人不必跟他们扯皮&＃xff0c;优先处理 bug&＃xff0c;记住止损是第一位的。
2. **确定影响面。**bug 止损或者修复之后&＃xff0c;要尽早确定影响面。通常影响面是评估一个 bug 严重性最重要的指标&＃xff0c;在评估影响面上要做到准确真实。不要害怕由于影响面太大而瞒报数据&＃xff0c;坦诚面对才能让你真正的成长。
3. **向老板汇报。**及时汇报也是非常重要的&＃xff0c;假如你害怕老板知道之后会影响你的绩效从而没汇报的话。那你可以想象一下&＃xff0c;如果你老板的老板知道了这个 bug&＃xff0c;再去询问你老板的时候&＃xff0c;他却不知道&＃xff0c;你觉得后果会是什么&＃xff1f;永远不要让你的老板成为最后一个知道问题发生的人。
4. **及时复盘。**通常严重的问题会组织复盘会&＃xff0c;详细的分析前因后果&＃xff0c;以及规划改进措施。但是如果不是很严重的问题。你可以自己做一个小小的复盘&＃xff0c;流程跟复盘会基本一致&＃xff0c;最好是通过文字记录下来&＃xff0c;防止自己下次再犯类似的问题。
5. **落实改进措施。**改进措施里通常会有一些长期的项目&＃xff0c;比如监控系统的完善&＃xff0c;告警系统的推进等等。由于推动起来比较麻烦&＃xff0c;不少措施到最后也没有落实&＃xff0c;最终引发了更严重的 bug。如果你想做的比别人更好的话&＃xff0c;踏踏实实的把改进措施一项一项的落实&＃xff0c;多做一些脏活累活&＃xff0c;你会比别人成长的快的多。

怎样才能少出bug&＃xff1f;

1. **自测&＃xff0c;站在用户角度的测试。**自测一定是必须的&＃xff0c;这是对自己代码负责任的表现。不要过度指望测试同学可以帮你测出所有bug。同时你需要切换到用户的角度进行测试&＃xff0c;多想想假如你是一个普通用户你会怎么使用这个产品。如果你只用你写代码时的思维去进行测试&＃xff0c;那么你很难测试出线上真实发生的路径&＃xff0c;从而导致 bug 的发生。
2. **从别人的 bug 中吸取经验。**不要在别人出 bug 时幸灾乐祸&＃xff0c;别人出 bug 的时候&＃xff0c;也是你学习的机会&＃xff0c;你可以想象假如这段代码是你来写的话&＃xff0c;你会犯同样的错误吗&＃xff1f;以及你会怎么来设计代码保证不出 bug&＃xff1f;是否可以从别人的 bug 中学习经验防止以后自己出现类似的问题&＃xff1f;
3. **做好动态控制与灰度控制。**这一点往往是发现 bug 之后的救命稻草。在修改线上长久稳定运行代码的时候&＃xff0c;尽可能的预留动态控制&＃xff0c;同时进行灰度上线&＃xff0c;防止上线之后立刻出现大规模的 bug。
4. **熟悉自己负责的产品。**理解产品细节&＃xff0c;可以让你在写代码的时候结合更多的业务场景考虑&＃xff0c;从而避免代码影响到其他业务。另外由于你足够了解业务&＃xff0c;你能更好的评估产品经理提出的需求是否合理。往往不合理的业务需求也是产生 bug 的导火索。别低估自己理解产品的能力&＃xff0c;你也许是最了解产品的那个人。
5. **谨慎对待紧急需求。**通常越是紧急的需求越容易出 bug&＃xff0c;由于思考的时间太短&＃xff0c;评估不充分&＃xff0c;又缺乏测试&＃xff0c;匆忙上线之后经常会出问题。面对这种紧急需求&＃xff0c;越要谨慎评估。即使是很小的修改&＃xff0c;能配合动态配置的也尽量加一个配置&＃xff0c;因为我已经遇到过不少次临时修改了一行代码导致线上出 bug 的问题&＃xff0c;说多了都是泪。

别怕出 bug&＃xff01;这是你成为优秀程序员的必经之路。如果你觉得这篇文章对你有帮助的话&＃xff0c;不妨顺手给我点个赞、评论区留言或者转发支持一下呗~ 你的每一次分享都是对创作者最好的激励~

在这里还分享一份收录整理的Android学习PDF&＃43;架构视频&＃43;面试文档&＃43;源码笔记&＃xff0c;高级架构技术进阶脑图、Android开发面试专题资料&＃xff0c;高级进阶架构资料

这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理&＃xff0c;帮助大家在面试季取到一份不错的答卷。

当然&＃xff0c;你也可以拿去查漏补缺&＃xff0c;提升自身的竞争力。

有需要的话&＃xff0c;可以直接 点击这里快速免费获取