比如就用这次疫情举例: 假设平台是一个火车票 飞机票 或者酒店之类的交易平台,在编码的时候直接根据不同的退款情况,自动计算了需要扣除的费用然后退款,这个退款流程是自动化的,然后出现了这次疫情,功能要求 XX 日期之前不扣除手续费全额退还金额。 这个时候 这种平台应该去怎么操作?是现写代码修改退款逻辑还是通过什么其他方式去实现? 如果说现改业务代码的话,整个链路都需要改,包括和酒店结算的业务逻辑等等,开发加测试,无法立即完成的这个功能上线,需要一定的时间。
上面只是举个例子,主要是想讨论:“需要一个非正常业务逻辑的功能,并且这个功能无法提前预料到。需要尽快实现的情况下,应该去怎么做?”
1
sadfQED2 2020-02-05 08:16:34 +08:00 via Android
稍稍长了点脑子的架构师,都会把手续费这种东西写成后台管理员配置啊
|
2
delectate 2020-02-05 08:27:04 +08:00
临时打补丁,来不及打补丁的截留所有问题订单人工处理。
|
3
815979670 OP @sadfQED2 #1 手续费只是个例子,主要是业务逻辑如果需要改,怎么才能实现快速开发 测试 和上线
|
4
paopjian 2020-02-05 09:23:20 +08:00 via Android
所有的底线都是人工处理,慢也没办法,快速开发的代价就是有不稳定 bug。要快速更新且问题少也只能全体加班了,而且还是单线程
|
5
gamexg 2020-02-05 09:57:21 +08:00 via Android
改退款代码逻辑,
太复杂的话就后台异步人工或程序处理。 |
6
opengps 2020-02-05 10:07:29 +08:00 via Android
来不及修改,就别改,发个公告,疫情结束后,拉取订单详情,统一返还
|
7
AlkTTT 2020-02-05 10:22:02 +08:00
重新实现 service 接口类
|
8
hakono 2020-02-05 10:36:08 +08:00 via Android
系统设计时都无法预料的话感觉没法子,你不可能每一个代码的逻辑点都要考虑今后是否会变更,要怎么才能写得通用。
这次只是个手续费问题可以用单独配置文件解决。如果下次一个判断逻辑要改,想要能动态更改判断逻辑的话,难道把这个逻辑代码单独拎出来保存成配置文件,用的时候搞个动态代码加载吗。。。每个业务逻辑都这么搞不说性能,后面接手的小伙伴估计也会想提刀砍人 |
9
Cbdy 2020-02-05 10:37:37 +08:00
提供人工操作的入口,人工操作兜底
|
10
Zenyk 2020-02-05 11:31:27 +08:00
这个问题是我理解错了吗?
感觉用策略+依赖注入就轻松解决了啊? |
11
uxstone 2020-02-05 14:31:36 +08:00
这种有状态的订单业务, 都会有在各个状态下出异常, 订单作废的逻辑吧
测试人员应该要考虑到这些情况 |
12
ebingtel 2020-02-05 18:36:00 +08:00
加班加点了……
|