软件够快才是真的好

背景

本文原载于 Hacker News，作者 Roden 以第一人称视角探讨了软件速度对用户体验和工程质量的深远影响。文章通过多个亲身使用的软件实例（nvALT、Ulysses、Sublime Text、Adobe Lightroom、Photoshop、Affinity Photo、Sketch、Figma、Google Maps 等），论证了“快速软件即最佳软件”这一核心命题。原文强调：速度快通常意味着软件专注、简洁，而慢速则暗示内部可能存在工程缺陷，甚至动摇用户对软件的信任。

核心内容

作者开篇即表达对快速软件的热爱——无论是功能还是界面，追求“想激活或操作某件事与事情发生之间几乎没有延迟”的轻盈感。快速软件通常更专注，如同优质工具般简单，但速度本身可能是软件中最有价值却最不被重视的资产。快速软件是“顺利融入生活的应用”与“让人极不情愿调用它”之间的分野。

作者使用体验最深的快速软件是 nvALT。这是一款名称古怪、外观平淡的纯文本数据库，附带纯文本编辑器。但它速度极快：瞬间打开，即时出结果。作者十年笔记全部存入其中，打开时光标已在搜索框内，全键盘友好操作。nvALT 与 Simplenote 同步，但作者选择 nvALT 而非 Simplenote 桌面版，因为后者“慢了几毫秒”——足够让人感受到差异，就像 1000 美元的日本园艺剪与 100 美元的普通剪子，都能剪东西，但整天使用的人会体会出区别。

主要写作工具是 Ulysses。它擅长组织较长的写作内容，但有时会卡顿：当作者在 5000 字文章顶部输入时，Ulysses 会因每次按键重新渲染整个文档而跟不上打字速度。“这让我发疯”。虽然组织性和简洁性弥补了偶尔的慢速，但慢速本身“像机器内部看不见的腐烂”，如同令人不快的气味。作者因此对应用的同步能力和数据安全性产生怀疑。速度和可靠性往往被直觉地联系在一起——速度可以成为工程质量的代理指标。应用在简单任务上变慢，可能意味着工程师不是追求极致细节的“挑剔者”，背后可能隐藏着灾难性缺陷。

反例是 Sublime Text。它从未让作者失望，即使处理 5 万行的文件也流畅自如。作者未将其用于完整写作，是因为它在排版、拼写检查、文件组织（无关键词、无法随意排序）等方面不如 Ulysses 精细——Sublime Text 为代码而非文字优化。但 Sublime Text 随着时间推移“越来越快”，这是作者热爱的特质：“软件应该随着时间推移而‘去臃肿’，越优雅，像河石一样被磨光滑。”作者对其工程能力完全信任，因为它始终像一个快速、专注的工具（即使它实际上很复杂），并且随着使用年限增加而变得更快速。

Adobe 系列则相反。Lightroom 和 Photoshop 曾经很快（Photoshop 在 90 年代速度极快，Lightroom 在 2007 年比 Apple 的 Aperture 快得多），但如今功能膨胀导致工程优化不足。Lightroom 成了“瘦长臃肿的团块”，有很多迟钝、缓慢的边角。Photoshop 更是“一条火鸡”——打开新建文件对话框需要数秒（2019 年的电脑上），导出图像快捷键要等 3-5 秒，且每次更新更慢。作者因此花钱购买了 Affinity Photo，纯粹因为速度，尽管仍在为 Creative Cloud 付费（主要用 Lightroom Classic 和 InDesign）。每当不得不打开 Photoshop 时，作者会真实地叹气。

设计工具 Sketch 的成功也部分源于速度。它比 Adobe 同类产品更快、更简单、更聚焦 UX 设计。虽有可靠性问题，但用户愿意忽略，因为它“用起来有趣”。速度可以成为巨大的商业资产——对于人们每天长时间使用的软件，提升 3% 的愉悦感不应忽视。

Figma 是另一个设计工具。尽管基于浏览器，但它快得让作者每次使用时都开心到笑。它感觉就像现代计算机应有的速度——极快，而且“感觉被爱着”。作者认识其工程和设计团队，知道它基于 craft 构建，贴近底层工艺。这种快不仅体现在计算周期上，还体现在用户操作周期上：工具工作得更合理，比如 Figma 的钢笔工具比 Illustrator 的更加理性。

Google Maps 正在经历缓慢死亡的悲剧——被数千次慢速割伤。Google 添加了大量动画，单个好看但整体非常慢。它曾经是快速、专注的工具，现在变得“像牛一样迟钝”。用户退出某些模式（如导航）可能需要点击四五个不同区域并忍受同样多的慢速动画。人们忍受它是因为其数据宝库价值，但信息正被埋在多变的 UI 变体和“总是感觉像是 beta 版”的界面后面。

关键要点

• 快速软件意味着聚焦和简洁，其速度本身是最有价值却最不被重视的软件资产。
• 速度与可靠性直觉对应：应用在简单任务上慢速，常暗示工程中可能存在深层缺陷（如 Ulysses 在 5000 字文档卡顿引发对同步和数据安全的担忧）。
• 慢速破坏信任，让用户怀疑“机器内部看不见的腐烂”；快速则增强信任（如 Sublime Text 十年来越来越快）。
• 软件应该随时间“去臃肿”而非膨胀，理想目标是越用越优雅（像河石被磨光滑）。
• 大公司产品（Adobe、Google Maps）因功能膨胀导致速度下降，为新锐工具（Affinity Photo、Sketch、Figma）提供了崛起空间。
• 速度快可以带来“使用的乐趣”，对于全天候使用的软件，哪怕是 3% 的愉悦提升也不应被忽视。
• 速度不仅是计算机周期效率，更是用户操作周期效率（如 Figma 的钢笔工具比 Illustrator 更理性）。
• Google Maps 因过多动画和繁琐交互正在缓慢退化，但数据价值使其仍被用户忍受。

意义与影响

本文本质上是一篇“软件速度宣言”，其意义超越了个人体验层面。它揭示了当代软件行业的一种常见病态：随着功能不断堆叠，工程团队往往牺牲了核心性能。速度成为被低估的质量指标，而用户对慢速的容忍度背后隐藏着深刻的技术债。

从商业角度看，速度是巨大的差异化武器。新工具（Figma、Sketch、Affinity Photo）通过保持快速体验从老牌巨头手中夺取市场份额，证明了“快”本身就是一种 feature。从工程哲学看，作者倡导“软件应随时间而变轻”的理念，与“持续重构”和“性能优先”的开发文化高度契合。这提醒开发者和产品经理：别让功能靡费毁掉用户对软件最基本的爱——那种“打开它，一切瞬间响应”的愉悦感。慢速不仅降低工作效率，更侵蚀用户对产品工程能力的信任，最终可能导致用户用“投票”（掏钱购买替代品）来离开。