Build things that last

前阵子整理旧硬盘，翻出一个 2016 年写的小工具。它没有依赖，只有一个 HTML 文件、一段不到两百行的 JavaScript，和一个朴素得有些过时的界面。我双击打开它，居然还能正常运行。

那一刻的感觉很复杂。过去几年里，我做过很多“更现代”的项目：更复杂的框架、更漂亮的动效、更完整的类型系统。但它们中的大多数，在新的 Node 版本、新的构建工具或新的云服务定价面前，很快就不见了。

我们这一代开发者太擅长开始了。真正困难的是，让一个东西在热度退去之后，依然值得被维护。

复杂度是有利息的

技术选型时，我们通常只计算“第一次写完需要多久”，却很少计算“未来两年里，它会给我带来多少额外的决定”。

每增加一个依赖，就多了一个需要升级的包；每引入一层抽象，就多了一个需要理解的概念；每接入一个外部服务，就多了一份可能涨价、停服或被收购的风险。这些成本不会在项目启动时出现，它们像利息一样，在之后的时间里慢慢累积。

这并不是说应该拒绝一切工具。框架和库让我们能在更短的时间里完成更多事情，这是真实的收益。问题在于，我们常常为了一些想象中的需求，提前支付了过高的复杂度。

一个只有几十篇文章的博客，真的需要服务端渲染、数据库和一套用户系统吗？一个内部工具，真的需要微前端和事件总线吗？

最好的架构，不是能支持未来所有可能性的架构，而是能让你在当下清楚理解每一行代码为什么存在的架构。

这些年我越来越偏爱“无聊”的技术：纯文本、静态 HTML、SQLite、HTTP、CSS。它们不新，也不酷，但已经被使用了足够久，久到我们知道它们的边界在哪里。

无聊的技术有几个好处：

这并不是保守。恰恰相反，把有限的时间投入到问题本身，而不是不断学习新的工具链，是一种更激进的效率。

我近年写代码时，会经常问自己一个问题：如果明天要把这个模块删掉，需要改多少地方？

如果答案是一大片，说明耦合太深；如果答案是“删掉文件，去掉一处引用”，说明边界还算清楚。

同样的思路也适用于产品功能。每增加一个功能，不只是增加代码，还增加了理解成本、测试成本、文档成本和未来的维护责任。一个长期存在的产品，必然做过很多次减法。

“为删除而设计”不是消极，而是一种对未来的善意。你无法预测两年后的自己需要什么，但你可以让那时的自己更容易做出改变。

互联网行业有一种默认的叙事：快速迭代、增长、退出。但并不是所有东西都需要按这个节奏运行。一个博客可以写十年，一个小工具可以用十年，一段代码可以在没有掌声的地方安静地服务十年。

这听起来不够激动人心，却是我现在更愿意追求的东西。

Build things that last. 不是让它们永远不变，而是让它们在变化中依然有一个稳定的内核；不是追求一时的完成度，而是留下继续生长的可能。

那个 2016 年的小工具，界面已经过时了，代码也谈不上优雅。但它解决了一个具体的问题，并且至今仍然有效。某种程度上，这比很多“更先进”的项目都更接近我心中理想的作品。