在处理bug时，你有适合自己的一套降低风险的策略么？
修正一个bug的风险到底有多大？或许，你会说，这要看bug是发生在什么地方，的确，UI层的样式问题、后台逻辑调用层的错误、数据访问层的异常、数据库级别函数或存储过程的修改……一个bug产生的影响可能微乎其微，当然也可能会影响广泛，甚至影响到程序架构！
撇开比较极端的情况，今天想要说的是我们日常工作中遭遇频率最高的一类bug：主要发生在UI层、数据逻辑层的常见bug。对于这种bug，我们又有过多少次因忽略其上下文关联，或者没有添加完整的条件验证和条件处理，导致程序异常，不得不再次修改的经历呢？
这里并不是要批判我们的“粗心大意”，只是要说明这样一个事实：作为一名开发人员，在处理一个bug的时候，很容易因过于关注bug的细节而“忽视”与其关联的上下文；或在没有完全理解原代码工作完整工作机制的情况下就动手修改bug，导致问题层出不穷……相对前者来说，后者的影响更加的广泛，所以，一般情况下，团队Leader都会指派对某功能模块最为熟悉的人员来处理相关bug，这其实就是一种最为常见的减少风险的方法。
根据自己在类似问题上多次碰壁经验来看，最为成熟和有效的方法，其实就是从完善我们自己修改bug的流程开始的！为什么这么说呢？打个比方，老婆昨天去医院拔牙，后来把医生的单据给我看，发现医生也是在按照成熟的流程进行作业的，可见一个相对成熟的流程对于我们处理问题是多么地重要！
回到咱们的主题，处理bug时，我们是不是按照一个自己认为合理的流程进行的呢？我想每个人可能有属于自己的流程，这里仅仅是自己的一点儿看法，仅供参考：
（1） 打开bug列表，你可能使用的是bug tracker或其他bug跟踪工具，这个无所谓。查找你负责的bug项。
（2） 逐条地对bug进行处理，我比较倾向于将当前处理的bug再拷贝一份到自己的bug list文档中，我会添加一些个人的备注，例如，bug的原因，目前的进展，是否需要进行再次验证或与产品经理进行讨论等等，主要是方便自己对bug进行完整的跟踪。
（3） 仔细阅读bug标题和详细内容明细，一般情况下，带注释的截图是非常直观的，个人比较喜欢。如果有疑问的话，需要马上找提交bug的测试人员进行确认，并注意记录发生bug时的关键数据。
（4） 在自己的开发机器上重现bug，起初应该尽可能地按照测试人员提供的关键步骤进行操作，以便迅速重现，如果经过简单分析就可以推断问题的根源的话，可以常识性地进行一些bug验证。
（5） 开启调试功能，重现bug并跟踪代码，找出问题的原因，一般情况下，如果是因对象不存在或赋值错误导致的异常，我们可以直接修正，如果涉及到数据异常的情况，可能我们就需要对产生bug的代码捎带其上下文进行一下排查，因为很有可能是因为数据提供方或者处理方导致了最终的异常。
（6） 确定问题根源，并进行修改后，我们需要进行自我验证！这一步是非常关键的，以至于大家可能很容易忽视!自己也是常常因为觉得一个bug并不难，于是顺手就改了，应该不会有啥问题，然后就check in了，后来的情况大家想必也猜到了，bug被测试打了回来，这还没什么，如果要是需要直接提交给实施或者客户的程序，那后果可就不堪设想啦！这里还有一点需要注意，我们不仅要按照原bug关键步骤进行重复测试，同时还要对相关的流程进行排查性测试，因为我们的修改很有可能影响到周边相关的功能，而当我们对此功能模块不是太熟悉的时候，这种风险尤其大，必须要格外留意。
（7） 再经过上面一步非常重要的自我验证后，我们就可以提交我们的代码了，这里同样有一个很容易被忽略的细节：填写bug备注。因为这是别人了解你此次提交更改的唯一途径，如果马马虎虎，或者是干脆不写的话，那么你的修改出现问题，光追查原因就要浪费很多的时间，如果那哥们如果已经远走高飞以后，那就更加的棘手了！为别人着想也就是为自己着想。
（8） 及时向相关测试人员提供你此次修改的一些情况，尤其是如果涉及范围较大，需要进行排查性验证的时候，一定要向测试人员交待清楚，因为尽管我们做了测试，但依旧有可能有所遗漏。
（9） 定期查看bug列表，跟踪自己负责的bug，并及时更新自己的bug list文档。
以上就是自己在处理bug时采取的一般流程，自从自己将这个流程形成文字后，遇到的因bug修改不完全导致的问题明显减少了，因为这些问题都在自己进行自我测试及排他验证的时候发现了，并在提交之前都进行了处理。以前自己因为这样的情况经常发生，经常会感到非常气馁，也怀疑过自己的能力啥的，后来经过一个做测试的哥们提醒才豁然开朗，每个人都会遇到“焦点关注”的问题，因为过于关注于技术细节而忽视前后逻辑关联，这也是造成这个问题的主因。所以说，自己要努力通过完善合理的流程来减少其造成的后果，而不是盲目地进行否认~
希望能对你有所帮助~
