一个side effect引发的bug

到新公司至少三月了,后边修了些不痛不痒的bug或者定位server端的问题。

明日遭逢个bug把自己困住了,当然最后仍旧在leader带领下形成了定点。那些bug分外有借鉴意义,我的目录是:

0、描述bug

1、定位bug

2、警惕开发进程中的side effect!!

3、为啥我的原则性靶心会打偏?

4、只有写代码才有技术含量吗?

0、描述bug

客户发现自己拍的照片在上传之后地面展现双份。

1、定位bug

其一进程相比较散乱,我会把内部关键点拎出来描述:

在固定bug初期,就意识photo这张表有问题,发现在上传后正常情形下不会有临时纪录,然则在有问题的数据中老是看看阴魂不散的这条临时纪录。

以此时候,发生了一个不胜重大的笔触:找到删除这条临时纪录的地点。

以此对于架构优异的数据库应该不是难题,一般这样的删除操作都会抽象个虚函数。可惜这里不是!此处省略一万字…

又多疑是因此sql硬删滴!好啊,搜索FROM
XXX表这多少个重要字总行吧!卧槽~他甚至是FROM [self
tableName]!我想哭!还好leader比较熟练,他就是不是以此,一语点醒~

好了原则性到删除入口,相比三个版本这些地点是否被调用。

很开森!靠!都被调了~

一股寒风~~咻咻~~

好呢!这相比调的意义吧~我想说这多少个进程着实很麻烦,因为只有平板电脑真机才有视频功用,所以,要翻看数据库还要把真机里的数据库拷贝出来。含着泪水最先了这一个阶段的调节。

结果:十分版本在实施删除临时纪录时,没有删除效果。

卧槽!神马东东!数据库非凡?多线程卓殊?底层库相当?…

在这多少个阶段,我几经思考,竟然选用了数据库相当!尽管真是这么些缘故,那些搜查的成本相当高!我认为自家的脑袋打了下铁!铛铛~~

leader选取查这些删除的纪假诺否能查找到!在代码中写。其实那多少个操作自己也做过,但是是在数据库中一向看。我这多少个手续一定是要的,不过却不经意了先后本身这些条件这些变量。对友好弱弱的失望了……

几经确定,果然查不到!

铛铛~打铁声!我又开头采取是底层库出了问题!幸好叫来了leader。他直觉觉得这多少个切换来另一个数据库了。

入口点等待起!debug!果然!

接下去就是正常的分析了。就在写博客前,找到可以说服自己的根本原因!

2、警惕开发进程中的side effect!!

导致它的根本原因是:同步数据是会把客户的多少个工程都建立相应数据库。可是在既有的数据库封装中唯有单例格局,即一个app中只有一个数据库实例—对应一个database。那么要树立多少个数据库如何做?简单不改动到原来代码的情势就是反复实例化数据库。注意!这里就暴发了side
effect—修改了近期数据库ID。当然这是个上线app,当然做了修正。但是在继续的丰盛效果怎么会知晓那多少个!坑爹!

自省:在筹划初,就应当避免发出side effect!

3、为啥我的稳定靶心会打偏?

正午两顿火锅。开玩笑啦~

3.1.时间分配。应该早些剥离琐碎

3.2.搜索时没有周到

3.3.定位问题,不要神化问题,神一般的题材,我辈是解决不了的。实际些。把可以想的先想了

3.4.debug就是绝对而言实验的过程。我对变量因子的把握还不够谨慎

4、只有写代码才有技术含量吗?

有诸多少人在抱怨写得少。我不觉得。我觉着思路才是最重大的。至少我梦想经过那些类型让自己从未有过经过专业磨炼的脑子更审慎些。

希望:

学sqlite。为何?这一次找bug,为何五回三番会想到数据库底层。就是上下一心怕。所以这一个技术也是要去攻破滴!

图片 1

网站地图xml地图