让代码运行起来,比代码可读性重要


"代码的阅读胜于编写"这句话现在已经是程序员共识,它提醒我们,在编写代码时不能仅追求方便,而忽视那些将来需要阅读和修改代码的人。更一般地说,"代码的阅读胜于编写"传达了一个观点:通过保持代码可维护性,保持简洁、编写测试和文档等方式来使得代码易于理解是一个明智的投资。它关乎对软件开发周期的全局视角。

让我用更简洁的表达方式来表述这个观点:

维护者 > 作者

我认为这种思路可以超越编写代码,并作为一个经验法则用于问题识别和决策。

代码的使用胜于阅读

代码只是达到目标的手段。软件应该有一个目的,它应该为用户提供服务。无论代码是否编写良好、可维护性如何,以及所使用技术是否先进,如果软件不能实现其目标并给用户带来良好体验,则一切都没有意义:

用户 > 维护者 > 作者

或者,既然我们不再需要区分开发人员角色:

用户 > 开发者

因此,与其猜测或询问用户需求,最好的方法是尽早、频繁地将程序放在用户面前,并结合他们的反馈来改进。

这是一个强大的思维模式,只要在开发过程中牢记用户,我们就能走得更远。这大致是我学习这个职业以及我职业生涯前半段对它的理解方式。

代码的运行胜于阅读

当我说"运行"时,我不仅指执行程序,还包括在生产环境中操作它,包括部署、升级、观察、审计、监控、修复和废弃等等。正如丹·麦金利所说:在保持系统可靠工作方面,长期成本几乎总是远远超过你在构建过程中遇到的任何不便。

我们可以将这个观点纳入我们的小模型中:

用户 > 运维 > 开发

我花了一些时间才完全理解这一点,因为根据我的经验,很多正在构建的软件实际上从未真正投入生产使用,至少没有达到重要规模。大多数软件都是基于从未经过测试的假设构建而成。但当你将代码运行在生产环境中时,简洁性原则就有了新的维度。它不再仅仅关乎代码本身,而是关乎减少移动部件并了解其故障模式。它关乎交付产品并确保即使在出现故障时也能正常工作。

此外,还有商业因素

我说过,在开发过程中牢记用户可以帮助我们走得更远。这适用于软件对用户有价值且良好运行的假设。对于开发人员来说,这是一个方便的抽象:我们提供优秀、可工作的软件,而业务则负责将其转化为利润。这在消费者和企业软件领域通常有效。但最终,这种抽象会被证明是一种过度简化,并且我们可以从中受益,将一些商业观点纳入我们的工作流程:

商业 > 用户 > 运维 > 开发

最明显的例子就是预算:我们没有无限资源来满足用户需求,所以需要衡量成本和收益。还有市场营销、截止日期、利益相关者和投资者等因素。个人兴趣和政治也会产生影响。某些决策在孤立考虑我们的软件、团队或用户时是合理的,但当考虑整个组织时可能不再合适。有时,我们需要关注能够产生收入的事务,而不是只迎合用户。我将再次回到这个问题。

反向思考

我们得到了一个小模型,它表达了软件开发中各种因素的相对重要性,或许可以帮助我们看到更大的图景并专注于重要的事情。现在我想看一下一些常见的软件开发功能障碍,并看看它们如何与该模型相匹配。

难以维护的代码

作者 > 维护者

这是我们起点。这是聪明而懒惰的代码变成了意大利面条和鬼屋,这是过早优化,这是只有卡洛斯才能碰触那个模块等等。

不可用的软件

开发者 > 用户

由那些不从用户那里学习或将技术放在第一位的团队制作的软件。过度工程化程序、恶化用户体验的"现代化"、破坏浏览器功能的Web应用等等。

只在我的机器上运行

开发者 > 运维

没有考虑操作问题而设计出来的软件。这是过于复杂、有很多移动部分、为小数据负载设计高级数据库、由单个小团队管理的微服务生态系统。这是过早为规模而架构的软件。这是由与在它出现故障时被叫醒的人不同的人设计的软件。

正确的事情

开发者 > 商业

将代码视为目标本身。这是自命不凡的工匠们、泰坦尼克号上的音乐家和Lisp黑客制作的软件。

以简历为导向的开发

开发者 > *

没有风险,开发人员可以做他们想做的任何事情。

虚构的软件

商业 > 用户 > 运维 > 开发

这是已经构建但很少(或从未)投入生产使用的软件。我称之为虚构的软件。Charity Majors 称之为活在谎言中。

商业 > 用户 > 运维 > 开发

另一种虚构的软件是那些没有用户但具有可扩展性(大规模)的软件。这是无法解决问题或解决错误问题,可能没有人关心问题。这种软件源于采用一些炒作技术并将其应用于所有事物,直到出现模糊地符合某个用例需求。

晚期资本主义

商业 > 用户 > 运维 > 开发

风险投资支持下没有商业模式或其商业模式是增长至垄断然后剥削用户的软件。

全局来看

如果你还没有关闭浏览器标签,让我总结一下:

商业 > 用户

这个观点可能很难接受。

正如我上面提到的,我学习这个工作时,软件是为最终用户解决问题的。这在《程序员修炼之道》的最后一个提示中得到了总结,该提示说我们的目标是让用户满意,而不仅仅是交付代码。但自从我开始从事程序员工作,并且随着软件变得无处不在,我发现这种假设越来越难以维持。

有很多正在生产的软件根本不关心其用户,或者操纵用户,或者将其变成产品。这不仅限于社交媒体:作为用户,在没有弹窗试图吸引我的注意力之前,我甚至不能预订房间、订购食物或点击Windows开始按钮;在进行谷歌搜索时,我会得到一堆垃圾信息。

我们认为做好工作意味着什么与行业中相当大一部分人认为能够获利是相矛盾的,我认为这解释了许多软件专业人士日益感到不适的原因。虽然我们不能回避对我们领域的经济现实,但也许我们应该更加坚定地站在道德立场上,不伤害用户。承认用户并非始终排在商业之前,但商业也不应无条件地居于第一位:

用户 > 运维 > 开发
商业 > 运维 > 开发
商业 ≹ 用户

原文链接:https://olano.dev/2023-11-30-code-is-run-more-than-read


相關推薦

2023-07-23

近日,新型JavaScript运行时Bun正式发布了0.7版本,带来了重大的升级。据悉,Bun是一个配套齐全的JavaScript解决方案,集运行时、打包器、转译器和包管理器于一体,追求极致的运行速度。此次更新主要集中在与Node.js的兼容性提升

2023-07-21

有意识到你在模仿,因为你只不过是在别人铺好的轨道上运行的火车。但在另一个极端,模仿可以是优越性的表现,而不是从属关系。 [25] 在很多领域,你的早期工作几乎必然会在某种程度上基于他人的工作。项目很少在真空

2023-04-24

一个好的软件, 不仅仅只是内存安全和绝对性能, 代码可读性, 场景适合性, 认知深刻和持续维护的软件对用户才有价值, 重写完一个软件, 证明 rust 比别的语言快和自己厉害, 马上就弃坑的软件没有价值。 3. Rust社区推

2023-05-18

入泛型以来,相关的评论正在减少。关于错误处理(关于可读性和冗长)的评论和学习最佳实践的困难成为了现在最常报告的挑战。 优化指南是提高 Go 性能的最有价值的方法。当被问及如何将资源用于 Go 编译和运行时的

2024-08-02

、作用域以及如何在不同节点间传递,对于流水线的高效运行和灵活性至关重要。通过合理地定义和使用参数,可以实现不同节点之间的数据共享和逻辑控制。例如,一个测试节点可以根据上游编译节点提供的构建版本来运行相

2022-12-10

有助于在编译时捕获与类型有关的错误,并应改善代码的可读性、可维护性和提前编译(AOT)。 由于转变巨大,对开发者而言肯定是会产生持续一段时间的影响/阵痛期,开发者最好是可以在 Dart 3 发布之前调整他们的代码。Goog

2023-11-25

问题​​。 此外,Bun 1.0.14增强了构建失败时错误消息的可读性。它修复了一个之前只高亮显示错误的第一个字符的错误,减少了错误消息中不必要的换行,并使构建错误的样式与运行时错误的样式一致​​。 最后,更新改进

2023-06-08

过本文,对青语言的语法设计进行一些说明。 1、青语言可读性差? 关于这一点,我们认为可能更多的是因为编程习惯的原因,而非青语言设计的问题。 首先,青语言的语法设计主要参考了JavaScript。JS是一门成熟且简单的主

2022-10-15

lla 创建的也就不足为奇。Mozilla 的开发人员研究了他们在代码中遇到的问题并寻求更好的解决方案。最后,他们想出了 Rust。 讨厌:Rust 的并发模型太复杂了 虽然多线程系统越来越流行,但对于很多开发人员来说这并不是真正

2024-11-01

pt 原有语法的基础上,ArkTS 加强了静态检查,从而提高了代码的质量和性能。同时,它还增强了并发编程的 API,解决了 JavaScript/TypeScript 在并发能力上的不足。此外,ArkTS 支持与 JavaScript/TypeScript 的高效互操作,保证了生态的兼

2023-08-02

事情,如 SPI 闪存访问。 我可以很容易地想象到 BIOS fTPM 代码会使用一些绝对可怕的全局“EFI synchronization”锁或其他东西,从而导致一些完全无关的随机问题。 举例来说,如果不是 fTPM hwrnd 代码本身决定从 SPI 读取某个随机数

2022-07-04

复了 Dock 中的 "清空垃圾桶" 按钮 将完整的 Unity7 shell 源代码迁移到 GitLab,并使其在 22.04 上进行了编译。 设计更加扁平化,但保留了全系统范围的模糊效果。 dock 的菜单和工具提示被赋予了一个更现代的外观。 低图形模

2024-07-25

炼;不会被单一封闭的供应商所束缚;数据保护;高效且运行成本低廉的模型以及长期标准的生态系统。 而对于外界常提及的“是否担心开源 Llama 会放弃技术上的优势”这一问题,扎克伯格也进行了否认,并给出了几大缘由:

2022-05-05

复了 Dock 中的 "清空垃圾桶" 按钮 将完整的 Unity7 shell 源代码迁移到 GitLab,并使其在 22.04 上进行了编译。 设计更加扁平化,但保留了全系统范围的模糊效果。 dock 的菜单和工具提示被赋予了一个更现代的外观。 低图形模