软件系统也要各司其职

在保险公司中，经常要看的一个指标叫做13个月保费继续率，这个指标的计算相当复杂，因为需要调取15个月之前承保的保单数据，然后再看当前的缴费状况。不仅如此，对于保单来说，会有不下二十种保全操作，这些操作有多种会影响到这个指标，还有这些操作的组合，导致情况会更加复杂。

在公司中，最早的时候，这个指标是在核心系统中计算的，因为那时候公司还没有数据仓库系统。后来有了数据仓库系统之后，就利用数据仓库的能力来计算这个指标了。因为在数据仓库中，会保存历史数据，而且会对那些数据进行加工处理，从而在计算继续率的时候，可以直接取得相关的计算数据结果，而不知什么都从头计算。

而且这样做带来的好处就是，业务部门以此为准即可，不需要从各处取得数据，然后再比较。

有句话是这么说的，如果你有一块表，那么可以说出准确的时间，但是如果有两块表，那么就不知道准确的时间是什么了，如果再多，那么所有的表就都是不准的了，因为有好多个时间的参考值，根本不知道哪个是准确的。

对于公司的继续率指标也是一样，之前有好几个计算继续率的地方，每个地方的算法都不尽相同，谁也搞不清楚哪个才是真正正确的结果，只有在数据仓库中能够计算之后，才有了真正统一的标准。尽管在那之后，抛弃已有的计算方式也经过了很多波折，但是随着不断地沟通，大家还是最终认可了数据仓库中的算法。

然而，最近有传言说要在核心系统中重新计算继续率，这绝对是一种倒退，也是核心系统开发人员的一场灾难。

毕竟核心系统使用的是数据库而非数据仓库，计算这种统计数据并非是它的专长，就好像是拿着一把匕首去砍柴一样，效果怎么会好呢？而且还有可能会损害大家的积极性，就像匕首很快就会崩溃一样。

而且，这样做出来之后，又会有多个标准，到底哪个才是准确的呢？

另外就是严重违反了DRY原则，既然已经有了很准确的继续率值，那么为什么还需要再重新开发呢？而且这样会带来很大的开发成本和维护成本，谁来负责掏钱呢？

而且，现在系统的性能已经比较难堪重负了，而这种统计数据的算法又会非常消耗资源，一旦影响到正常的业务操作，谁来承受这个责任呢？

在工作中，人要各司其职，在软件系统中，各种各样的系统也是一样。