我近期正在做的一个东西，是维护和扩展一个保险方面的计算引擎。
根据被保险人的年龄，性别，所选产品等的情况，来计算保费，以及保单利益等，最后产生报表(报表在几页到十几页之间)。
这个引擎采用c语言，部署到ios平台和windows平台。
几十种产品，上百个数据表，中间的计算也很复杂。
以前的计算引擎代码，有十几年历史，除了一些数据表外，各种全是硬编码。
近三十万行代码，一旦出错或改动，只能debug。多么痛苦的事情。
而且最近还要改成为另一个国家用的。于是我要做一个重构（除了重用数据以外，其实是推倒重来...）。
目前已经完成主要部分，还有一些正在编程中。
在这里分享一下基本思路。（待续）
一，Engine Calculation (引擎计算部分）
这一部分是这个引擎的核心部分。
因为所有的保费和报表计算部分，都可以用excel来模拟（在我们这里叫做mock up),所以我就做了一个excel的解释执行器。
先把excel转成xml,然后用c语言解释执行。
一段excel转的xml：
<tr>
<td type="double" index="A16"><![CDATA[1.0]]></td>
<td type="string" index="B16"><![CDATA[Accidental Death & Dismemberment]]></td>
<td type="expression" index="C16"><![CDATA[IF($C$7="Y","PP","PW")&"I"&K16]]></td>
<td type="expression" index="D16"><![CDATA[VLOOKUP($C$5&"I"&$D$7&C16&$C$6,sc_premium!A3:E546,4,0)]]></td>
<td type="expression" index="E16"><![CDATA[VLOOKUP($C$5&"I"&$D$7&C16&$C$6,sc_premium!A3:F546,5,0)]]></td>
<td type="expression" index="F16"><![CDATA[VLOOKUP($C$5&"I"&$D$7&C16&$C$6,sc_premium!A3:F546,6,0)]]></td>
<td type="expression" index="G16"><![CDATA[TRUNC(E16*F16/$F$14,4)]]></td>
<td type="expression" index="H16"><![CDATA[ROUND($G16*H$13,2)]]></td>
<td type="expression" index="I16"><![CDATA[ROUND($G16*I$13,2)]]></td>
<td type="expression" index="J16"><![CDATA[ROUND($G16*J$13,2)]]></td>
<td type="string" index="K16"><![CDATA[A]]></td>
<td type="string" index="L16"><![CDATA[]]></td>
<td type="string" index="M16"><![CDATA[]]></td>
<td type="string" index="N16"><![CDATA[]]></td>
<td type="string" index="O16"><![CDATA[]]></td>
<td type="string" index="P16"><![CDATA[]]></td>
<td type="string" index="Q16"><![CDATA[]]></td>
</tr>
这个计算模块已经重构了两次，比较成熟了，经历了10多个保险产品的考验，性能和结果准确性满足要求。
做这个模块时所遇见的问题及其解决方案。
1， 多平台部署时的内存问题。
这个引擎部署在ios上使用时效果很好，但转成dll后部署到windows平台，就会crash.其主要问题在于对string的内存释放时出错。目前虽已经稳定，总觉得string的alloc和释放还有些不规矩。正在考虑用stringtable来整体解决string的alloc和释放。
2， 性能问题
最开始时，这个计算引擎只能把excel表格从头到尾计算一遍来获得结果。
当excel表格很大时（700－1000行以上），整个计算一遍速度就太慢了。可以很明显看到延迟。
现在这个引擎已经能做到局部计算，不用计算全表，只计算所需要的量。根据所求的量的公式，来追溯公式里所需的其他变量（跨表），而其他变量又追溯另外的变量，引起连锁反应而获得此数值。经过这方面的加强，性能有了很大提高。
有些数据的计算，需要大量的相关表格，此时，可以把相关表格的计算结果做成一个表格来使用，就不需要引用那么多表格了。
目前的计算引擎是解释执行的，最近学了一些编译原理，有想法把excel转成汇编语言执行，性能想必又会有提高...
二，Input Data Mapping 和 Output Data Mapping
Input Data Mapping 是把保存在结构体里的用户数据，传递到计算引擎中去。
Output Data Mapping 则是把计算结果传递出来，保存到相应结构体变量，格式化等等规整后，便于传递到服务器端以及报表引擎去。
这一部分别看只是数据的传递，实现起来却是很麻烦的。
实际上我今天还来公司加班，正在对这部分做一次重构。
以前的实现，只是简单的硬编码，写set value/get value的方式，把数据向计算引擎里传，或者传出来。
随着所做的product越来越多（时间紧任务重，半成品的engine也要用上啊），发现了弊病：
1， 每个product大体相同，但set value/get value处却总有些微妙区别，导致要根据产品不同加条件判断，增加输入输出语句。这就又逐渐增加了“垃圾代码”。
2，还有的在输入数据时，还需要engine进行验证，有的要输入整个结构体数组，有的输出时要进行结构体数组的初始化....
林林总总的小而麻烦的地方，导致引擎代码在输入输出部分，补丁片片。
可以想象，一两年后，这里就是个大坑了。
目前正在做的重构是，使用类似hibernate的概念，写一个属性匹配的xml,并动态识别struct的属性，来进行自动的输入输出匹配，与此同时进行属性的验证。
我有时候会用到第三方库，有的因内存或环境限制而不合适，有的很好用。
从头造轮子，可能有以下原因：
1，没有意识到有合适的轮子存在（这个最不应该，是我需要警觉的地方）
2，自己这个轮子需要有太多调整。
3，市面上的轮子太“重”和“胖”了，不适合自己用。
4，运行环境和开发语言等的限制
我在这里面用的parser，不是antlr,但也是借鉴了一个开源代码w3parser,
只因该parser的执行速度很快，错误检查和单步执行做的特别好。是java的，我转成了c，非常好用。
excel转xml,用到java里的很多lib,也很好用。
