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

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

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

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

业务流程

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

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