切身体会设计系统时的前瞻性问题



 这几天遇到用户提出的一个新需求，要求在现有系统的基础上增加一种新的销售模式，其实也算不上新的销售模式，

只不过是由于收货方式有点区别，要在以前的价格基础上做订单时有个调整即可。但是做这种单据可以有几种方式，其中

一种是有采购入库单直接生成的销售出库单，写设计方案时，我就发现了一个头痛的问题，目前系统已经将销售模式写死

了，比如SaleType（1表示正常销售，2表示调拨销售，3表示分销，4表示。。。）。本来这次的需求也属于正常销售的

一种，只是要稍加区别即可。但是现在目前系统在不增加字段或者不进行大修改的情况下相当困难。因为很多系统很多关

联地方都将SaleType写死了，特别是很多报表，对于一个线上系统而言，这样改一番工作量大不说，还有很大的风险。

假如当初将SaleType的设置这样多好啊，比如1--10表示正常销售，11--20表示调拨销售，21--30表示分销，依次划分下

去，我们在系统里写逻辑判断时也用范围判断，比如判断正常销售用1<SaleType<11来判断，当然也可以将范围放得更

宽些，比如1--20表示正常销售。这样的话以后要追加一些新的需求就会方便很多，不需要我们在去加字段，或者对代码

进行很多修改了。所以这次的需求的追加让我意识到了设计时，我们要多考虑些未来可预见发展的需要，当然也要避免

过度设计。如果在项目设计阶段，大家都形成这种共识，以后维护升级也会方便很多。但是更改也是不可避免的，因为

没有哪一个软件系统上线后就不需要变更一种用到最后终结的，如果真是这样的话，我们做IT的恐怕都面临着做完项目就

失业的风险了，呵呵。