在业务需求下,所有的技术都是沙滩上的一粒小沙子,微不足道

        我们在实际项目开发工作中,数量是个基础却用途广泛的字段,帖子的数量、物品的购买数量、购物单的数量等等随处可见,然而小小字段使用里内含大大的门道。一度让我明白,实际业务场景永远是项目的主角,任何的技术与框架在业务面前就是沙滩上的一粒沙子,毫无作为。
       10年前,我刚刚学会编程后需要毕业设计,思来想去后决定设计一个简单那的购物系统。我在设计购物系统里的购物单对象的时候,习惯的把里面的购物数量的数据类型设计成int。这个小小的举动,形成了我长久以来的编程习惯并且长期以来的工作我都是这么设计的,直到去年的时候。一个机缘巧合之下,我有幸接触到一个ERP系统,改变了我以往一贯的想法并对我造成极大的感触。

       先说一下项目的背景:广东范围内一家医药批发公司的ERP系统,技术框架是老旧的SWING框架,该项目已经实施运行了两年以上的时间,目前处于稳定维护开发中,是一个成功的互联网解决方案实施案例。我有幸参与进去并且作为一位核心的开发人员。在我工作的过程中,发现了一个奇怪的现象并从中学到不少的东西:

       我发现ERP系统里相关业务相关的数量字段的数据类型全部清一色的、毫不例外的都是Double型(且精确到小数点后6位)。当时我非常的诧异,觉得订单的数量为什么会设计成小数,难道订单数量会下0.1的吗?后来我发现是我太无知了,确实会出现并且很正常。原因是这个设计涉及到一个非常重要且敏感的模块,财务结算。具体来说,就是设计到发票的开具场景问题。数量字段设计成Double可以解决发票开具时订单单价与订单总金额的正常显示。

       我们在发票开具的时候,由于订单的总金额超过发票的可开具最大金额数。公司里的发票最常用的是2万元版的,一旦总金额炒作2万元后,就要进行发票分开操作。这个发票分开的操作,遇到保证金额的计算准确问题?为了保证金额的准确,只能在数量这个项里做手脚了,把数量平摊出来,金额保证不变。这样既可以保证计算票面总金额的准确度,又可以不影响阅读。这样做造就了一个奇怪的现象:数量出现小数。所以在ERP系统里关于数量的数据类型一律设计成Double型。

      这个现象看似古怪,以为是个错误,其实相当的合理合情!一个看似笑话的设计,其实背后隐藏一个非常深奥而严肃的道理!

     作为一位程序员,活到老学到老是我们的人生宗旨,永恒不变的定律!我们时时刻刻都要面对未知的挑战,在挑战面前我们不能害怕,要保持谦虚的给出踏实可行的解决方案,这才是我们这份工作的核心!永远不要小看任何一个项目,哪怕这个项目技术又老又旧,规模又小又不起眼!

猜你喜欢

转载自blog.csdn.net/lijinquan2009/article/details/116156421