Best Simple System for Now：当下最优简单系统

背景

本文源自 Hacker News 上的一篇深度技术思考帖，作者以“CTO 朋友”的比喻为引子，探讨了软件开发中长期存在的两难困境：一边是追求快速交付、先赚到钱再说的“左路”务实派，另一边是追求稳健、可持续、避免技术债的“右路”完美派。作者指出，这种二元对立本质上是错误的，并提出了一个被长期忽视的中间道路——Best Simple System for Now (BSSN)，即“当下最优简单系统”。

核心内容

困境：左路 vs 右路

作者的一位 CTO 朋友用清除山路比喻两种开发哲学：

• 左路：用砍刀和蛮力快速清出一条路，粗放但进展快。适合侦察前方地形，但不可持续。
• 右路：修建一条宽阔、平整、坚实的道路，耗时但安全，适合带领大部队前进。

这位朋友在交易公司工作，左路快速赚钱的论点极具说服力，而右路主张构建弹性产品。两边都认为对方做错了：右路担心左路积累技术债；左路认为右路过度工程化、镀金（gold-plating），且往往得到业务经理的支持。

中间道路：BSSN 的定义

Best Simple System for Now 是满足当下产品需求的最简单系统，代码以适当标准编写。它没有多余的、过度设计的代码，一切代码恰好达到所需的健壮性和可靠性，不多不少。

这个名称中的每个词都是精心挑选、相互支撑的。偏离任何一点，就不再是 BSSN。

核心维度拆解

1. for Now（为当下设计）

系统不应以任何方式预判未来。 这与大多数程序员接受（或给出）的建议相悖。程序员倾向于找出通用解决方案（比如“做成规则引擎”或“状态机”），试图一步到位节省后续改造成本。但这种做法依赖于无意识的模式匹配（System 1），而“看清当下真正是什么”需要刻意的系统思考（System 2）。为当下设计正是摒弃模式匹配的诱惑，只关注眼前真实的需求。作者戏称 BSSN 可读作“bison”（野牛），与常见的“shaving yaks”（毫无意义的琐事）形成对比。

2. Simple（简单）

设计时，作者内心有两个自己交战：“聪明的自己”凭借经验预判未来，主张提前抽象、接口、并发算法等；“谦逊的自己”知道预测总是“接近但错误”，建议暂时别动。通常“聪明的自己”获胜，结果要么迁就错误的假设，要么回溯重写。作者 30 多年职业生涯中反复如此。

观察过大量代码库后，作者确信其他人也一样。大量代码充斥着几十年来从未被利用的预测性接口和接缝，为想象中两万并发用户准备的算法却只服务于十二人，为“可扩展”“灵活性”留下的扩展点也许从未被使用，而所有复杂性交织的微妙 bug 却真实存在。

简单是当下的函数：只追求当前需求与约束下的最低复杂度，当需求变化时，“简单”的定义也随之改变。

引用 Antoine de Saint-Exupéry 的话：“完美不是无可添加，而是无可删减。”BSSN 追求这种完美——如果删除某部分而系统仍能完成当下所需，它本来就不该存在。

BSSN 不通过迎合所有未来来达到“面向未来”、“可扩展”、“灵活性”，而是通过极致的简单让它能够在需要时灵活变化。 没有投机接口、没有过于宽泛的数据类型、没有用泛化替代特化。设计高度有主见、刻意狭窄。

作者还引用了 Gall 定律：“一个能工作的复杂系统，必然是从一个能工作的简单系统演化而来。从头设计的复杂系统永远无法工作，也无法通过修补使其工作。” 作者见过无数 3-5 年后走向失败的例子，从企业数据字典到通用工作流方案，再到可点击配置的规则引擎。

3. Best（最优）

保持简单不等于偷工减料。 在任何情况下都存在“正确的方式”，我们可以选择这样做。完美主义者和务实者的共同挑战在于：“正确的方式”是上下文相关的。支撑核心业务功能的代码需要高质量，而一次性脚本则不必如此。BSSN 要求：基于当下的需求和约束，做出最恰当的质量决策，不多也不少。代码的健壮性、测试覆盖、错误处理等都应正好匹配当前场景。

（原文在此处中断，但作者的核心意思已完整传达：Best 强调的是上下文中的最优，而非绝对的完美。）

关键要点

• 反对二元对立：软件开发不必然是非此即彼的取舍——要么快速积累技术债，要么过度工程化。存在第三条路。
• BSSN 三要素：for Now（不预判未来）、Simple（最低复杂度，可随需求变化）、Best（在当前上下文中选择最恰当的正确做法）。
• 警惕通用化冲动：程序员天然倾向于提前抽象、接口、规则引擎等通用方案，这往往导致过度复杂和隐性 bug。应抵制这种 System 1 的模式匹配，训练 System 2 去“看见真正的东西”。
• 简化而非镀金：真正的“完美”是可删减到无可删减，而不是预先填充所有可能。简单系统具有天然的灵活性，能够在需求变化时轻松调整。
• Gall 定律的警示：复杂系统只能从简单工作系统演化而来，不能从零设计。任何试图“一步到位”构建复杂系统的尝试，几乎必然在 3-5 年内失败。
• 质量是上下文相关的：核心业务代码与一次性脚本应该有不同的健壮性标准。BSSN 主张在此刻的约束下做到“刚好足够”，而非一刀切的“最好”。

意义与影响

1. 终结“完美主义 vs 务实主义”的无效争论：当团队花费大量精力争论“该左还是该右”时，BSSN 提供了一个共同认可的标准——所有人都可以问：“这是当下最合适的简单系统吗？” 从而减少内耗。

2. 重新定义“技术债”：不是所有“快速实现”都产生有害的技术债。只要代码是当前需求下的最优简单方案，未来的修改成本就是合理的进化成本，而非无法偿还的债务。

3. 指导实际工程决策：无论架构师、高级工程师还是初级开发者，都可以用 BSSN 原则自问：

   • 这个接口真的有必要现在引入吗？
   • 这个通用处理模块是否可以用特化代码替代？
   • 这个扩展点是为未来准备的幻影，还是当下就要用？
   • 测试覆盖是否恰好满足当前风险的平衡？

4. 组织文化转变：当团队接受“当下最优”的理念，就会更关注需求的“当前真实”，减少对未来不切实际的猜测，降低过度设计的风险。同时，它也要求团队具备足够的重构能力——因为简单系统在未来需要灵活演化，而重构是这种演化的重要支撑。

5. 挑战“最佳实践”的教条：许多“最佳实践”（如面向接口编程、预先设计可扩展性）在 BSSN 视角下可能变成过早优化。它提醒我们：每一条原则都应被上下文审视。唯一不变的原则是：保持简单，直到复杂变得必要。