如果你想快点前进，如果你想迅速完成，如果你希望你的代码易于编写，那就让它易于阅读。——Robert C. Martin
—读完这句，什么在心中回响？
速度背后的反常识
Robert C. Martin 这句话看似矛盾：想更快前进，竟然要先让代码“慢下来”，多花心思去写得清楚易读。然而进一步看，这恰恰指出了软件开发中最常见的误区——许多人把“尽快写完”误认为“真正高效”。实际上，仓促堆砌的代码常常会在后续调试、修改和协作中成倍地消耗时间。 因此，代码的可读性并不是美化门面，而是加速整个开发流程的基础。正如 Martin 在《Clean Code》（2008）中反复强调的那样，代码首先是写给人看的，其次才是给机器执行的。当人能迅速理解代码意图时，开发、测试与迭代都会自然提速。
代码首先服务于人
进一步说，机器并不在乎变量名是否清晰，也不在乎函数是否结构整齐；只要语法正确，它就会执行。但人类阅读代码时，却依赖命名、层次、注释与逻辑组织来理解系统行为。也就是说，代码真正的主要读者往往不是编译器，而是未来的自己、同事，或刚接手项目的新成员。 由此可见，易读代码本质上是一种沟通。就像一本条理清晰的书更容易被读懂，一个命名准确、职责单一的函数也更容易被维护。Martin 的观点延续了软件工程中的经典共识，例如 Fred Brooks 在《The Mythical Man-Month》（1975）里就指出，软件开发的大量成本来自沟通与理解，而不是单纯敲代码。
可读性如何转化为效率
接着看，这句话最有力量的地方，在于它把“可读”与“快速完成”直接联系起来。表面上，重构命名、拆分函数、减少嵌套似乎增加了眼前工作量；但从整体周期看，它们能显著减少错误传播和返工。一个结构清晰的模块，往往能让开发者更快定位问题，也更敢于修改，因为他们知道每一部分在做什么。 现实中的团队对此体会尤深：当某个核心函数长达数百行、分支交错、命名含糊时，每一次改动都像排雷；相反，如果逻辑被拆解为数个意图明确的小函数，新增功能往往只是顺势扩展。于是，所谓“快”，不再是第一次写下代码的速度，而是整个生命周期中的持续推进速度。
易写源于易读
这句名言还提出了一个更深层的判断：如果希望代码“易于编写”，就必须先让它“易于阅读”。初看之下，这似乎是结果与原因的倒置；但事实上，清晰的代码结构会反过来降低编写难度。当系统拥有一致的命名规则、明确的模块边界与稳定的抽象层次时，开发者就不必每次都从混乱中重新摸索。 换言之，易读性会创造一种顺畅的写作环境。正如建筑师在规整的城市网格中更容易规划新道路，程序员在清楚的代码框架中也更容易添加新功能。Kent Beck 在《Implementation Patterns》（2007）中提倡通过小而清晰的表达方式降低设计负担，这与 Martin 的判断形成了自然呼应。
维护阶段才见真正代价
然而，代码的价值并不止于上线那一刻。软件系统真正漫长的部分，通常是维护、扩展和修补。许多项目在初版交付时看似“迅速完成”，但几个月后却因为代码难懂而步履维艰：一个简单修改要花半天确认影响范围，一个 bug 修复又引出两个新问题，这正是不可读代码累积的隐性债务。 因此，易读代码其实是在为未来买时间。Ward Cunningham 于 1992 年提出“技术债务”概念时，就指出某些短期捷径会让后续成本增加。沿着这个思路看，Robert C. Martin 的话并不是风格建议，而是一条工程原则：今天多写一点清晰，明天就少付许多代价。
从个人习惯到团队文化
最后，这句话的意义还超出了个人编码风格，进入团队协作的层面。一个团队若共同追求可读性，就会逐渐形成统一的命名习惯、评审标准与重构意识。这样一来，代码库不再像不同作者拼接的杂乱笔记，而更像一部语气一致、结构清楚的作品，任何成员都更容易参与和接手。 也正因为如此，代码评审中最有价值的问题常常不是“它能不能运行”，而是“别人能不能一眼看懂”。Google 的工程实践文档和众多成熟团队的 style guide 都强调一致性与清晰度，因为它们直接关系到组织效率。归根结底，Martin 这句话是在提醒开发者：真正决定速度的，不是手有多快，而是代码让人理解得有多快。
推荐阅读
作为亚马逊合作伙伴，我们从符合条件的购买中获得佣金。
一分钟思考
这句话给你带来了什么感受？
相关名言
已选2条程序必须为人们阅读而编写，而机器执行只是附带的。——哈罗德·阿贝尔森
哈罗德·阿贝尔森
哈罗德·阿贝尔森这句话把编程的优先级倒了过来：程序首先是一种“给人看的文字”，其次才是给机器执行的指令。机器只需要语法正确、逻辑可运行；但人需要理解意图、推断边界、评估风险，才能维护与演进系统。因而，把代码写得像清晰的说明书一样，往往比追求短小或炫技更能提高整体效率。 进一步说，这种观点并非否认性能或正确性，而是强调在真实的软件生命周期里，“读代码”的时间远超过“写代码”的时间。你今天写下的每一行，都可能在未来被他人、甚至被数月后的自己...
阅读完整解读 →程序必须写给人读，而机器执行只是顺带的。 - 哈罗德·阿贝尔森
哈罗德·阿贝尔森
哈罗德·阿贝尔森这句“程序必须写给人读，而机器执行只是顺带的”，首先把编程的重心从“让计算机跑起来”挪回到“让人能理解”。机器只需要精确的指令，而人需要意图、结构与边界：为什么这么写、假设是什么、如何扩展、哪里可能出错。正因为软件会被反复修改、交接和复用，代码的第一读者往往不是编译器，而是未来的同事、审阅者以及几个月后的自己。 因此，这句话并非轻视执行效率，而是提醒我们：真正昂贵的成本常常在维护阶段。写得可读，本质上是在降低团队沟通成本...
阅读完整解读 →更多作者内容
来自罗伯特·C·马丁的更多内容 →