保持系统可靠运行的成本往往是远远超过在构建过程中遇到的任何不便之处
原文链接：https://olano.dev/2023-11-30-code-is-run-more-than-read/未经允许，禁止转载

作者 | Facundo Olano 译者 | 弯月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

代码的阅读次数多于编写次数如今这已是程序员的共识，提醒我们初次编写代码不应该为了追求方便而牺牲将来阅读和修改此段代码的人
更通俗地来说，“代码的阅读次数多于编写次数”传达的意思是，通过保持代码简单、编写测试和文档等方式来降低维护代码的难度通常是一个不错的投资
这是为软件开发周期的全局考虑
我可以通过更简单的方式表达这个观点：维护者 > 作者我认为这种思想可以超越代码编写，作为一种经验法则用于识别问题并做出决策
代码的使用次数多于阅读次数代码是达到目的的手段
软件应该有一个目标，应该为某个用户提供服务
无论代码编写得多么好，多么易于维护，也无论使用的技术有多复杂，如果不能实现其目标，并为用户提供良好的体验，那就没有意义：用户 > 维护者 > 作者或者，我们将开发者角色合二为一：用户 > 开发者这就是为什么，与其猜测或询问用户需要什么，不如尽早而频繁地将程序放在用户面前，并将我们从他们的反馈中获得的信息融入到程序中
这是一个强大的思维模式，在开发的过程中，只要我们牢记用户就能走得很远
代码的运行次数多于阅读次数此处我所说的“运行”指的不仅仅是执行一个程序；我指的是在生产环境中运行代码的所有方面，包括部署、升级、观察、审计、监视、修复、下线等等
正如Dan McKinley所说：通常情况下，保持系统可靠运行的长期成本往往总是远远超过在构建过程中遇到的任何不便之处
将这个观点纳入上面的思维模式：用户 > 运维 > 开发者我花了一些时间才完全理解这一点，因为根据我的经验，许多正在构建的软件实际上从未真正投入生产，至少不是大规模
大多数软件是根据从未经过测试的假设而构建的
但当你在生产环境中运行代码时，KISS（Keep It Simple, Stupid：保持简单和愚蠢）原则会呈现出新的维度
这不仅仅关系到代码，还涉及降低复杂性并了解它们的故障模式；发布软件，并确保发生故障时仍然能正常工作
商业视角我说过，在开发过程中牢记用户可以让我们走得很远
这建立在这样一个假设的基础之上：软件确实能提供帮助且运行良好，只有对用户有价值的软件对组织才有价值
开发人员可以理解为：我们生产良好、正常运行的软件，并通过商业将其转化为金钱
大部分软件皆是如此，特别是消费者软件和企业软件
但这种抽象过于简化，实际上我们可以将一些商业视角纳入我们的工作流程：商业需求 > 用户 > 运维 > 开发者最明显的例子是预算：我们没有无限的资源来满足用户需求，因此我们需要衡量成本和收益
此外，我们有市场营销，截止日期，利益相关者和投资者，甚至还有个人兴趣和政治因素等
从我们的软件、团队或用户的角度出发制定的决策，从整个组织考虑可能就不合适了
有时，我们需要考虑如何创收，而不仅仅是取悦用户
各种问题代码以上，我们建立了一个能够表达软件开发中各种因素的相对重要性的小模型，它可以帮助我们考虑到全局，并专心做好重要的工作
下面，我们来看看一些常见的软件开发问题，以及它们如何与这个模型相匹配
难以维护的代码作者 > 维护者这是本文开头探讨过的问题
这种聪明但懒惰的代码会变成意大利面条，只有某个特定的人才敢碰
无法使用的软件开发者 > 用户这类软件的开发团队没有听取用户的意见，或者是他们将技术放在了第一位
过度设计的程序，“现代化”导致用户体验下降，破坏浏览器功能的 Web 应用程序等
在我机器上正常运行开发者 > 运维这类软件没有考虑运维
这些软件过于复杂，有很多组成部分，虽然数据负载很小但采用了花哨的数据库，由一个小团队管理的微服务生态系统
过早考虑大规模架构的软件
半夜因软件出现故障而被唤醒的人与设计软件的人是不同的一批人
正确的事情开发者 > 商业需求将代码视为目的本身
由自负的工匠、泰坦尼克号的音乐家和Lisp黑客构建的软件
简历驱动开发开发者 > 开发软件时不考虑任何风险，开发者可以随心所欲地做任何他们想做的事情
虚构的软件 商业需求 > 用户 > 运维 > 开发者这类软件即便构建完成也很少（或永远不会）投入生产，我称之为“虚构的软件”
Charity Majors 称之为“活在谎言中”
商业需求 > 用户 > 运维 > 开发者另一种虚构的软件是没有用户的软件（但有规模）
这类软件没有解决任何问题，或解决了错误的问题，或者没有受众
这些软件采用了一些炒作的技术，并一直使用，直到出现某种用例
晚期资本主义商业需求 > 用户 > 运维 > 开发者由风险投资支持的软件，这类软件没有商业模式，或其商业模式是成长直至垄断然后剥削用户
庞然大物这类软件可以总结为：商业需求 > 用户如上所述，我认为软件的目的是为最终用户解决问题
我们的目标是让用户满意，而不仅仅是交付代码
然而，从事程序员的工作以来，虽然软件无处不在，但我发现坚持这个立场越来越艰难
有很多正在开发中的软件根本不关心用户，或者企图操纵用户，或者将用户变成产品
这类软件不仅限于社交媒体，作为用户，点击开始按钮就会弹出各种窗口，我甚至无法在不受到此类骚扰的情况下顺利地预订房间、订购食物；打开浏览器上网搜索就会得到一堆垃圾结果
似乎做好软件开发的工作与该行业的盈利之间存在着某种矛盾关系，我认为这解释了为什么许多软件专业人士越来越不适应该行业
虽然我们不能无视经济现实，但也许我们应该更加强力地坚守道德底线，不伤害用户
虽然用户不一定始终优先于业务，但业务也不应无条件地居于首位：用户 > 运维 > 开发者商业需求 > 运维 > 开发者商业需求 ≹ 用户