配送站站内作业架构升级
原退仓功能，没有单测试，属于历史遗留代码。充斥这个大量的 if else 缺乏业务语意，代码规范混乱维护成本极高，在此
基础上修改产出及低，故需要重构，重构后方案使用清晰，易维护
重构方案：
系统显性的定义产品方案，逆向收货单接单时通过相关属性判断使用那种解决方哪，在退仓作业时通过方哪种方案决定如何
创退仓单，如果打包，是否需要预约等
方案引入 liteflow 轻量级框架，通过强制定义 node 节点来开发出符合单一原则的组件，通过对 Node 编写单元测试，来
实现代码可测试能力
内容:
全物流，仓、CFC 、配送、运输 作业端定时上传蓝牙扫码到的温度信息，实现全链冷链温度跟踪。采集率达到 93%
1、项目新增了容器管理，用于容器与温度采集蓝牙设备的关系。
2、App 温度采集，由于作业端 APP 数据定时上报，将近1万 App 终端。每分钟就会产生 10 万条温度记录。对系统的存储
要求比较高，通过上报时间作为分表键进行分表。
3、 App 采集频率很高，当温度没有变化时记录大量的无用的数据，通过道格拉斯普克算法对历史数据进行抽稀
4、 作业端 APP 改造，作业时校验温度是否超温，如何有超温需要上报异常情况，通过场景分析需求后认为后续还有可能增
加新的操作前值条件，故需要考虑可扩展性，尽量减少 APP 端的发布次数。故与 App 制定了前置检查接口，接口返回 APP
弹窗列表，由服务端定义有多个弹窗，弹窗确认后的动式什么，通过这个设计，连续解决了多个需求的开发，节约了 APP
50%开发时间
业绩:
采集率达到 93%
app 开发减少 50% 开发时间
内容:
履约物流横跨多个团队的应，配送服务在妥投，收货后需要回调履约服务，当履约服务异常时将出现单据状态不一致的情
况。
该组件（pan_task ）为了解决这个问题，组件可以指定数据源，来保证写操作的原子性，业务动作完成后需要写入后，需要
调用 panTask 组件注册一个任务，通过定时任务服务调用，来重试，已达到最终一致的目的。如达到重试上限，将通过报警
通知开发进行处理
业绩:
配送域内，已经全部接入并通过此框架解决，并作为内部开源项目，推动其他域使用
教育经历
利用3年周末时间完成了专升本的学习。带着工作中的种种疑惑，重新学习理论基础学习。解决了工作中的实际问题。受益匪浅