技术方案里的妥协

技术方案讨论中，“硬编码”通常不是一个好词。

它意味着规则直接写进程序，变化时需要重新开发和发布。相比之下，配置化看起来更加灵活，也更接近一套可以长期扩展的设计。

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

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

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

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

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

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

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

我们最终使用了配置、模板和少量明确代码相结合的方式。

稳定、重复出现的字段能力进入配置；几类结构相似的场景由模板承载；少数业务含义特殊、短期内也不太可能复用的联动规则，则保留在代码中。

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

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

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

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

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

每一种灵活性都有自己的维护成本。

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

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

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

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

技术判断的价值，不是永远选出最优雅的结构，而是知道复杂度被放在了哪里，为什么愿意承担，以及什么时候需要重新评估。

如果一个方案只能用“更先进”或“更灵活”解释，往往还没有真正说明它解决了什么问题。