事实上，阅读与写作所花时间的比例远远超过 10 比 1。作为编写新代码工作的一部分，我们不断地阅读旧代码。——罗伯特·C·马丁
—读完这句，什么在心中回响？
重新定义程序员的日常
罗伯特·C·马丁这句话首先纠正了一个常见误解：许多人以为程序员的主要工作是持续不断地“写”代码，然而真实情况往往恰恰相反。事实上，在新增功能、修复缺陷或重构系统之前，开发者总要先花大量时间理解已有逻辑、追踪依赖关系，并判断某处改动会引发哪些连锁反应。 也正因如此，编程并不是单纯的创造活动，而更像是一场持续的阅读实践。新代码并非凭空产生，它总是建立在旧代码、团队约定和历史决策之上；换句话说，写作只是显性的成果，而阅读才是背后的基础劳动。
旧代码为何成为真正的工作现场
进一步看，所谓“编写新代码工作的一部分”，本身就意味着开发从来不是在空白纸上作画。大型软件系统往往经历多年演化，代码中不仅包含业务规则，还沉淀了无数关于性能、兼容性和异常处理的现实妥协。于是，开发者在动手之前，必须先进入这些历史层层叠叠的痕迹之中。 这也解释了为什么旧代码常常是真正的工作现场。正如马丁在《Clean Code》(2008) 一贯强调的，软件质量不仅体现在能否写出新功能，更体现在后来者能否读懂、修改并安全扩展既有系统。阅读旧代码，因此不是准备动作，而是开发本身。
可读性决定团队协作效率
既然阅读占据如此高的比重，那么代码的首要品质便不该只是“能运行”，而应该是“能被人读懂”。这一点在团队协作中尤为明显：一个变量命名含糊、函数职责混乱的模块，往往会让接手者耗费数倍时间去猜测作者意图，甚至在误解中引入新的错误。 反过来说，清晰的结构、明确的命名和一致的风格，实际上是在替未来的阅读者节省认知成本。于是，所谓写好代码，本质上就是替别人——也包括未来的自己——写一份易于阅读的说明书。代码不是只给机器执行的指令集，它同样是给人交流思想的文本。
阅读能力塑造技术判断
然而，这句话的意义还不止于倡导代码整洁，它也提醒我们：优秀程序员的核心竞争力之一，是阅读复杂系统的能力。因为只有读得足够深，开发者才可能识别重复逻辑、发现隐藏耦合，并看清一个看似简单的修改为何会牵动全局。相比盲目追求“写得快”，这种判断力更接近真正的工程能力。 从这个角度说，阅读代码有点像医生读病历或律师读案卷：重要的不是浏览过多少页，而是能否从细节中重建背景、意图与风险。也因此，经验丰富的工程师常常把大量时间花在追踪调用链、阅读提交记录和理解上下文上，因为这些工作决定了改动是否稳妥。
从个人习惯到工程文化
最后，这句看似描述事实的话，其实也提出了一种工程文化的要求。既然每个人都要长时间阅读别人留下的代码，那么团队就应该把“便于阅读”视为共同责任，例如重视评审、补全文档、控制函数复杂度，并通过测试来解释系统行为。这样一来，阅读就不再是痛苦的考古，而成为可靠协作的一部分。 因此，马丁的话并不是在贬低写代码的价值，而是在重新排序工作的重心：先理解，再表达；先阅读，再写作。只有当一个团队真正接受这一点，软件开发才会从个人式的即兴创作，转变为可维护、可传承的集体工程。
推荐阅读
作为亚马逊合作伙伴，我们从符合条件的购买中获得佣金。
一分钟思考
这句话暗示了什么小小的行动？
相关名言
已选6条如果你想快点前进，如果你想迅速完成，如果你希望你的代码易于编写，那就让它易于阅读。——Robert C. Martin
罗伯特·C·马丁
Robert C. Martin 这句话看似矛盾：想更快前进，竟然要先让代码“慢下来”，多花心思去写得清楚易读。然而进一步看，这恰恰指出了软件开发中最常见的误区——许多人把“尽快写完”误认为“真正高效”。实际上，仓促堆砌的代码常常会在后续调试、修改和协作中成倍地消耗时间。
阅读完整解读 →代码仅仅能运行还不够；它必须以你为长子命名时同样的谨慎来精心打造。——罗伯特·C·马丁
罗伯特·C·马丁
这句话一开头就划清了一条界线：软件开发的标准，绝不该停留在“代码可以运行”这一最低要求上。罗伯特·C·马丁借由强烈的对比提醒我们，真正有价值的代码不仅要完成任务，还要在结构、命名、可读性与可维护性上经得起时间考验。换言之，功能只是起点，质量才是作品的真正灵魂。 进一步看，这种观点其实是在反对短视的工程文化。许多团队在赶工压力下把“先上线再说”当成借口，但随后而来的往往是调试困难、需求变更成本高昂，以及新人难以上手的连锁问题。因此，这句格...
阅读完整解读 →你应该像给第一个孩子取名那样谨慎地给变量命名。——罗伯特·C·马丁
罗伯特·C·马丁
罗伯特·C·马丁这句话看似夸张，其实是在提醒程序员：变量名从来不是可有可无的装饰，而是代码表达意图的第一语言。就像给第一个孩子取名时，人们会反复斟酌含义、发音与未来影响，变量命名同样需要承担沟通、辨识与传承的责任。 进一步说，代码往往写给人看，其次才是给机器执行。编译器并不在乎变量叫 x 还是 totalOrderAmount，但后来接手的同事、几个月后的自己，却高度依赖这些名字来理解系统。因此，一个随意的名字，常常会把原本简单的逻辑包...
阅读完整解读 →代码能运行还不够。——罗伯特·C·马丁
罗伯特·C·马丁
罗伯特·C·马丁这句话首先提醒我们：软件开发的目标从来不只是“跑起来”。一个程序能够通过编译、完成基本功能，当然值得肯定；然而进一步看，这往往只是交付的最低门槛，而不是质量的终点。正因如此，“能运行还不够”听上去像批评，实则是在把注意力从结果表象拉回到工程本质。 换句话说，真正优秀的代码还必须具备可理解、可维护和可扩展的特性。马丁在《Clean Code》（2008）中反复强调，代码首先是写给人读的，其次才是让机器执行的。也正是在这一层...
阅读完整解读 →首先，解决问题。然后，编写代码。—— 约翰·约翰逊
约翰·约翰逊
这句话强调了编程不仅仅是写代码，而是首先要理解并处理问题。代码的作用是实现问题的解决方案，而不是目的本身。
阅读完整解读 →先设想一个解决方案，然后一行一行地写代码去实现它。——艾达·洛夫莱斯
艾达·洛夫莱斯
这句箴言勾勒出编程的基本轨迹：先在心中完成解法，再以代码逐步显形。它提醒我们，代码并非起点，而是验证设想的工具与轨迹记录。由此，我们自然转向历史，探看这一思路如何在计算的源头被提出并实践。
阅读完整解读 →更多作者内容
来自罗伯特·C·马丁的更多内容 →代码仅仅能运行还不够；它必须以你为长子命名时同样的谨慎来精心打造。——罗伯特·C·马丁
这句话一开头就划清了一条界线：软件开发的标准，绝不该停留在“代码可以运行”这一最低要求上。罗伯特·C·马丁借由强烈的对比提醒我们，真正有价值的代码不仅要完成任务，还要在结构、命名、可读性与可维护性上经得起时间考验。换言之，功能只是起点，质量才是作品的真正灵魂。 进一步看，这种观点其实是在反对短视的工程文化。许多团队在赶工压力下把“先上线再说”当成借口，但随后而来的往往是调试困难、需求变更成本高昂，以及新人难以上手的连锁问题。因此，这句格...
阅读完整解读 →你应该像给第一个孩子取名那样谨慎地给变量命名。——罗伯特·C·马丁
罗伯特·C·马丁这句话看似夸张，其实是在提醒程序员：变量名从来不是可有可无的装饰，而是代码表达意图的第一语言。就像给第一个孩子取名时，人们会反复斟酌含义、发音与未来影响，变量命名同样需要承担沟通、辨识与传承的责任。 进一步说，代码往往写给人看，其次才是给机器执行。编译器并不在乎变量叫 x 还是 totalOrderAmount，但后来接手的同事、几个月后的自己，却高度依赖这些名字来理解系统。因此，一个随意的名字，常常会把原本简单的逻辑包...
阅读完整解读 →代码能运行还不够。——罗伯特·C·马丁
罗伯特·C·马丁这句话首先提醒我们：软件开发的目标从来不只是“跑起来”。一个程序能够通过编译、完成基本功能，当然值得肯定；然而进一步看，这往往只是交付的最低门槛，而不是质量的终点。正因如此，“能运行还不够”听上去像批评，实则是在把注意力从结果表象拉回到工程本质。 换句话说，真正优秀的代码还必须具备可理解、可维护和可扩展的特性。马丁在《Clean Code》（2008）中反复强调，代码首先是写给人读的，其次才是让机器执行的。也正是在这一层...
阅读完整解读 →如果你想快点前进，如果你想迅速完成，如果你希望你的代码易于编写，那就让它易于阅读。——Robert C. Martin
Robert C. Martin 这句话看似矛盾：想更快前进，竟然要先让代码“慢下来”，多花心思去写得清楚易读。然而进一步看，这恰恰指出了软件开发中最常见的误区——许多人把“尽快写完”误认为“真正高效”。实际上，仓促堆砌的代码常常会在后续调试、修改和协作中成倍地消耗时间。
阅读完整解读 →