作为一名职业程序员，同时也是一名开源创作者, 夸张点说，我解过的bug可以绕地球一圈, 每天写bug解bug几乎是我的日常。
但是，作为一个善于思考和总结的技术up主，我怎么能止步于每天写bug和解bug呢？更何况，人生在世，总得有点追求。既然我不能够阻止bug的产生，那么就让我总结一点bug的修复技巧，让bug消失地更快点吧!
一、bug修复的生命周期
当我们遇到一个bug(问题)的时候，一般我们需要经历如下6个步骤：
- 了解bug。我们首先需要到底出了什么bug，现象是什么，怎样发生的；
- 复现bug。在了解了bug的大致情况之后，我们需要能够找到复现的路径，这就为后面bug的定位提供可靠的依据；
- 定位bug。当有了稳定的复现途径之后，要做的就是打断点、打日志进行调试，来一步一步分析和定位bug，到底是那块代码导致的错误；
- 确认bug。当我们定位到bug出错的地方之后，我们就需要分析这到底是不是bug。如果是bug，那么这个bug出现的根源是什么，到底能不能解决；
- 修复bug。在明确了bug的根本原因之后，下面就需要发挥我们的聪明才智去修复这个bug了；
- 验证bug。并不是每次我们修复完bug之后就可以万事大吉了，此时我们还需要去重现bug以确保bug被真正修复。除此之外，有条件的我们还需要去验证相关场景，以保证修复该bug不会引入其他bug。
以上可以总结为12字方针--"了解、复现、定位、确认、修复、验证"bug。一般在稍微大一点的公司，都会有对应的流程对bug的修复进行流程控制，最终形成闭环。
可以看到的是，其实修复bug只是解决一个bug的6个步骤中的其中一步。很多刚刚参与工作的程序员经常犯的错误就是一遇到bug，就开始漫无目的地看代码或者是上网各种瞎搜索，又或者各种无脑问，最后搞了一圈可能连自己要解决的bug到底是什么都不知道，这样解决bug的效率可想而知。
可能读到这的你此刻非常想问：怎样才可以更快地修复一个bug呢？那么下面我就根据上面讲的六个步骤来分别讲解一下对应的技巧。
二、解决bug的艺术
了解bug是解决bug最重要的一步，它直接决定了后面五步执行的效率和质量。糟糕的错误报告和不负责任的问题描述都是埋葬程序员修复bug意志的罪魁祸首。
在了解bug之前，我们需要收集足够的信息，了解它产生的现象、描述、复现步骤、以及解决后的预期是什么等等。那么我们应该怎么做才能更加全面地了解它呢？
下面我给几点建议供大家参考：
1）观察现象
光凭文字说明是无法准确领悟到bug的精髓的。因为每个人思考问题的角度以及文字表达描述都是千差万别的。
如果说这个时候能提供一段出错的视频或者问题截图，又或者能够现场演示错误的话，这样观察现象，然后再结合问题描述之后，一定能够帮助你快速地了解这个bug。
2 ) 询问相关人员
这里你询问的可以不仅限于发现bug的人（一般是测试人员），当然你首先应当询问的还是这个发现bug的人。
这里你需要着重询问bug报告上你觉得迷惑的点，比如出现bug的应用版本、设备型号、bug出现的频率、bug产生的步骤和恢复的途径、bug修复的预期效果等。这里你需要进行刨根问底地询问，因为可能bug发现人觉得一些无关紧要的细节，对你来说却是至关重要的点。
问完发现bug的人之后，我们还可以向bug对应模块的负责人（测试、开发、产品）询问该模块的业务逻辑，说不定能够获取到有价值的信息哦。
3 ) 提供bug报告模板
一份优秀的bug报告模板，可以让程序员直接跳过bug修复的前三步，直接进入到确认bug步骤，从而能够极大地提高bug修复的效率。那么一份优秀的bug报告模板应当具备哪些内容呢:
有了以上的内容之后，相信程序员能够很快地了解这个bug，定位出bug产生的原因并予以解决。
如果你在第一步了解bug中获得了良好的bug报告的话，则此部分可以很容易。你只需要按照bug报告中的bug复现步骤，按顺序操作即可稳定复现bug。
当然，很多时候往往并不是一帆风顺的，即使你手握bug报告，做了非常详细的调查工作，然而bug就是无法复现，那么这个时候我们应该怎么做呢？
1 ）重新了解bug
此时为了能够复现bug，你可能需要回到上一步，重现去了解bug。因为你之前对bug的理解可能产生偏差，又或者你第一步并没有做好才导致了bug未能复现。这个时候带着疑问去重现了解bug，可能你会发现新的大陆。
2）将偶现bug转为必现bug
偶现bug算是bug家族中最调皮的一个了。它们以没有规律，难以复现等特性，经常能把一个好好的程序员给逼疯。
但是既然是要复现bug，那么肯定要找到bug稳定复现的路径，这样才能方便下面bug的定位。这里我推荐大家的一个做法就是想办法把偶现的bug转化为必现的bug。因为即使是偶现的bug，很多也是特定条件下必现的bug，只不过此时你还没发现这个特定条件而已。
那么怎样才能将偶现bug转为必现bug呢？这里我简单介绍一下我常用的技巧：
- 对比法：观察并对比复现和不复现的各方面条件，找到那个必现的特定条件；
- 注释（删除）代码法：对怀疑的代码进行注释（删除），直到彻底将偶现bug转变为必现bug。
这一步可以说是解决bug的关键环节，这一步骤的难易程度一般取决于以下几个因素：
- 程序员自身的代码量（工作经验）；
- 对项目代码（业务）的熟悉程度；
- 分析问题和解决问题的能力。
那么我们如何才能更快地定位出bug产生的位置呢？下面我提供一些思路供大家参考：
- 断点调试法。这是程序员通用，同时也是最有效的定位问题的方式。一个不会断点调试的程序员和瞎子没有本质上的区别；
- 排除法。如果一个bug产生的原因可能有多种情况的时候，这个时候采取排除法的方式是最优的。你可以把可能导致bug产生的代码块都打上日志或者断点，然后重现一下bug进行问题的定位；
- 代码回滚法。如果你这个bug在之前的版本是好的，但是在现在版本上又出现了，这个时候就可以使用代码回滚大法。把你的代码回滚到你怀疑的版本，运行看bug是否消失，然后对两个版本之前代码有何区别，最终定位出bug产生的位置。这里我们可以使用二分法来提高代码的回滚效率；
- 注释（删除）代码法。这个我在上一个步骤中也提到过。对于一些难以理解和定位的bug，我们可以使用这个方法进行尝试。不过这个方法使用起来有一定的风险，因为可能你删除的那一串代码虽然能够解决bug，但是却不是bug产生的根源，这个时候你可能会将必现bug改成了偶现bug，让问题变得更加复杂；
- 源码分析法。有的时候有些bug可能并不是你的代码导致的问题。可能是第三方库本身的bug，又或者是系统本身的bug，又或者是你误用api导致的问题，这个时候就需要你拥有源码分析的能力。深入源码中，一层层分析直到最终找到bug产生的原因；
- 联想法。通过一些类似的bug修改经验从而联想猜测出bug产生的位置。这个方法对使用者本身有较高的要求。需要使用者对项目代码和业务逻辑非常熟悉，同时对问题分析的能力有较高的要求。这就是我们常说的牛人能够一眼就能看出问题，他们常用的就是这种方式；
- 场外支援法。这是实在定位不出bug才采取的下下策。因为它并不能提高你定位bug的能力，同时请别人帮忙定位bug，你就需要把你之前所做的工作都要全盘地向他表述一遍，这样不仅会降低bug修复的效率，同时还不一定能保证定位出bug产生的位置，它取决于你表述问题的能力和帮你的人分析和解决问题的能力。
这一步可以说是bug修复6个步骤中最为关键的一步。这一步直接决定了这个bug能否被彻底地解决，同时也是最能体现bug修复艺术的步骤。
但是很遗憾的是，这一步往往被很多人给忽视了。我为什么会这样说呢？因为很多时候我们修复bug的时候，都会受到各方面的限制：
- 自身经验水平的限制：一些初入项目的程序员经常因为修复一个bug而导致了另一个bug，又或者只是看到了bug的表象却不能感知到bug产生更深层次的原因，所以10种产生bug的情况他可能只改了一种，将必现问题改成了偶现问题，让bug变得更加复杂；
- 时间限制：这是我们程序员经常碰到的限制。这在互联网企业非常普遍，通常解决一个bug是有时间限制的，例如：这个项目明天就要上线了，并强制要求你今晚就得想办法解决。这个时候你可能就被逼无奈，采取硬编码的方式去临时把这个bug给按住。其实这样虽然bug是被临时解决了，但是却会让这个bug变得愈加复杂。很多公司出现的那些祖传代码就是在这种情况下产生的，动一下就可能产生无数未知的bug，令人绝望；
- 业务限制：很多时候导致代码逻辑非常复杂难懂的罪魁祸首就是这种业务限制。我们在修复一个bug的时候，很多时候就是因为这种业务的限制，导致bug的修复一种不能从根源上予以解决，只要业务一调整就可能导致这个bug反复地出现。
说了这么多限制，那么我们如何才能找到问题的根源呢？
- 多积累经验，提升自身的水平：这是打破自身经验水平的限制；
- 及时处理bug：在收到bug报告的第一时间就去处理，尽可能打破时间的限制；
- 多熟悉业务：有时间就多去了解和梳理业务，深入研究项目代码。这样我们在解决bug的时候也不会因为对业务不熟悉而无法分析出bug产生的根源；
- 准确定位bug：bug定位的准确性直接决定了你能否分析出bug产生的根源。因此你需要仔细分析和定位bug，使用我上面介绍的8种方式去定位bug。
其实前面的四步都是为这一步所做的铺垫。有了前面四步的工作，相信到这儿也是相对微不足道的了，剩下的就是如何优美地解决这个bug了。
到了这个阶段，bug通常不需要大的修改来修复，因此这一步往往会非常快，当然也就没有什么好的技巧啦。
在这里需要我们着重注意以下几点：
- 重复之前复现bug的步骤来验证bug是否被彻底解决；
- 验证bug修复可能改动到的相关模块是否正常，保证bug修复不引入新的bug。
如果上述有任何一点没有达到的话，请返回步骤四和步骤五，重新修复bug！
三、如何提高bug修复的效率
通过上面对于解决bug的艺术的讲解，我们可以总结出以下影响bug修复效率的几个关键点：
- bug信息收集的效率以及有效性；
- 时间限制的压力；
- 人员对项目代码（业务）的熟悉程度；
- 人员自身经验和分析问题的能力。
以上4点可以说直接决定了bug修复的效率。那么如何才能提高bug修复的效率呢？下面我将一一给出我的看法。
那么我们应该如何建立健全的信息收集机制呢？这里我给出我的几点建议：
1 ）提供优秀的bug报告模板
上文我们在了解bug一步中提到过：一份优秀的bug报告模板，可以让程序员直接跳过bug修复的前三步，直接进入到确认bug步骤，从而能够极大地提高bug修复的效率。
这里我再次重复一步，一份优秀的bug报告模板应当具备哪些内容：
- bug的标题和问题描述；
- 出现bug的应用版本；
- 出现bug的设备信息（型号、版本等）；
- bug产生相关的视频、截图和错误日志；
- bug复现的步骤；
- bug出现的必要条件（环境）和恢复途径；
- bug修复后的预期效果；
- bug对应的模块或者关联bug。
2 ）建立完备的日志体系
在项目的初期，我们可能为了赶工期而常常忽视了日志打印的重要性，这很可能就会导致该项目日后的维护将非常得艰难。
那么我们为什么要建立一套完备的日志体系呢？
- 并不是所有的用户（测试）都能够给你描述清楚bug产生的信息；
- 即使用户（测试）给你描述了bug产生相关的信息，但是他们并不理解你的代码逻辑，他们只能根据bug出现的现象告诉你问题，可能他们的表述和你的理解不在一个频道。
如果你有这么一套完备的日志体系，那么你就可以在用户（测试）不用开口的情况下，直接get到用户的操作行为以及对于的代码逻辑。同时，可能一句关键点的报错日志就可以帮你直接定位到bug产生的位置，从而直接进入第四步确认bug。
说了这么多，我们应该如何打印高效的日志呢？
1）更早地发现bug
很多时候来自时间限制的压力，往往是测试不充分导致的。很多bug直到产品临近上线或者交付的时候才被发现，这个时候唯一解决问题的方式就是在时间上做出限制，无情压迫我们这些活在公司权力最底层的程序员们。
如果这个时候能有一套自动化测试机制，每天下班后都进行自动测试的话，那样很多bug就能被提前发现，从而为我们修复bug预留了不少宝贵的时间。
2 ）节约bug验证的时间
对于一些复杂难解、偶现的bug，我们往往会在确认bug到验证bug之间花费大量的时间。这个时候如果有一套自动化测试机制或者工具帮助我们验证bug的话，就可以极大地缩减我们修复bug的时间。
1 ）建立丰富的知识库体系
那么如何才能建立起丰富的知识库体系呢？下面我给出我的几点建议：
- 对知识进行分类；
- 定期添加和更新知识库的内容；
- 提高知识库的检索效率；
- 定期组织知识的分享；
- 激励贡献知识库的人员。
2 ）建立责任田划分机制
划分责任田的好处：
- 专业的人做专业的事情。划分完责任田后，田主需要对自己负责的模块负责，这就必然要求其对模块内的代码（业务）更加熟悉；
- 责任到人利于追责和bug跟踪。
当然责任田也不是想象中的那么完美，它也存在一定的缺陷：
- 职责明确之后可能导致缺少全局视野。一些复杂的bug可能是几个模块共同作用下才产生的，对于这类bug的定位势必会大大增加难度；
- 划分责任田之后，可能导致踢皮球的情况。
责任田划分机制，它是一把双刃剑。所以是否需要建立责任田划分机制，还是需要结合企业自身的情况而定的。
- 建立公平的员工晋升制度。这样可以充分调动人员的主动性的积极性，提升人员的个人素质和业务能力；
- 建立岗位轮换制度。让人员定期负责不同的模块，可以极大地提升人员的综合素质和全局视野；
- 定期组织培训学习。
四、最后
以上内容，是我参与工作五年，开源六年以来所总结下来的全部经验，喜欢的可以点击收藏或者三连支持一下！最后，还是祝福大家从此代码无bug，哈哈哈！！！
转载请注明出处：https://stgod.com/4761/
