聊聊你每天是如何修 bug 的

今天改了一天的 bug, 说说心得；

对于需求，我们一般持有的态度是做事的， 不要把自己太当回事，要把自己做的事情当回事，虽然很多的需求在产品经理设计的时候，是很不合理，也不切实现的，但是经过我们逻辑的设计和复盘，就可以达到和好的例子或者模板出来，这也是需求一次次在锤炼我们的同时将， 需求可行性执行下去的一个方面；

对于 bug，我们一般改的还真不是自己出的问题，很大程度上是团队协作的过程中，出现的问题，或者特别小的细节问题，比如对接系统中与其他系统的时间差，有可能差个十分钟，甚至更多；

1.对于问题，先找到出现的地方

然后问自己为什么？

我发现我之前发现问题，之后这个直接是一个系统异常，操作失败，没有一个全局耐心的思考，程序是我们创造用于需求，帮助这个世界解决问题的，所以，我们本质上的工作就是在解决问题。

解决问题的关键就是， 明确问题是什么，（出现的异常情况，具体定位）；

不能说，我解决不了，自己就随便找找，去搜百度，直接去寻找答案，要学会找出根源的问题数据，然后将数据揪出来， 查看数据的为何出现异常，

2.需要做什么，而产生的这个问题？

其实这个是我们解决问题的步骤了：

比如上次测试跟我说，感觉系统时间不一致，操作系统中的数据，查询到的时间感觉老是不对劲，

对于时间这个东西，一般人其实都是不太敏感的，因为从他发现到你理解到这段时间，就已经出现了这个现象，要是直接复现，这个问题还是很有必要的；

比如我在对比商品数据的时候，发现一直 有一个索引添加不成功，不让我创建新的数据，搞得我也疑惑，

通过对于之前索引的知识，他只会在特定的情况下出现，并产生影响；

一般情况下，数据都不会被索引拦住，这个是唯一性索引， 可能大家都在用， 多数用于创建商品，标识唯一性，通过对于商品名称，商品店铺以及归属产品这三个字段做一个唯一性索引，

就可以隔绝大多数的异常数据，

只要符合唯一性索引的数据，才会进入到我们的系统中，

我当时，发现是我因为要添加的索引数据正好是商品标识 oid 的一个字段，不是，因为是对比过后的数据，我把数据存储的时候添加的属性搞换了，那个数据就已经存在了，导致我的数据就进不去了；

从这件事，我就发现，我要是明确问题定位，加上在做什么的时候，发送问题了？

这两件事搞懂之后，bug 已经成功了一半了；

3.根据现有的问题，找寻最佳的解决方案

其实这就是我们解决问题 bug 的第三个步骤，很多人，一上来直接第三步，那样效率太慢了；

互联网上你需要分类过滤的信息太多了，所以尽可能的知晓我们自己的当时🔐遇见的 bug 问题；

比如我今天遇到一个数据导入的问题，显示是 JSON 解析异常，是一个 JSON 文件将数据导入，

但是导入的数据包含集合，普通的属性，然后是一些特殊的属性，对象可以包含一切，但是 JSON 解析的话，一次可能解析不成功；我试过了，还真的不可以；

然后我就去定位，是不是集合解析不成功的问题，我删掉了集合的 JSON 数据，去单纯的直接解析对象，perfet,成功了，这样我就考虑如何将对象中的包含众多属性和集合的 JSON 数据转化成我需要的模板对象；

然后我就单纯的将 JSON 转成 JSONobject， 通过 getArray()，然后根据 stream 流的方式，可以看我上两期的文章，转成 list；

就可以直接将我需要的集合数据转化出来，其他的单个属性数据，按照 jsonobject.getString()

基本都可以拿到数据；

这样就可以完美的解析到你想要的数据，从而进行写库，完美结束。

BUG 的痛点：

1.你根本不知道问题出现在哪里

2.你不知道是因为什么现象，需求所产品的（需要 debug）

3.解决当前问题的方案，这个可以相互讨论

还有一句我感觉比较重要的话，

所有的功能，都是先完善再完美的；

都是经过打磨出来的，好的狙击手都是靠子弹喂出来的，你也应该是 bug 修出来的；

今天的文章就到这里了，我是卢卡，欢迎纠错，我们下期见