程序必须写给人读，而机器执行只是顺带的。 - 哈罗德·阿贝尔森
—读完这句，什么在心中回响？
一句话点明软件的真正对象
哈罗德·阿贝尔森这句“程序必须写给人读，而机器执行只是顺带的”，首先把编程的重心从“让计算机跑起来”挪回到“让人能理解”。机器只需要精确的指令，而人需要意图、结构与边界：为什么这么写、假设是什么、如何扩展、哪里可能出错。正因为软件会被反复修改、交接和复用，代码的第一读者往往不是编译器，而是未来的同事、审阅者以及几个月后的自己。 因此，这句话并非轻视执行效率，而是提醒我们：真正昂贵的成本常常在维护阶段。写得可读，本质上是在降低团队沟通成本，让系统能长期演化。
可读性就是可维护性的入口
当软件进入现实环境，可读性直接决定维护效率：定位问题、添加功能、重构模块都依赖对代码的理解速度。接着我们会发现，“能运行”只是最低门槛；如果实现方式晦涩，任何小改动都可能引发连锁风险。正如 Donald Knuth 在《Literate Programming》(1984) 倡导的那样，程序应当像文章一样表达思想，让读者先理解“叙事”，再追踪“细节”。 换句话说，代码不仅是指令集合，也是知识载体。一个命名清晰、结构分明的函数，相当于把设计决策公开给团队；反之，隐晦的技巧和过度压缩的表达，会把知识锁进作者的脑中，形成长期的维护债。
机器不缺耐心，人缺
进一步看，机器执行代码从不抱怨：再长的变量名、再多的空行、再清晰的分层，对它而言都是等价的语法符号。人类却会在阅读中迅速疲劳，尤其在故障排查或赶进度时。于是，可读性的价值在压力场景里更突出：凌晨两点的线上事故，读得懂的日志与清晰的错误处理路径，比“聪明”的一行流式链式调用更救命。 这种差异解释了阿贝尔森的优先级排序：为了机器而写的代码往往追求“最短路径”，为了人而写的代码则追求“最少误解”。当系统规模扩大，误解的累积成本会远超几条指令的微小性能差异。
如何把意图写进代码里
既然代码要给人读，接下来关键是把“意图”显化：用贴近业务的命名替代抽象缩写；用小而单一职责的函数替代巨型过程；用明确的边界条件与错误分支替代隐式假设；用合适的注释解释“为什么”，而不是重复“做了什么”。《The Pragmatic Programmer》(Hunt & Thomas, 1999) 也强调，清晰表达与降低重复能让系统更可靠，因为读者能更快确认逻辑是否符合需求。 更重要的是保持一致性：统一的风格、层次和约定，会让读者把注意力放在业务差异而非格式差异上。可读性并不依赖华丽写法，而来自稳定的结构与可预测的模式。
可读性与性能并不天然对立
最后，这句话常被误解为“只要好看就行”，但阿贝尔森并没有否定效率，而是在强调先后顺序：先让人能正确理解与验证，再在必要处做有依据的优化。很多性能问题其实来自错误的算法或不合理的架构边界，而这些往往能通过清晰的表达更早暴露。等到需要优化时，可读的代码也更易于做基准测试、替换实现与隔离热点。 因此，最成熟的实践是双赢：用可读的默认实现覆盖大多数场景，再把少数关键路径用注释、测试与清晰的抽象包裹起来进行优化。机器最终会执行所有代码，但决定代码能否长期生存的，仍是人能否持续读懂它。
一分钟思考
这句话暗示了什么小小的行动？
相关名言
已选2条程序必须为人们阅读而编写，而机器执行只是附带的。——哈罗德·阿贝尔森
哈罗德·阿贝尔森
哈罗德·阿贝尔森这句话把编程的优先级倒了过来：程序首先是一种“给人看的文字”，其次才是给机器执行的指令。机器只需要语法正确、逻辑可运行；但人需要理解意图、推断边界、评估风险，才能维护与演进系统。因而，把代码写得像清晰的说明书一样，往往比追求短小或炫技更能提高整体效率。 进一步说，这种观点并非否认性能或正确性，而是强调在真实的软件生命周期里，“读代码”的时间远超过“写代码”的时间。你今天写下的每一行，都可能在未来被他人、甚至被数月后的自己...
阅读完整解读 →先设想一个解决方案，然后一行一行地写代码去实现它。——艾达·洛夫莱斯
艾达·洛夫莱斯
这句箴言勾勒出编程的基本轨迹：先在心中完成解法，再以代码逐步显形。它提醒我们，代码并非起点，而是验证设想的工具与轨迹记录。由此，我们自然转向历史，探看这一思路如何在计算的源头被提出并实践。
阅读完整解读 →更多作者内容
来自哈罗德·阿贝尔森的更多内容 →