在一个高度自动化的平台系统中，如果需要实现一个未预料到的功能应该怎么处理？

[815979670]

比如就用这次疫情举例： 假设平台是一个火车票 飞机票 或者酒店之类的交易平台，在编码的时候直接根据不同的退款情况，自动计算了需要扣除的费用然后退款，这个退款流程是自动化的，然后出现了这次疫情，功能要求 XX 日期之前不扣除手续费全额退还金额。 这个时候 这种平台应该去怎么操作？是现写代码修改退款逻辑还是通过什么其他方式去实现？ 如果说现改业务代码的话，整个链路都需要改，包括和酒店结算的业务逻辑等等，开发加测试，无法立即完成的这个功能上线，需要一定的时间。

上面只是举个例子，主要是想讨论：“需要一个非正常业务逻辑的功能，并且这个功能无法提前预料到。需要尽快实现的情况下,应该去怎么做?”

[sadfQED2]

稍稍长了点脑子的架构师，都会把手续费这种东西写成后台管理员配置啊

[delectate]

临时打补丁，来不及打补丁的截留所有问题订单人工处理。

[815979670]

@sadfQED2 #1 手续费只是个例子，主要是业务逻辑如果需要改，怎么才能实现快速开发 测试 和上线

[paopjian]

所有的底线都是人工处理，慢也没办法，快速开发的代价就是有不稳定 bug。要快速更新且问题少也只能全体加班了，而且还是单线程

[gamexg]

改退款代码逻辑，
太复杂的话就后台异步人工或程序处理。

[opengps]

来不及修改，就别改，发个公告，疫情结束后，拉取订单详情，统一返还

[AlkTTT]

重新实现 service 接口类

[hakono]

系统设计时都无法预料的话感觉没法子，你不可能每一个代码的逻辑点都要考虑今后是否会变更，要怎么才能写得通用。

这次只是个手续费问题可以用单独配置文件解决。如果下次一个判断逻辑要改，想要能动态更改判断逻辑的话，难道把这个逻辑代码单独拎出来保存成配置文件，用的时候搞个动态代码加载吗。。。每个业务逻辑都这么搞不说性能，后面接手的小伙伴估计也会想提刀砍人

[Cbdy]

提供人工操作的入口，人工操作兜底

[Zenyk]

这个问题是我理解错了吗？
感觉用策略+依赖注入就轻松解决了啊？

[uxstone]

这种有状态的订单业务， 都会有在各个状态下出异常, 订单作废的逻辑吧
测试人员应该要考虑到这些情况

[ebingtel]

加班加点了……