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