测试给我提了个BUG，我发现是开源框架产生的

公司有个财务管理的项目，我负责核心的计算模块。

因为财务管理有很多公式，不仅仅是加减乘除，所以引用了很多数学公式。如MAX，MIN，IF，AND，OR，ROUND等等。

例如:

#平均日工资# = (#基础工资#+#工龄补贴#+#职称补贴#+#绩效工资#)/21.75

#职业技能补贴# = IF(#专业技术#=\"初级\",40,IF(#专业技术#=\"中级\",70,IF(#专业技术#=\"高级\",100,0)))

引用apache-poi巧妙解决复杂公式的计算

一般的加减乘除，还是很容易实现的，但是像上面的公式，基本上处理起来的就比较棘手了。

为啥我会想到用apache-poi呢？

最开始我参加工作的时候，在一家金融公司，报表特别多，所以使用过apache-poi解析过Excel文件。

这时候，我想它既然支持解析Excel，那肯定支持解析公式啊。不过像#基础工资#可不能直接解析，那就将公式里每一项都计算出来，然后再带入到#平均日工资# =(#基础工资#+#工龄补贴#+#职称补贴#+#绩效工资#)/21.75,2，

例如:#平均日工资#=(10000+100+500+1000)/21.75,2

这样不就得到平均日工资了嘛，我为自己的智慧深深地折服。

另外，JEP也可以做复杂公式的计算，不过用起来很鸡肋，尤其计算用浮点数竟然用double，精度丢失啊兄弟们有木有。

我在设计模式-解释器模式这一篇博客里，提及过JEP，有兴趣的可以去看下

出现问题

这个项目靠着我的设计稳定运行，财务是不容许出现小错误的。

可是在前天，测试告诉我。平均日工资在使用ROUND函数，保留两位小数时，出现了小小的问题。就是平均日工资为整数时，只保留了1位。如下图:

把说它是个BUG或者问题，其实也不算，因为计算的数值是正常的；只是整数保留小数点后几位，效果都一样。

例如:3088.00 , 3088.0和3088都是等价的，并且ROUND函数在Excel使用时，也无法保留整数的小数位。

发现问题

抱着治学严谨的态度，我打开之前写的代码，一顿debug后，发现这个锅是apache-poi框架的，他们对整数处理时，往后面加了个.0

,例如:ROUND(3088.00,2),它会将3088.00转化为3088.0，也会将3088.000转化为3088.0，导致了ROUND函数的精确值并不准确。

我也在Excel做了对比试验，在Excel中使用

ROUND(3088,2)和ROUND(3088.0,2)以及ROUND(3088.000,2)

得到的结果都是3088，这和我们使用apache-poi又不太一样。

提出问题

于是，我就像给他们这个框架提issue，我来到github上，找到开源项目apache-poi。难受的是，这个开源框架没开issue。WTF，什么操作~！！

我就去它的官网上，结果发现他们把问题都放到了stack overflow上，然后写了个Question，链接。

然鹅，没有人理我。

那么问题来了，apache-poi这个框架github上不给提issue,

stack overflow也没人管，那么它到底有没有开源精神~~

另外，我还发现它另一个BUG，等下次更新出来分享给大家，不过看这情况，怕是都要我自己动手解决咯。