我们在软件开发中失去礼仪了吗？

Source: Dev.to

请提供您想要翻译的具体文本内容，我将为您翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！

介绍

我写软件的时间越长，我对“令人印象深刻”的感受就越改变。如今真正让我惊叹的不是现代技术，而是更早期的系统——以及构建它们的人。

以 Windows 95 为例：这是一套近 30 年前的完整操作系统，拥有 GUI、驱动程序、多任务、多媒体、进程和线程管理——所有这些都装在大约 50 MB 的磁盘空间里，并且可以在 4–8 MB 的内存上运行。

现在把它和今天的情况进行比较。我现在用来输入这段文字的浏览器标签页占用了超过 1 GB 的内存。我没有在编译任何东西，也没有在渲染视频，我只是编辑文字而已。

仅这一数字就足以让 1980 年代的工程师感到震惊——那时的人们在只有 2 MB 内存和 20 MB 硬盘的机器上运行完整的多用户 Unix 环境。整个开发工作流——编辑器、编译器、网络、用户——都在当时看似不可能的约束条件下完成。

即使是今天的一些小事也显得沉重。激活虚拟环境后，一个简单的 “Hello, World” 程序就可能在真正的业务逻辑运行之前就拉取数十兆字节的库。这并不是因为问题本身复杂，而是因为其周边生态系统庞大。

消逝的纪律

让我感到惊讶的并不是硬件变得更快——那是必然的。让我惊讶的是丰裕如何改变了我们的行为。我们失去了软件礼仪。

稀缺的约束曾经强制了一套不成文的行为准则：

• 内存很宝贵——你会自行清理
• 每个周期都重要——在循环之前先思考
• 依赖需要赢得——不会为琐碎任务随意引入库
• 抽象必须被理解——你知道底层到底发生了什么

旧系统并非神奇。它们受限——而这种限制培养了纪律。我们用便利换取了这种纪律。

专业悖论

如果你不使用大量的库、云 SDK 和在运行时消耗资源（以及金钱）的抽象层，你就有可能被 Developer B 超越，而他根本不在乎。Developer B 是“交付者”——他们快速交付，后果不顾！

这些指标对精细的工艺不利：

• 速度 > 效率
• 交付的功能 > 消耗的资源
• 上市时间 > 技术债务的考量
• 框架熟悉度 > 对基础的理解

我们已经创造了一个世界，最“高产”的开发者往往是那个把抽象层层堆叠、依赖层层叠加的人，直到整个结构臃肿到需要硬件升级才能保持同等水平——并且推高了云成本。

坏礼仪的代价

这不仅仅是怀旧。后果是真实的：

• 环境影响 – 我们正在消耗兆瓦电力来运行执行简单任务的低效软件
• 可访问性削弱 – 需要最新硬件的软件会排除使用旧设备的用户
• 安全脆弱性 – 多层依赖产生我们不了解的攻击面
• 创新停滞 – 当我们所有的精力都用于维护臃肿的系统时，真正的突破几乎无从谈起

在 2 MB PDP‑11 上构建 C++ 的工程师们不仅聪明——他们更体贴。他们考虑了硬件、后续程序员以及用户的资源。这种考虑正是他们的职业伦理。

重新学习我们的礼仪

是的，我们的礼貌正在丧失。但礼貌是可以重新学习的。它始于一些小小的体贴行为：

• 质疑依赖 – “我真的需要这个 50 MB 的库来完成一个简单任务吗？”
• 持续分析 – 了解你的代码实际在做什么，而不是你以为它在做什么
• 深入一层 – 知道抽象层下面到底发生了什么
• 倡导效率 – 把性能视为特性，而不是事后考虑

最令人印象深刻的软件并不是使用最多资源的那种，而是用最少资源完成最多任务的那种。那种自律、体贴、对机器和用户的专业礼貌——这正是我们需要重新找回的。

因为归根结底，软件开发不仅仅是让计算机完成任务。它关乎我们在资源有限的世界中如何生存。事实证明，良好的礼貌在代码中和在生活中同样重要。