代码阅读次数多于编写次数

维护者 > 作者

如今这已是程序员的共识，提醒我们初次编写代码不应该为了追求方便而牺牲将来阅读和修改此段代码的人。

“代码的阅读次数多于编写次数”传达的意思是，通过保持代码简单、编写测试和文档等方式来降低维护代码的难度通常是一个不错的投资。这是为软件开发周期的全局考虑。

代码的使用次数多于阅读次数

用户 > 维护者 > 作者

代码是达到目的的手段。代码是被用来实现用户需求的工具。软件应该有一个目标，应该为某个用户提供服务。无论代码编写得多么好，多么易于维护，也无论使用的技术有多复杂，如果不能实现其目标，并为用户提供良好的体验，那就没有意义。这就是为什么，与其猜测或询问用户需要什么，不如尽早而频繁地将程序放在用户面前，并从他们的反馈中获得的改善信息融入到程序中。

“代码的使用次数多于阅读次数”传达的意思是，以用户为中心、以实际需求为出发点开展编码工作，否则一切将是徒劳。

代码运行次数多于阅读次数

用户 > 运维 > 开发者

此处的“运行”指的不仅仅是执行一个程序；我指的是在生产环境中运行代码的所有方面，包括部署、升级、观察、审计、监视、修复、下线等等。正如Dan McKinley所说：

通常情况下，保持系统可靠运行的长期成本往往总是远远超过在构建过程中遇到的任何不便之处。

我花了一些时间才完全理解这一点，因为根据我的经验，许多正在构建的软件实际上从未真正投入生产，至少不是大规模。大多数软件是根据从未经过测试的假设而构建的。但当你在生产环境中运行代码时，KISS（Keep It Simple, Stupid：保持简单和愚蠢）原则会呈现出新的维度。这不仅仅关系到代码，还涉及降低复杂性并及时了解它们的故障情况；发布软件，并确保发生故障时仍然能正常工作。

“代码运行次数多于阅读次数”传达的意思是，在小规模软件系统中，不要过度设计程序，保持简单和愚蠢，以便及时发现和修正问题。

商业视角

我说过，在开发过程中牢记用户可以让我们走得更远。这是在这样的假设下进行的：有用且运行良好的软件，对用户有价值的软件，才会对组织也有价值。对于开发人员来说，可以这样理解：我们生产良好的、可用的软件，而业务则负责将其转化为金钱。大部分软件都是如此，特别是消费者软件和企业软件。但这种抽象被证明过于简单化，实际上我们可以将商业视角纳入到我们的工作流程：

商业需求 > 用户 > 运维 > 开发者

最明显的例子就是预算：我们没有无限的资源来满足用户的需求，所以我们需要衡量成本和收益。有营销，有最后期限，有利益相关者和投资者。甚至还有个人兴趣和政治因素等。单独考虑我们的软件、我们的团队或我们的用户显得是有意义的，但当我们将组织视为一个整体时则不然。有时，我们需要致力于创造收入，而不是取悦用户。

也就是说代码程序要迎合商业模式。