如何说服同事放弃非目的表复用，采用专用表实现EULA用户同意功能？

1. 先拆穿「复用更省时间」的假象，拿明确的工作量对比说话 #

不用空泛讲设计原则，直接列两种方案的实际工作量：

• 同事的复用方案需要做的额外适配：
  • 现有ConstantGroups表缺少EULA必备的版本号、生效状态、强制触发规则、多语言标识等核心字段，新增字段需要兼容原有常量分组的全量业务逻辑，一旦改漏就会影响线上在用的常量配置功能，额外增加的回归测试工作量至少是新表方案的2倍
  • 现有按ClientID返回字符串的接口，根本不支撑「校验用户是否同意当前最新版本、多版本EULA回溯」的核心逻辑，就算复用表结构，这部分业务逻辑还是要从零开发，和新写接口的工作量完全一致
  • 后续EULA如果要迭代功能（比如增加自定义同意条款、到期自动重签规则），在ConstantGroups表上改要反复兼容老业务，每次迭代的额外成本只会越来越高
• 你的新表方案的实际工作量：两张表的DDL编写+基础CRUD接口开发撑死2个工时，完全独立不用兼容任何老逻辑，测试范围仅覆盖新功能，实际总耗时比复用方案更少

2. 列清楚复用方案的不可承受风险，责任共担的前提下没人会选高风险选项 #

• 业务排查成本爆炸：ConstantGroups原本是常量配置底层表，后续只要该表的逻辑有调整（比如加软删、修改查询规则），EULA功能会毫无预警地出问题，排查时没人会第一时间想到常量配置表还承载了用户协议业务，问题排查时间至少翻3倍
• 合规风险不可控：EULA属于法律层面的有效凭证，同意记录和协议内容如果和普通业务常量存在同一张表，一旦出现误删数据、脏数据写入的情况，丢失法律凭证的责任整个团队都担不起
• 维护成本长期居高：后续新同事接手业务，看到ConstantGroups里存了EULA数据完全不符合预期，理解成本、改bug成本都会成倍增加，违反单一职责的设计原则带来的债早晚要还

3. 给台阶降抵触，主动承担核心工作量 #

如果同事还是纠结那点开发时间，可以主动提你来承担新表方案的核心开发：你负责写数据库DDL、EULA版本校验、同意记录存取的核心接口，对方只需要对接前端逻辑即可，把对方的工作量降到最低，大部分人都不会拒绝。

内容的提问来源于stack exchange，提问作者Olav Gausaker