技术方案里的妥协

讨论技术方案时，规则直接写在代码里通常容易被质疑，因为改一次就要重新开发和发布，相比之下，配置化看起来灵活得多。

我曾经在一个动态表单项目里遇到过类似选择。系统需要根据不同客户、业务阶段和用户角色展示不同字段。最初设想是建立一套通用配置，尽量让后续变化不再修改代码。

真正进入实现以后，单纯配置很快遇到了边界。

配置能够描述字段，却难以描述所有关系

字段名称、类型、是否必填和展示顺序，都很适合配置。

问题出现在字段之间的联动，选择一个值以后，另一个字段可能出现、隐藏或改变校验规则。有些字段只在特定流程节点生效，还会受到角色和历史状态影响。

如果继续追求全部配置化，就需要设计条件表达式、变量引用、优先级和冲突处理。配置系统开始拥有自己的语法和执行逻辑，实际上变成了一门小型编程语言。

这套能力并非不能建设，但它的开发、测试和使用成本已经超出当时项目需要解决的问题。

最后我们把稳定、重复出现的字段能力放进配置，结构相似的几类场景用模板处理，业务含义特殊、短期内不太可能复用的联动规则仍写在代码里。

从形式上看，这个方案不如“所有规则都可配置”整齐。它要求维护者知道三种机制各自负责什么，也没有彻底消除后续开发。

但它控制了项目范围，避免为了尚未出现的需求建设一整套规则平台，也让关键业务逻辑仍然能够通过代码评审和测试得到明确约束。

技术方案总是在约束中产生。交付时间、团队经验、业务稳定性和未来变化概率，都会影响选择。

所谓妥协，不应该是“时间不够，先随便做”。有效的妥协需要说明放弃了什么、承担什么成本，以及哪些条件变化以后应该重新设计。

如果选择硬编码，就要明确它适用的业务边界，避免分支散落在各处。配置化需要处理校验、版本和可观察性，模板则要防止复制之后逐渐产生无法合并的差异。

架构设计经常需要考虑未来，但未来需求并不总能准确预测。

为了可能出现的变化提前建设通用平台，很容易得到一套能力很强、实际使用很少的系统。相反，完全忽略未来，也会让下一次扩展只能推翻重来。

更现实的做法，是区分已经反复出现的变化与仅存在于想象中的变化。前者值得抽象，后者可以先保留清楚的扩展位置，而不必立即实现全部能力。

现在回看那次选择，我仍然不会把它称为最优方案。它只是当时条件下能够解释的一种取舍。

至少这次选择里，交付时间和后续维护都要考虑，能把取舍说清楚，比让方案在形式上显得漂亮更有用。