关于long、double、BigDecimal在效率、可用性、灵活性等等方面的技术性讨论和测试其实在网上已经很多了，本文也不是打算讨论他们的实现的，其实笔者也曾在很长的职业生涯周期中一度拘泥于此。但是渐渐的，已经对此没有那么的一根筋在乎了，至少从整个决策思路而言。

在涉及到金额或金融的计算中，有些时候为了显示或者严格准确性的要求，很多初级开发会毫不犹豫的选择BigDecimal，毕竟无论是java官方还是教科书都是这么说的。随着开发经验的增加、对性能优化的关注等等各种原因，很多的项目或系统开始从设计上或者架构上或者管理上规定了使用long来代替金额（精确到厘）或者利率（精确到小数点后6位，日利率万3.23），这样可以确保支持的金额足够大、精度足够高，而且服务端性能上而言，比BigDecimal高几十倍，所以不少项目就这样用了long。

但是，有很多的系统/项目（其中有不少系统/项目组甚至是赚的盆满钵满）才不管什么性能，统一规定金额、价格、利率等一律使用BigDecimal，至于会慢一些，开发不care、负责赚钱的部门经理更加不care，毕竟BigDecimal足够的灵活，灵活到任何时候要想什么精度只需要更改一个统一的filter即可，数据库不需要事先精确的规定必须多少位、事后要调整也完全可以向后兼容，代码里面不需要关心某个地方会不会遗漏了更改，只要结果正确即可。

从纯技术和设计的角度而言，它们可能不是最优的，在技术专家/架构师的角度看来，甚至是可以很大程度上提高的。除非出现明显的问题，通常管理者对此并不关心、他们的领导对此也不关心，只要客户可以接受，大部分的开发产出足够快，就可以了。但是，一旦出现问题，通常这个改动会非常的麻烦，并且总是有一个人能够解决这个问题（这个人可能是客户、也可能是管理者自己、也可能是某个幕后的技术专家/架构师）。

其实这也就是思考点和面的差别，墨菲定律是成立的，但是作为一个管理者，更重要的是在墨菲定律所说的严重后果发生前，你是否已经胜利的找到了接盘者。

long和BigDecimal引发的管理思考