今天我遇到了编程中的一件让人棘手的事情,在开发前期需求调研的时候,产品跟我讲了需求,说好了上游过来的数据都是我需要的,不需要考虑其它情况的。我就按照这个需求做了,项目已经开发要完毕了,然后破天荒突然间的发现上游有大量的数据垃圾流向了我。最让人无语的是原先的产品拍拍屁股辞职走人了,我的内心几乎是奔溃的……
然而,问题总归要解决的,在跟新的产品“开撕”了半天后,在组长的提议下,让我代码重构,过滤出这些垃圾数据,于是便开始了一段有趣的编程之旅。
起初,我的sql查询语句是 “select * from user where a = ? and b = ? ……”, 然后在代码中进行相关的业务逻辑,现在突然间发现原本产品的需求设计有问题,有大量发垃圾数据袭击而来,通过我这个查询也顺带查询了许多垃圾数据,造成了系统的混乱。经过组长发提议后,我第一个方案便是在业务层,开始了我的垃圾清理之旅,我的代码逻辑如下:
通过上面的代码逻辑可以看到,我将不符合条件的数据筛选出来了,然后批量删除了,这样就解决问题了。但是,出现了一个尴尬的问题,如下图所示:
从上图可以看出,我通过过滤后查询到的数据只有4条,可是分页工具条却显示我的总数有5条。这是为什么呢?
其实,是因为我在代码逻辑里删除了一条垃圾数据所造成的。心急的我马上跟领导反映了这个bug,可事后去却又觉得自己太过于冲动,如此简单的问题,自己能解决,为什么要提出来呢!
我跟领导反映后,领导给我出了一个主意,就是修改sql语句,级联查询子表,根据查询语句就将垃圾数据过滤掉,这样一来实际数据的数量就可以跟分页插件的总数保持一致了。我接受了这个建议,正当我修改sql语句进行到一半的时候,我突然灵机一动,想到了既然我删除了垃圾数据,总量减少了,那我把分页的总数也跟着减少不就完事了吗!沾沾自喜的我,只加了一行代码就解决了这个问题。
就这样,我解决了前端这个尴尬的bug。但事后我的思维进入了更深层次的境界,就是考虑到了性能优化的问题。从上面的代码可以看出我每次循环都要有一次判定是否为垃圾数据,而且事先需要先创建一个装垃圾的集合对象,而且还要删除它,删除它的底层必定要再次循环,而后再由垃圾回收机制销毁对象,这是很浪费性能的。作为对编程有着执着追求的我,作为一个完美主义的我,决定继续重构代码,寻求优化之路,势必要写出高质量的代码。
再经过一番思量后,我决定继续接受领导的建议,将过滤垃圾的业务逻辑搬到sql语句中,于是我的sql语句编程了下面这个样子:
通过修改这个sql语句后,就直接过滤了垃圾数据。接下来就需要重构我的业务代码逻辑,其实这时候就变的非常简单了,只需要注释一些代码就可以了。
从上面可以看出,我不再需要创建集合,删除集合,也不用每次循环都判定是否为垃圾数据了。如此一来,高质量的代码横空而出了。