Bug制造指南

哪个男孩不想亲自造一串儿Bug？

今天，我们已经知道Bug的根本原因是Rayark。

这是万象，确切的说是Sdorica，它的数据有2.5G资源和250M安装包。

当几行烂代码快速轰击Sdorica的进程时，会分裂出另外两个情况——发热和卡顿，并释放内存，以及约 20 行的Error Log。

更刺激的是，长时间的发热可以继续轰击其他进程，引发不断的升温，称为链式反应。

这个反应的威力有多大呢？

一个完全闪退的Sdorica ，就相当于近 20% 的电量损失，足以消耗0.0027度电。

为什么Bug这么难修？

我曾经尝试建设完善的反馈体系，但是很遗憾这项计划没能进行下去。

究其本源，原因有三点：

1、我自身时间不多

2、龙渊心有余而力不足

3、雷亚不配合

下面我们详细介绍这三点对于Bug的直接影响。

一个完整的Bug反馈流程可以简单分为三步。

问题收集、复现验证、更新修复

那么问题出在哪了？

我们根据三点原因来说。

第一点原因：我时间不多，导致我无法在tap实时上报、跟进、整理反馈贴。这就导致了第一步就不顺利。

第二点原因：龙渊心有余而力不足，测试条件、Log精度有限，导致一些罕见、偶现的Bug迟迟不能复现验证。

第三点原因：雷亚不配合，很多情况出Bug的模块并非龙渊所写，必须要请雷亚修复。一旦Bug到了雷亚，进度往往飘忽不定。

有了前面这些基础，就可以解释为什么你反馈的Bug迟迟修不好。

陈年老Bug一般有这几个共同点，“画面、音效Bug”“造成后果不严重”“罕见”“偶现”“雷亚的”。

因为，我会选择性上报“严重影响游戏”“大量出现”的bug。

那你可能会说“你都上报不就解决了？”

回过头看第一点原因你将得到答案。

怎么办？Bug就不修了吗？

答案是“Bug还得修，想解决第一点，只能加大人员投入”

但这仅仅是开始，还有我更难以推动改革的第二第三点原因接踵而至。

修Bug如此麻烦，让我们回归事物本原，谁造了Bug？