本周工作思考
- 本周主要是优化点和bug修复为主，bug本身的修复方式方法和提升bug修复效率其实挺值得研究的
首先是问题分析，分析问题前先是要复现问题，最难的bug的找不到复现的规律，也就是我们常说的偶现的bug，排查过很多的偶现的问题，从我的实践经验来说，排查类问题，一定要有一个基本常识：代码里没有幽灵，一切都是代码的问题， 偶现的问题，在某个场景下一定是必现的，一定要找到那个场景， 一切问题都原因，可能多个原因碰在一起了，可能单个在实现的最容易被忽略的代码，而且绝大部分原因是是我们自身代码的使用或者误用引起的，最最困难的问题是多个原因在某一异常场景下串行碰撞在一起，最终出现了一个表现出来的bug。对于偶现的bug更多考验的QA伙伴的专业能力，包括细致的观察能力，敏锐的直觉判断力以及业务逻辑的深刻理解能力，这种专业能力的养成是需要很多的业务积累和长年累月的刻意练习沉淀下来的。对于开发来说，排查一个未知问题，最关键的一点是确定排查方向和分析出最有可能的两三个原因，基本上这两点明确了，bug的修复就是时间问题和成本问题了，那么该如何提升的bug修复的效率呢，这里面需要分析的情况很多，包括bug的级别的认定，投入情况，业务复杂度，实现技术复杂度等等，有些从技术角度来说，不太明确，有些确实需要一些积累，比如灵感，创意，但是我绝大部分的bug的我认为可以使用一些方法或者方法论，可以在整体上提升bug的解决效率。以下几个因素我认为非常影响bug的解决效率：
细节的把握程度，这个细节包括多方面的，比如线上是否有问题，其他账号是否问题，多语下是否有问题，不同的交互操作能不能触发这个问题等等，对细节的把握程度就像你手里的放大镜，你能够对这个问题放大多少倍，越放大，你可以观察的角度，你看到的现象就越多，就越容易看到问题的本质，其实这也是解决很多问题的一个思路，通过深入的观察，分析，多维度拆分，理解来变相的放大这个问题，进而解决。
实现原理和设计细节的理解程度，bug是不正常的存在，所以肯定要知道正常是什么样子，如何是别正常设计的和实现的，特别是基本定问题，在深入分析原因时，原理和设计是心中的地图和导航，这样才能保证自己不在茫茫代码中迷失自己的方向，准确有效找到“病灶”所在，有时候当遇到很棘手的问题或者陷入瓶颈时，不妨从原理出发，从梳理设计开始排查，也许会有全新的思路
业务的熟悉程度，我们有很多问题是业务迭代，模块组合，业务叠加过程中产生的，我很惊叹于代码的神奇，有时候它很像化学反应， 一个模块的代码加上一个模块，不是两个模块，是一个新的模块，而且是全新的功能，这不就是化学反应吗？我们很多bug是这一类的问题，如果你熟悉业务的前因后果，甚至就是你开发的，排查起来会很快进入有效时间，而不是一直在周围排雷了解。在碰到一个bug，对它所处的业务不熟悉时，务必先从了解业务开始，包括啥时候上线，主要解决的什么问题，谁开发的等等，甚至可以找当时需求文档和前后端的设计文档看看，这很重要。
善于观察和直觉，这个没有太多可以说的了，平时积累的多不多，内功深厚不深厚我觉得都会体现在敏锐的观察和直觉准确判断上了。我们得承认一小部分bug，是需要直觉的判断（这个有点不可知论，但是实践上确实如此，从逻辑推断要排查的地方太多了，直觉判断看起来更像是一种专家判断的方法论），找参与过开发的伙伴，找QA伙伴，找熟悉这块业务的伙伴，找你认为可以给你一些思路的伙伴，碰撞一下思路，梳理下你现有的思路，很可能会有茅塞顿开的感觉。