代码写完才是开始：为什么真正昂贵的不是开发，而是把软件一直跑下去
从“代码要好读”，到“代码要活下去”
程序员都听过那句老话：代码写给人看，顺便让机器执行。它的潜台词很朴素——今天图省事写下的一段“天才代码”，未来大概率会变成同事眼中的案发现场。于是，业界慢慢形成了一套共识：别炫技，保持简单，写测试，补文档，尊重后来接手的人。换句话说，维护者比作者更重要。
这篇文章有意思的地方，在于它并没有停留在“可维护性”这个程序员熟悉的舒适区里，而是把问题继续往现实世界推进。作者提出：如果说代码被读得比写得多，那么更接近真相的说法其实是——代码被运行的时间，比被阅读的时间更多。这里的“运行”不是狭义的 CPU 执行，而是软件进入生产环境之后漫长而琐碎的一生：部署、扩容、监控、报警、升级、修复、审计、下线，甚至半夜两点把值班工程师从床上叫起来。
这是一种非常“基础设施化”的思维。它提醒人们，软件不是毕业作品，也不是演示视频里那段流畅无比的点击路径。软件一旦上线，就像一台真正开始载客的电梯，用户不会关心它的内部结构有多优雅，他们只关心按钮按下去有没有反应，门会不会卡住，停电了能不能安全落地。
为什么今天这个观点格外刺耳，也格外重要
过去十几年，软件行业有一个显著变化：开发门槛越来越低，发布速度越来越快，堆技术名词越来越容易。云服务、容器、微服务、低代码、AI 编程助手，把“做一个东西出来”这件事变得前所未有地轻松。可与之同步增长的，不是每个团队的运维能力、架构判断力和业务常识。
结果就是，我们看到越来越多熟悉的技术荒诞剧：流量还没到几千日活，架构先拆成二十个服务；数据量不过一个中型表格，却先上分布式数据库；一个小团队还没搞明白用户是谁，就急着把系统设计成“未来可支撑十亿请求”。这类项目看上去很现代，PPT 上也很性感，但它们往往有一个共同结局：上线难、维护难、定位故障更难，最后团队每天忙着救火，却很少有人能说清楚火是怎么烧起来的。
作者借用了一个硅谷工程圈常见的判断：长期维持系统可靠运行的成本，几乎总是远高于开发阶段遭遇的不便。这句话在今天尤其扎心。因为在 AI 工具加持下，写代码正在迅速变便宜，但“把一堆代码变成稳定服务”的能力，反而更稀缺了。Copilot 可以替你补全函数，ChatGPT 可以给你生成接口，但没有哪个模型能替你承担周末故障、数据回滚、版本兼容和合规审计。
所以，“代码被运行得比被阅读得更多”并不是一句文字游戏，而是在给今天的技术行业泼冷水：别把上线当终点，真正的账单，通常是从上线后才开始寄来的。
用户第一还不够，运维视角被低估太久了
很多团队已经意识到“技术不能自嗨”，也会把“用户导向”挂在嘴边。作者也承认，在他职业生涯前半段，自己接受的主流训练就是：用户比开发者更重要。软件是为人服务的，尽早把产品交到用户手里，持续听反馈，比闭门造车要强得多。
这当然没错。但文章最犀利的一刀，恰恰切在这里：用户重要，不代表运维不重要；能用，不代表能长期稳定地用。很多产品在发布会、评审会、甚至投资人面前都表现得像模像样，可一到生产环境就原形毕露。监控没有埋全，日志不可检索，部署流程靠口口相传，配置散落在不同机器上，权限边界模糊，故障恢复完全靠“记得上次谁修过”。
互联网行业有个流传很广的段子，叫“works on my machine”——在我电脑上明明是好的。它其实不是笑话，而是一种组织病。软件如果不是由负责值班、报警和事故复盘的人来约束设计，系统就会自然朝着“开发方便、运行痛苦”的方向滑去。也难怪后来 SRE、平台工程、DevOps 这些概念会被反复强调，本质上就是要把“上线后的生活”提前带回开发阶段。
这让我想起很多公司在微服务上的教训。微服务本来是大规模组织协作下的一种工程策略，不是创业团队的成人礼。但现实里，它常被误解成“高级架构”的代名词。最后一个五六人的团队，要维护服务发现、配置中心、链路追踪、消息队列、网关、容器编排，活像一支只有三个人的交响乐团，偏偏给自己搬来了整套歌剧院设备。系统当然显得宏大，但值班表也会跟着宏大起来。
软件不只服务用户，它还服务财务报表
文章另一个不那么讨喜、却很诚实的部分，是把“商业”摆到了用户前面。作者说，开发者常默认一个前提：只要软件有用、体验好，组织自然会从中获益。这在很多消费软件和企业软件里大致成立，于是工程师得以躲在一个相对干净的抽象里——我们把产品做好，挣钱的事交给业务部门。
但现实没有这么童话。预算是有限的，截止日期是真的，市场窗口会关闭，投资人要听增长故事，老板要看季度数字，团队还有内部政治。很多决策从纯产品视角看很别扭，可放到公司整体里却说得通。于是我们才会看到那么多令人烦躁的产品设计：层层弹窗、过度引导、故意难找的关闭按钮、无限续费、信息流塞满广告。它们未必让用户更开心，却可能让报表更好看。
作者在文末提到一个很沉重的变化：软件行业越来越难维持“为用户解决问题”这个朴素职业伦理了。很多软件并不真正关心用户，甚至主动操纵用户、消耗用户，把用户本身变成商品。这话听着刺耳，但我们每个人都在日常生活里体会过——订个酒店要先躲开优惠弹层，点个外卖要先分辨默认勾选，开电脑都要被系统推荐内容打扰，就连搜索引擎结果页也越来越像一场信息污染实验。
这其实提出了一个比工程更深的问题：如果“商业优先”已经是行业现实，那么技术人还能守住什么边界？作者给出的答案很克制：承认商业不会永远排在用户后面，但也不能默认商业永远凌驾于用户之上。说白了，程序员不能假装自己与后果无关。你写的是推荐系统还是诱导系统，做的是留存优化还是注意力绑架，区别并不只是 KPI 名称上的修辞。
这篇文章真正击中的，是技术行业的集体幻觉
我很喜欢作者在文中拆解的几类“坏味道”。比如不可维护的代码，本质是作者凌驾于维护者；不好用的软件，是开发者凌驾于用户；“只在我机器上能跑”的系统，是开发者凌驾于运维；而最常见也最荒唐的一种，是“想象中的软件”——项目做了很多，PPT 很漂亮，仓库提交记录密密麻麻，但产品几乎从未真正进入生产环境，或者根本没有用户。
这类“想象中的软件”在过去几年并不少见。风口一来，区块链、元宇宙、AIGC、去中心化社交，大家都能迅速拼出一套技术叙事。问题是，技术叙事不等于真实需求，演示环境也不等于可运营的产品。有些项目不是不能做出来，而是做出来之后，没有人持续使用，也没有人愿意持续维护，更没有清晰的商业闭环。它们看似是软件，实际上更像融资材料的附件。
从这个意义上说，这篇文章的价值，不在于提出了多么颠覆的新理论，而在于它把软件开发重新拉回了一个朴素坐标系：谁在真正承受后果，谁就应该在决策中拥有更高权重。维护者承受烂代码，用户承受坏体验，运维承受系统故障，商业承受资金压力，而当商业过度压榨用户时，整个行业还会承受信任透支的后果。
如果非要给今天的技术行业一个提醒，我会说：别再迷恋“写了什么”，多看看“跑成什么样”；别只谈架构图上的优雅，也要问问告警响起时谁来接；别把用户价值当成口号，更别把商业现实当成免罪符。软件行业真正成熟的标志，不是能更快写出代码，而是能更诚实地面对代码上线后的全部代价。
这也是为什么，我认为这篇文章虽然写的是工程哲学，读起来却像一则行业诊断书。它不提供鸡血，也不兜售工具，只是平静地指出一个常被忽略的事实：代码最重要的阶段，不是被写下来的那一刻，而是它开始在真实世界里承担后果的那一天。