[原]问题狙击原则

狙击各种问题，不同人有不同的看法，因为其繁琐恼人，有的同学甚至是唯恐避之而不及，虽然可以理解，但却丧失了对于开发深刻认识的机会，毕竟宝剑锋从磨砺出。

这里小结下最近狙击各种问题时候的一些感触，结论放前面：

• 保持冷静，坚定和敏锐的状态，使用强逻辑来发现问题
• 主动增加test case来提升问题出现的概率
• 保持代码的简单整洁，降低问题概率，提升处理问题概率
• 责任让人成长

如果凝练成一个字，便是“勤”了。

保持冷静和逻辑

实际项目中遇到一些同事，在处理问题中不勤于思考和挖掘，总是依赖于一个现场都准备好，或者到了QA可以稳定重现，才能将问题处理掉。

这其实从战斗力的角度来看，其实是比较弱的。

实际大量的情况，我们狙击问题更像是福尔摩斯破案，从已有的蛛丝马迹中推断问题所在，就其本质衡量便是，你到底需要多少线索就能将一个问题狙击掉。

是很少的几条，还是要稳定的重现的这种n多条？

这里我们可以有一个信条：所有问题终究可以被处理掉，没有处理掉，只是我们还没有做到位，尚需努力，你需要保持坚定和冷静。

同时也可以有一个追求，便是如同侦探高手，尽可能少的线索中，运用逻辑来抽丝剥茧，将问题层层聚焦，最后解决。

好的问题狙击者，可以带领多个同事，不停的聚焦，以很高的效率来处理问题。

最近在处理dx12的一些奇怪bug的时候，甚至开启了盲狙模式，虽然没有确切现场（重现概率极低），但是从推理来看，问题就出在某些地方，然后修正上线，问题也解决了。

逻辑的力量！

主动增加test case来提升问题出现的概率

这里举一个好的案例就是，在出现问题的时候，努力去思考如何去增加问题重现的概率。

上周也是一个dx12的gpu crash，它的特点是一旦崩溃，我们拿到的dump也是第二现场，而如果要抓到crash，需要是开启nvidia的aftermath等工具。

然后我们的操作就是在所有QA哪里，包括所有策划哪里以及运营同事哪里都安装上了抓取环境，最后在一段时间的游戏之后，在一个运营同事哪里打出一个现场，最后问题迎刃而解。

可以想象，如果我们只是要求QA来“稳定重现”的话，这个问题可能几个月都解决不了，我们也总要面对一个不稳定的dx12版本，如何去面对玩家呢？

通过尽可能多的test case，则增加了线索，提升了我们的开发效率。

保持代码的简单整洁，降低问题概率，提升处理问题概率

这个在之前的多篇文章说过了，复杂度控制，hold住全场，才是解决问题的真正银弹。

在解决问题的真正痛苦之中，也让不少同事认识到把代码写到“不以善小而不为”是多么重要。

问题带来很多玩家的抱怨，不眠之夜，无所适从，这些东西感受的越深，那么就越能感受到稳健设计的必要性，写出简洁优雅代码的必要性。

责任让人成长

随着项目的开发，结结实实的遇到好几次，是被事情推着走的，作为技术的负责人，最后一道关卡，不再有人能在你背后帮你兜底，也没有“搞不定”这个选项。

这反倒能带来一种伴随冷静的坚决，也是让我很喜欢的，就是深入问题一个又一个的分析和解决，直至最后搞定。

2周前就有一次，在处理树的一个性能问题，经过了一个通宵的硬刚，本以为解决问题，伴随着早晨的阳光回家睡觉去了，然后下午2点多起来吃饭，一看性能报告，还是不行。

距离上线的时间已经很近了，赶忙回到公司，和同事进一步分析和讨论，进而再设计一个方案，然后从5点开始坐下来编程，那其实并不是一个焦虑疲惫的过程，就是一个完全沉浸的过程，等收笔提交，已经晚上十点了，这时候才发现已经非常饿了，于是出去吃了个饭，等待性能报告。

当突破自己成为唯一的选项的时候，突破自己也变得简单了。

回观众多问题，我们可以看到：问题的出现，是一个概率问题，问题的避免和解决也是一个概率问题，我们可以遵循各种优秀的实践原则来降低问题的出现。

同时当问题真正出现的时候，我们可以以“勤”于思考，“勤”于发现的方式和态度来提升解决问题的概率和速度。