构建能留下来的东西

企业软件的平均寿命大约是十二年。这个数字听起来不短，直到你意识到：它替换掉的系统，往往也是一套十二年前的软件。我们在构建软件时，其实默认它迟早会被替换，而且我们知道这一点。

少数例外值得研究。一套软件活过十年，被用在没人预料到的场景里，并且仍然有价值。它值得研究，不是因为它拥有正确答案，而是因为它对“哪些问题会保持不变”下了不同的赌注。

什么不会变

老得好的系统，通常围绕变化缓慢的东西构建：底层问题领域、用户真实需求、环境的基本约束。老得差的系统，通常围绕变化很快的东西构建：框架、模式、当下的审美。

事后看，这很明显。但在当下并不明显，因为框架和模式总是以“永久问题的解决方案”的姿态出现。REST API、microservice、event-driven architecture，每一个刚出现时，都像是对旧思维的一次永久进步。大多数并不是。它们只是更适合某个特定时刻的约束。当约束变化时，围绕它们构建的系统就变得昂贵。

认识论姿态

我越来越觉得，耐久的软件首先不是技术成就，而是一种认识论成就。最长寿的系统，往往由那些真正不确定未来会发生什么的人构建。他们不是在优化自己预期中的未来，而是围绕这种不确定性来组织系统。

这有很具体的实践含义：

• 保持接口狭窄。你暴露的 surface area 越少，未来承诺维护的东西就越少。
• 偏好 boring technology。不是因为新技术不好，而是因为 boring technology 有历史记录。你知道它在哪里会坏。
• 把会变的部分和不会变的部分分开。业务逻辑通常变化较慢，通向业务逻辑的 interface 常常变化很快。把它们当成同一种东西来构建，会很贵。
• 为后来的人写代码。不是只指注释和文档，当然那些也重要，而是让“为什么”变得清晰。否则很多选择在未来看起来都会像任意决定。

谦逊的问题

为耐久性而构建最难的地方在于，它需要一种短期不太被奖励的谦逊。2035 年还在运行的系统，通常不会看起来像当下 best practices 的完美展示。它不用最时髦的框架。它甚至在发布前就显得有一点过时。

但它有别的东西：它做的事情和底层问题真正需要的东西之间，有非常紧密的对应关系。它能抵抗 accidental complexity 的堆积，而那些为了显得先进而构建的系统，常常被这种复杂性拖垮。

我构建过一些比预期活得更久的东西，也构建过一些没有活下来的东西。回头看，区别几乎总是：我到底有没有区分“我知道的东西”和“我只是在假设的东西”。

耐久的系统，是我松松地握住假设，并据此构建的系统。脆弱的系统，是我确信自己知道未来会怎样时构建的系统。

我通常是错的。那些活过我预测的系统，恰恰是为这种可能性设计的。