"代码的阅读胜于编写"这句话现在已经是程序员共识，它提醒我们，在编写代码时不能仅追求方便，而忽视那些将来需要阅读和修改代码的人。更一般地说，"代码的阅读胜于编写"传达了一个观点：通过保持代码可维护性，保持简洁、编写测试和文档等方式来使得代码易于理解是一个明智的投资。它关乎对软件开发周期的全局视角。
让我用更简洁的表达方式来表述这个观点：
维护者 > 作者
我认为这种思路可以超越编写代码，并作为一个经验法则用于问题识别和决策。
代码只是达到目标的手段。软件应该有一个目的，它应该为用户提供服务。无论代码是否编写良好、可维护性如何，以及所使用技术是否先进，如果软件不能实现其目标并给用户带来良好体验，则一切都没有意义：
用户 > 维护者 > 作者
或者，既然我们不再需要区分开发人员角色：
用户 > 开发者
因此，与其猜测或询问用户需求，最好的方法是尽早、频繁地将程序放在用户面前，并结合他们的反馈来改进。
这是一个强大的思维模式，只要在开发过程中牢记用户，我们就能走得更远。这大致是我学习这个职业以及我职业生涯前半段对它的理解方式。
当我说"运行"时，我不仅指执行程序，还包括在生产环境中操作它，包括部署、升级、观察、审计、监控、修复和废弃等等。正如丹·麦金利所说：在保持系统可靠工作方面，长期成本几乎总是远远超过你在构建过程中遇到的任何不便。
我们可以将这个观点纳入我们的小模型中：
用户 > 运维 > 开发
我花了一些时间才完全理解这一点，因为根据我的经验，很多正在构建的软件实际上从未真正投入生产使用，至少没有达到重要规模。大多数软件都是基于从未经过测试的假设构建而成。但当你将代码运行在生产环境中时，简洁性原则就有了新的维度。它不再仅仅关乎代码本身，而是关乎减少移动部件并了解其故障模式。它关乎交付产品并确保即使在出现故障时也能正常工作。
我说过，在开发过程中牢记用户可以帮助我们走得更远。这适用于软件对用户有价值且良好运行的假设。对于开发人员来说，这是一个方便的抽象：我们提供优秀、可工作的软件，而业务则负责将其转化为利润。这在消费者和企业软件领域通常有效。但最终，这种抽象会被证明是一种过度简化，并且我们可以从中受益，将一些商业观点纳入我们的工作流程：
商业 > 用户 > 运维 > 开发
最明显的例子就是预算：我们没有无限资源来满足用户需求，所以需要衡量成本和收益。还有市场营销、截止日期、利益相关者和投资者等因素。个人兴趣和政治也会产生影响。某些决策在孤立考虑我们的软件、团队或用户时是合理的，但当考虑整个组织时可能不再合适。有时，我们需要关注能够产生收入的事务，而不是只迎合用户。我将再次回到这个问题。
我们得到了一个小模型，它表达了软件开发中各种因素的相对重要性，或许可以帮助我们看到更大的图景并专注于重要的事情。现在我想看一下一些常见的软件开发功能障碍，并看看它们如何与该模型相匹配。
难以维护的代码
作者 > 维护者
这是我们起点。这是聪明而懒惰的代码变成了意大利面条和鬼屋，这是过早优化，这是只有卡洛斯才能碰触那个模块等等。
不可用的软件
开发者 > 用户
由那些不从用户那里学习或将技术放在第一位的团队制作的软件。过度工程化程序、恶化用户体验的"现代化"、破坏浏览器功能的Web应用等等。
只在我的机器上运行
开发者 > 运维
没有考虑操作问题而设计出来的软件。这是过于复杂、有很多移动部分、为小数据负载设计高级数据库、由单个小团队管理的微服务生态系统。这是过早为规模而架构的软件。这是由与在它出现故障时被叫醒的人不同的人设计的软件。
正确的事情
开发者 > 商业
将代码视为目标本身。这是自命不凡的工匠们、泰坦尼克号上的音乐家和Lisp黑客制作的软件。
以简历为导向的开发
开发者 > *
没有风险，开发人员可以做他们想做的任何事情。
虚构的软件
这是已经构建但很少（或从未）投入生产使用的软件。我称之为虚构的软件。Charity Majors 称之为活在谎言中。
另一种虚构的软件是那些没有用户但具有可扩展性（大规模）的软件。这是无法解决问题或解决错误问题，可能没有人关心问题。这种软件源于采用一些炒作技术并将其应用于所有事物，直到出现模糊地符合某个用例需求。
晚期资本主义
风险投资支持下没有商业模式或其商业模式是增长至垄断然后剥削用户的软件。
如果你还没有关闭浏览器标签，让我总结一下：
商业 > 用户
这个观点可能很难接受。
正如我上面提到的，我学习这个工作时，软件是为最终用户解决问题的。这在《程序员修炼之道》的最后一个提示中得到了总结，该提示说我们的目标是让用户满意，而不仅仅是交付代码。但自从我开始从事程序员工作，并且随着软件变得无处不在，我发现这种假设越来越难以维持。
有很多正在生产的软件根本不关心其用户，或者操纵用户，或者将其变成产品。这不仅限于社交媒体：作为用户，在没有弹窗试图吸引我的注意力之前，我甚至不能预订房间、订购食物或点击Windows开始按钮；在进行谷歌搜索时，我会得到一堆垃圾信息。
我们认为做好工作意味着什么与行业中相当大一部分人认为能够获利是相矛盾的，我认为这解释了许多软件专业人士日益感到不适的原因。虽然我们不能回避对我们领域的经济现实，但也许我们应该更加坚定地站在道德立场上，不伤害用户。承认用户并非始终排在商业之前，但商业也不应无条件地居于第一位：
用户 > 运维 > 开发 商业 > 运维 > 开发 商业 ≹ 用户
原文链接：https://olano.dev/2023-11-30-code-is-run-more-than-read
评论删除后，数据将无法恢复
让代码运行起来，比代码可读性重要
"代码的阅读胜于编写"这句话现在已经是程序员共识，它提醒我们，在编写代码时不能仅追求方便，而忽视那些将来需要阅读和修改代码的人。更一般地说，"代码的阅读胜于编写"传达了一个观点：通过保持代码可维护性，保持简洁、编写测试和文档等方式来使得代码易于理解是一个明智的投资。它关乎对软件开发周期的全局视角。
让我用更简洁的表达方式来表述这个观点：
我认为这种思路可以超越编写代码，并作为一个经验法则用于问题识别和决策。
代码的使用胜于阅读
代码只是达到目标的手段。软件应该有一个目的，它应该为用户提供服务。无论代码是否编写良好、可维护性如何，以及所使用技术是否先进，如果软件不能实现其目标并给用户带来良好体验，则一切都没有意义：
或者，既然我们不再需要区分开发人员角色：
因此，与其猜测或询问用户需求，最好的方法是尽早、频繁地将程序放在用户面前，并结合他们的反馈来改进。
这是一个强大的思维模式，只要在开发过程中牢记用户，我们就能走得更远。这大致是我学习这个职业以及我职业生涯前半段对它的理解方式。
代码的运行胜于阅读
当我说"运行"时，我不仅指执行程序，还包括在生产环境中操作它，包括部署、升级、观察、审计、监控、修复和废弃等等。正如丹·麦金利所说：在保持系统可靠工作方面，长期成本几乎总是远远超过你在构建过程中遇到的任何不便。
我们可以将这个观点纳入我们的小模型中：
我花了一些时间才完全理解这一点，因为根据我的经验，很多正在构建的软件实际上从未真正投入生产使用，至少没有达到重要规模。大多数软件都是基于从未经过测试的假设构建而成。但当你将代码运行在生产环境中时，简洁性原则就有了新的维度。它不再仅仅关乎代码本身，而是关乎减少移动部件并了解其故障模式。它关乎交付产品并确保即使在出现故障时也能正常工作。
此外，还有商业因素
我说过，在开发过程中牢记用户可以帮助我们走得更远。这适用于软件对用户有价值且良好运行的假设。对于开发人员来说，这是一个方便的抽象：我们提供优秀、可工作的软件，而业务则负责将其转化为利润。这在消费者和企业软件领域通常有效。但最终，这种抽象会被证明是一种过度简化，并且我们可以从中受益，将一些商业观点纳入我们的工作流程：
最明显的例子就是预算：我们没有无限资源来满足用户需求，所以需要衡量成本和收益。还有市场营销、截止日期、利益相关者和投资者等因素。个人兴趣和政治也会产生影响。某些决策在孤立考虑我们的软件、团队或用户时是合理的，但当考虑整个组织时可能不再合适。有时，我们需要关注能够产生收入的事务，而不是只迎合用户。我将再次回到这个问题。
反向思考
我们得到了一个小模型，它表达了软件开发中各种因素的相对重要性，或许可以帮助我们看到更大的图景并专注于重要的事情。现在我想看一下一些常见的软件开发功能障碍，并看看它们如何与该模型相匹配。
难以维护的代码
这是我们起点。这是聪明而懒惰的代码变成了意大利面条和鬼屋，这是过早优化，这是只有卡洛斯才能碰触那个模块等等。
不可用的软件
由那些不从用户那里学习或将技术放在第一位的团队制作的软件。过度工程化程序、恶化用户体验的"现代化"、破坏浏览器功能的Web应用等等。
只在我的机器上运行
没有考虑操作问题而设计出来的软件。这是过于复杂、有很多移动部分、为小数据负载设计高级数据库、由单个小团队管理的微服务生态系统。这是过早为规模而架构的软件。这是由与在它出现故障时被叫醒的人不同的人设计的软件。
正确的事情
将代码视为目标本身。这是自命不凡的工匠们、泰坦尼克号上的音乐家和Lisp黑客制作的软件。
以简历为导向的开发
没有风险，开发人员可以做他们想做的任何事情。
虚构的软件
这是已经构建但很少（或从未）投入生产使用的软件。我称之为虚构的软件。Charity Majors 称之为活在谎言中。
另一种虚构的软件是那些没有用户但具有可扩展性（大规模）的软件。这是无法解决问题或解决错误问题，可能没有人关心问题。这种软件源于采用一些炒作技术并将其应用于所有事物，直到出现模糊地符合某个用例需求。
晚期资本主义
风险投资支持下没有商业模式或其商业模式是增长至垄断然后剥削用户的软件。
全局来看
如果你还没有关闭浏览器标签，让我总结一下：
这个观点可能很难接受。
正如我上面提到的，我学习这个工作时，软件是为最终用户解决问题的。这在《程序员修炼之道》的最后一个提示中得到了总结，该提示说我们的目标是让用户满意，而不仅仅是交付代码。但自从我开始从事程序员工作，并且随着软件变得无处不在，我发现这种假设越来越难以维持。
有很多正在生产的软件根本不关心其用户，或者操纵用户，或者将其变成产品。这不仅限于社交媒体：作为用户，在没有弹窗试图吸引我的注意力之前，我甚至不能预订房间、订购食物或点击Windows开始按钮；在进行谷歌搜索时，我会得到一堆垃圾信息。
我们认为做好工作意味着什么与行业中相当大一部分人认为能够获利是相矛盾的，我认为这解释了许多软件专业人士日益感到不适的原因。虽然我们不能回避对我们领域的经济现实，但也许我们应该更加坚定地站在道德立场上，不伤害用户。承认用户并非始终排在商业之前，但商业也不应无条件地居于第一位：
原文链接：https://olano.dev/2023-11-30-code-is-run-more-than-read