代码运行次数
多于读取次数

"Programs are meant to be read by humans and only incidentally for computers to execute." —— 这句话出自Donald Knuth，被无数程序员奉为圭臬。 但今天，我想挑战这个观点的适用范围。

一句被误解的真理 · 起点

让我们从最经典的版本说起：

这个模型很优雅。它告诉我们：不要为了自己写得爽而牺牲后来人的阅读体验。 写清晰的命名、加必要的注释、保持函数短小、避免过度 clever 的技巧。 这些都是好建议。

但它有一个隐含假设：代码会被反复阅读和修改。 而现实中呢？很多代码写完之后，可能几个月甚至几年都不会有人再看一眼。 更重要的是——如果代码根本跑不起来，或者跑起来之后天天出问题， 那么"可读性再好"又有什么意义？

"代码只是实现目标的手段。软件应该有其用途，它应该为用户提供服务。" —— 从 user > maintainer 到 user > dev

优先级层级：从代码到商业 · 进化

让我把这个思维模型的完整进化链展示给你看。每一步进化，都代表一次认知升级：

注意到那个 biz ≈ user 了吗？ 这是整篇文章最令人不安的部分——商业和用户并不总是站在同一边。

常见反模式诊断 · 排雷

有了这个模型，我们可以像医生诊断病人一样，快速识别各种软件开发中的"病症"：

运维的隐性成本 · 觉醒

我花了好一阵子才真正理解"运行"二字的分量。 因为就我的经验而言，很多软件最终都无法真正投入生产环境，至少无法大规模部署。 大多数软件都是基于一些从未经过测试的假设而构建的。

但当你的代码真的在生产环境中跑起来之后，一切都变了：

• 部署不再是 `git push`，而是灰度发布、蓝绿部署、金丝雀发布……
• 监控不只是看日志，而是Prometheus + Grafana + Alertmanager全套组合拳
• 故障响应意味着凌晨三点被PagerDuty叫醒，一边揉眼睛一边查metrics
• 安全审计意味着你要证明你的系统没有被入侵、数据没有泄露
• 停用迁移可能是最难的部分——比上线更让人紧张

"基本上，维持系统可靠运行的长期成本总是远远超过构建过程中遇到的任何不便。" —— Dan McKinley

所以当我说 ops > dev 时， 我是在说：让你的代码能在凌晨两点不出事，比你用上最新的语言特性重要一万倍。

商业现实与道德边界 · 困境

这里有一个很多开发者不愿意面对的事实：

现在市面上有太多软件不关心用户了——要么操纵用户，要么把用户变成产品本身。 作为用户，我连订房间、点餐、搜索信息都会被弹窗广告轰炸； 用Google搜索只能找到一堆SEO垃圾。

我们对"做好工作"的理解，与业内相当一部分人认为的"盈利"之间存在着深刻的裂痕。 这解释了为什么越来越多的软件专业人士感到不安—— 我们接受不了这种价值观的扭曲。

我的立场是这样的：

写在最后 · 行动指南

如果你读到这里，可能会觉得这篇文章有点"丧"。 但我的本意不是让你绝望，而是让你清醒。

清醒地认识到：

• 代码不是目的，是手段。如果你的代码漂亮得像艺术品但没人用它，那你是在写小说，不是在写软件。
• 运维是冰山下的巨兽。在写每一行代码之前，先问自己："这东西上线之后谁来看日志？谁来修bug？"
• 用户才是裁判。不是你的Tech Lead，不是Hacker News评论区，不是你的ego——是那些真正使用你产品的人。
• 商业是约束条件，不是豁免权。你可以为了生存做妥协，但别把妥协当成常态，更别为此沾沾自喜。

最后，送给你一个我在职业生涯中学到的最有用的经验法则：

记住：代码运行次数多于读取次数。
不是因为运行更重要，而是因为只有跑起来，才有人读。