线上bug排查没有思路？ 修复完bug又引入新的bug？ 此篇文章也许会给你一些启发 我目前正在从事软件开发工作,每天都会有各种各样的问题产生，每天也都需要不断地去解决这些问题。有些同学遇到某些软件bug的时候没有排查问题的思路，所以根据网络经验与个人经验总结一篇通用的软件bug排查思路，仅供参考，希望对新手程序员有一点点帮助 读后可能有的收获： 遇到大部分简单问题能够独立的、有理论支撑的排查并解决问题 写作逻辑： 本文通过软件开发过程来分析如果更一般性的修复bug，包括开发前如何引入更少的bug，开发过程中遇到问题，如何描述定位bug？定位bug后如何修复？修复完此bug后如何不引入新的问题？以及bug最终修复后，需要向上级汇报，如何描述此问题？
文章目录
怎么不写bug？
业务需求必须熟悉
核心思想-怀疑一切
需求更改如何应对
怎么不改bug？
怎么把bug定位并解决？
5WHY原则挖掘bug的是否真的解决？
解决方案是否满足最初需求
是否存在其它相关性问题？
解决bug的同时是否引入新的问题？
总结
怎么不写bug？
经常调侃咱们程序员“不是在写bug，就是在改bug呢？”这谁受得了，哪个大佬教我写的代码没有bug可以吗？写的代码没有bug，明白的告诉你不存在的。既然写代码总会有bug，那我少写点bug总可以了吧？这个可以有，下面引入少写bug的一般性思路，本文仅简要介绍，后续专门讨论。
业务需求必须熟悉
一般需求方提出需求都会提出很模糊，这个时候研发人员一般会按照自己的想法来实现需求方的需求，当把实现交到需求方时发现需求方要的不是此功能，程序员们就回去改程序。这种事情经常发生，也是大部分问题引入的