发布时间: 阅读量

记一次复杂的刷卡程序设计

程序层面来说很简单,就是一个springboot单体项目,接受刷卡器的http请求,较为复杂是业务上的判断分支较多,以及对于两个刷卡设备的刷卡怎样标记为一次,还有在出入节点上的逻辑!

怎么判定两条记录为一次通过

从拿到这个项目开始,这个功能的实现就算是一个比较难的点!正所谓会者不难,难者不会!之前也没有接触过这样的业务,其实关键是技术实现!在考虑到现场的实际情况也比较多,比如说入节点机器坏了,只刷了出节点,出节点坏了,只刷了入节点!后续还需人工去补录数据!
考虑了许多场景,还是先从正常的情况出发!进的时候生成一个唯一id,出的时候找最近的一次没有配对过的进记录,拿到入记录的id,生产出记录通过这个唯一id就能知道这两条记录是匹配的!
到这也算是把判定两条记录为一次通过搞定了!
第二天在会上和老大交流了我的想法,他又给我提供了一种方式,记录表新增一个关系字段,这个字段存匹配记录的ID,因为id也是唯一的,A存B的id,B存A的id,这样也能判定这两条记录为一次通过!最后还是用了第二种方式!理由就是:后者匹配就是唯一,前者的唯一id唯一性较复杂!

业务流程

关于业务流程的复杂,之前接触的是整体的业务流程!这个程序的复杂是聚焦到一点,就一个方法,就是整个主流程!类似于我们之前做的pos机的那个交易流程,在交易中要考虑的情况多!(这块是团队大哥负责的,其实大同小异)
WechatIMG589.jpg

因为团队的有限性,对接的需求都是口述,就是说完以后就知道大概干点啥,细节的都是边做边对需求(之前呆过的地方,都有产品,这些东西他们都疏通好了,作为技术就照着产品开发),对个人来说算是一次挑战,就是比较费时间,因为沟通才是工作中最大的成本!