关于系统设计灵活性的思考

来源:互联网 发布:java enum getname 编辑:程序博客网 时间:2024/05/16 01:06

       昨天跟项目组内一个小弟因为系统设计灵活性问题进行了一次争论,起因是因为前期设计没有考虑相关连系统可能的业务变化,对开发系统灵活性有些限制。设计是我设计的,开发是小弟做。当时,处于本能反映,和他争论了一番。事后想想,这种都有理由,没有对错的争论没有太大意义,不过思考了两个问题,现在总结了一下:一是思考为什么会这样设计?二是考虑这样设计影响有多大?

       讨论的设计是一个抽数汇总表的设计,简单说:原系统有七种业务,存放在不同的七张表中,需求是要按单位统计这七种业务的业务量情况,汇总表的设计是按单位、日期、七种业务的日业务量用不同的列来保存。讨论的问题是“把七种业务转置成列,如果以后再有新的业务,业务逻辑和展现都需要修改。”

一、为什么会这样设计?

1、开始系统设计时,并没有这张汇总表,系统设计了七种业务交易记录的明细表,这张汇总表开发人员为某一个按业务类型统计使用的。

2、后来考虑到实际交易明细比较大(千万级),考虑统计的性能问题,需要提前汇总,就使用了这个汇总表。

3、关键是具体的系统抽数逻辑处理已经实现,里面计算一些指标也比较复杂,有些功能也是按这个汇总表来开发的,再调整成本有些高。

二、考虑这样设计影响有多大?

1、如果关联系统已增加业务表的方式增加新需求,设计的汇总表需相应加字段、系统抽数逻辑处理(这是避免不了的)、相关按业务类型的展现功能需要处理。但这块工作不是太复杂,抽数、相关功能的核心业务逻辑已经实现,就是加字段的问题。

2、七种业务属于按业务大类进行的划分,业务小类是在各业务表内控制。业务小类部分容易变化调整,但不会对我们系统产生影响,关键是新增大类。这块原关联系统应该是有规划和考虑,不然原系统内部的相关业务统计查询也要做调整。

3、考虑讲这个问题的影响降低,在汇总表中添加业务总量字段,使统计业务总量的分析使用这个字段,这样原系统新增业务大类只会影响到系统抽数逻辑处理和几个按业务类型统计的功能。

     总结:最求完美的系统设计是我们追求的目标,但所谓的完美、灵活、性能是相对的,需要根据项目的实际情况考虑诸多的因素,如时间、成本、需求。另外,工作中也难免出现问题,关键是在出问题的时候,需要考虑影响有多大,如何弥补,将影响控制到最小。





0 0
原创粉丝点击