首先声明,本人所有博客均为原创,谢绝转载!
端午节临近,也总算稍微闲了那么一点,有时间写上一段博文了...
话说四个星期以前,无意中看到老板愁眉苦脸的,并且与技术总监和另一个资深开发的老哥在激烈辩驳着什么,因为好奇心理,就凑上去听了一下.原来是因为老板想做一个报表模块,而且数量不限定,不过暂时需要短时间内做出45张报表,但因为这45张报表的参数,数据表,,数据的计算方式,甚至连格式还有数据的数量都不一致,加上表有月度和季度之分,有些需要查上一年的数据,有些不用,有些只能查5条,有些只能查十条,还有后面因为权限的原因需要一张张表单独授权,导致技术总监和另一个资深开发的老哥认为这些表需要一张张来做.没法快速开发,下面给大家看下其中几个类型
差不多就是这样子.因为听到这个不能快速开发出来,而销售团队那边等着报表系统去推销,所以老板一脸郁闷.
不过我凑上去看了几眼后,发现,不对啊,虽然数据确实不同,但展现方式的表样式的分类其实并不多啊.
于是,大脑里开始疯狂的运转起来.
首先我们确定需求: 需要短时间开发出45张表,并且需要高扩展性,以及高复用性,因为后面会增加表并且也会增加功能(事实证明确实如此),也就是说,我们将代码最大的可复用化并且可配置化以应对扩展以及可能的修改
需求明确好了,我们再明确问题:参数个数不一样,数据表不一样,数据的计算,表格式不一样,权限需要分开,等等不通点导致没法代码复用也就不能够快速开发出来.
ok,需求和问题都明确了,现在只要确定解决方案就行了.
首先面对参数不同,数据表不同这两点后端的问题,我们可不可以在后端定义一些规则带值过去呢?不对,不能带过去,因为这样会暴露我们数据库字段设计,留下安全隐患,那我们就在我们服务端保存一个Map ,key 为当前用户查看的表,value则为那张表需要的字段即可,
但这个问题又引申出第二个问题了,如果带值过去的话,我们现在用的Hibernate能支持这种做法吗?想了下,好像不行,那么只能用可定制化最高的JDBC了,但是JDBC在查询的时候需要明确字段名和类型,字段名我们可以传过去,类型呢?所以我们还需要自定义一个字符串规则来确定字段和字段的类型.
至于像是月还是季度啊,看五条数据还是十条数据这些,通过规则带到前端去即可,把字段和类型则保留在后端.
将全部过程在脑子里全部过了一遍,并且确认可以跑通后,就跟老板说了一句,这个问题我来解决吧,而老板听了我的思路后,也就同意了下来.
Ok,问题解决了,我们来看下具体怎么做的吧.首先为了便于开发,我将这些报表按照展示数据格式的不同分为了五大类
这样在开发好一个表格式后,就不用再一个个表去对这个表的表格式是否已经开发完了,之后开始编码,给个示范的DEMO
其实我这样硬编码传参有一个非常大的问题,就是当我再想要给其中某几张表单独加参数的话,必须要给其它表也加上空参
所以最好的做法应该是使用xml格式定义规则,但说实话,商场如战场,你写的代码是要产生经济价值的,所以我们应该先赶紧把功能做出来,后面再慢慢重构优化,这才是正确的路子.
给大家解释下规则: ;这个符号代表的是每个不同的参数,数据结构中的-代表的是字段名和其类型,=是字段与字段之间的区分,
OK,照着这个思路大家应该知道后端怎么做了吧?继续下一个,我们现在解决了后端的代码复用性,那么前端呢?首先,在这之前,我们要考虑一个问题,前端代码怎么可复用?因为各个表数据的数据结构差异性太大了,导致我们如果用Domain实体类来封装的话,会弄N个Domain,这样前端代码就不可能复用,所以我们要统一格式,不使用Domain实体类,而使用数组(集合)的方式来统一格式.下面是我根据业务自己写的sql解析工具,和jdbc封装工具
因为当时时间很赶,所以代码写的有点急,导致看上去有些乱,大家不要介意哈,不过等业务稳定了后面会花时间重构的.
最后前端代码就可以随便的复用啦
你看,本来这么多张表,还有各种各样的条件,这想起来是个多么大的问题啊,但只要我们确定需求和问题,在顺着问题一个个分化解决就行了,说白了,这个就和追女孩子一样,首先确定目标,再想着追这个女孩子要什么条件,有什么困难,再把这些困难分解成一个个小困难,在脑子里列出来(脑子不好的可以列在纸上),一个个解决.
这样,只要你把无数个小困难通通解决了,不管多么漂亮的女孩你都会追到哒(才怪,除非你长得像我这么帅)
最后,得益于我这种做法,我在这么短的时间里,不但做好了这几十张表,而且还扩展出了,评论,图形展示,权限控制,导出,等各项功能(后面还会加上机器学习将数据报表分析智能化,预警化).如果一张张做的话,可以想象,要每张表都重复写上这些功能,得多.....
好啦,废话不多说,展示下成果吧.(PS:前端除了逻辑外,有很多样式和特效也都是我写的哦)
