M*N个策略造成类爆炸怎样重构？ - 编程一生
内容提要
针对M个三方服务与N种业务组合导致的策略类爆炸问题，文章提出重构思路：先区分重构、重写与重新架构，强调重构应小步迭代；支付部分采用“工作流+策略模式”，将签名、组装、调用、解析等拆成可配置积木块自由组合；整体业务打造接入平台，以自定规范统一接入；重构需预留固定时间，新功能先验证新逻辑，老逻辑灰度迁移，保持简单稳步推进。
延伸解读
重构、重写与重新架构：先分清再动手
文章用搭积木比喻区分三者：重构是渐进调整局部，重写是推倒重来，重新架构是保留可用模块做框架再设计。关键提醒是重构应小步迭代，且与修改量无关；若对外功能不变，重构更稳妥。重写常伴随功能升级，否则难以保证行为一致。这有助于团队在类爆炸时先明确目标，避免以重构之名行重写之实。
支付重构：用工作流+策略模式实现积木化
针对M个三方服务与N种业务组合，文章建议支付部分采用“工作流+策略模式”。将签名、入参组装、下游调用、结果解析等拆成实现统一接口的积木块，不同渠道只是积木块列表不同，且列表可配置化。这样各流程互不干扰，变更影响小、组合灵活。前提是支付要素较易抽象，可围绕网联等监管要求统一。
整体接入平台：规范比技术更关键
文章指出，整体业务复杂在收单，解决思路是打造接入平台，而平台关键不是技术而是自定规范。但规范推行依赖公司影响力：若接入方无规范，自身规范易被接受；若对方是大公司，则可能需按对方规范来，此时可用积木化方法组合适配。这提醒读者评估自身话语权，再决定平台规范的落地方式。
平衡重构与业务：预留时间、新功能验证、灰度迁移
文章建议一开始定好重构目标并分解到每天固定时间，在需求评估时扣除。新功能可作为重构结果的验金石，先在新逻辑上验证，初期影响小；老逻辑迁移需灰度，可按业务或流量百分比逐步切换。总结强调小步快跑、设计与代码重构结伴、命名困难可能意味设计问题、每步足够简单。
Q&A
重构、重写和重新架构有什么区别？
重构是对代码和功能进行渐进式改进；重写是摧毁原有代码重新构建；重新架构是在大框架上做修改和再设计，具体实现模块可能复用原来的。文章用搭积木比喻：重构是调整几块积木让马更好看；重写是推倒重搭；重新架构是画好设计图后拆用原有积木搭新东西。
支付模块策略类爆炸，用什么设计模式重构比较好？
推荐“工作流+策略模式”。定义统一接口Executor，将签名、入参组装、下游调用、结果解析等步骤实现为独立的“积木块”，每个积木块实现execute方法。不同支付渠道的流程通过配置不同的积木块列表（List）来组装，列表可配置在文件或数据库中。这样各流程互不干扰，灵活组合。
如何打造一个统一的接入平台来应对多业务和多供应商？
打造接入平台的关键不是技术而是规范。需要自己制定规范，要求接入方按照规范来。前提是公司自身有影响力，平台有决策权。实际中分两种情况：如果接入方没有规范，容易接受我方规范；如果对方是大公司有自己规范，我方处于弱势，则可采用积木化方法组合适配。
重构和日常需求开发如何平衡时间？
建议一开始就定好目标：什么阶段重构到什么程度，然后分解工作，分摊到每天比如2小时。在需求开发时间评估时就要把这部分时间扣掉，预留固定时间用于重构。
重构后老逻辑迁移到新逻辑，如何降低风险？
首先把新功能当作重构结果的验金石，有新功能先在新功能上验证新逻辑的正确性，因为新功能上线到上量有过程，初期出问题影响小。然后老逻辑迁移需要灰度，可以按业务一个一個灰度迁移，也可以按流量百分比迁移。
重构过程中有哪些实用的原则或建议？
文章总结了几点：1. 小步快跑，稳步迭代；2. 设计与代码的重构结伴而行；3. 如果模块或函数不能想到一个好名字，很可能是设计出了问题；4. 每步要保证足够简单，想象随时可能会停止。
