程序员才懂的“浪费”与软件工程的代际跃迁

一、一段代码引发的两种反应

假设今天你在代码审查中看到这样一段逻辑：为了计算两个整数相加，代码并没有直接使用本地运算指令，而是发起了一次远程调用：

def add(a: int, b: int) -> int:
    resp = requests.post(
        "https://api.example.com/v1/add",
        json={"a": a, "b": b},
        headers={"Authorization": "Bearer ..."}
    )
    return resp.json()["result"]

看到这段代码，程序员群体内部至少会出现两种截然不同的态度。

第一种是“原教旨主义者”的愤怒。
这类开发者通常对计算机体系结构有着近乎偏执的尊重。他们会立刻指出：为了完成一次整数加法，竟然要消耗网络往返时间、占用连接池资源、支付接口调用费用，还要承担网关超时、服务不可用、限流熔断等风险。从执行效率看，这显然是对 CPU 的极大浪费；从工程可靠性看，这是一种主动引入故障点的设计；从成本控制看，这几乎无法通过任何严肃的预算评审。

第二种是“经验丰富者”的黑色幽默。
他们不会急着脸红脖子粗，反而会把这段代码截图发到内部群里，配上一句调侃：“以后用户电脑里的计算器，断网了可能连一加一都算不出来。”这类开发者经历过多轮技术演进，早已不再用单一的执行效率标准去评判一段代码。他们更关心的是：这段代码出现的上下文是什么？它是否在特定条件下真的成立？它是否预示了某种更大的趋势？

二、如果收起笑容，这段代码到底在表达什么

如果把这段“用远程请求算加法”的代码视为一种隐喻，而不是一个实际必须修改的生产缺陷，那么它其实指向了一个软件工程中长期存在的命题：

当我们拥有足够便宜、足够易用的资源时，我们是否还会坚持过去那种追求极致执行效率的写法？

经济学中有一个概念叫杰文斯悖论：当一种资源的使用效率提升后，其总消耗量反而可能大幅上升，因为效率提升降低了使用成本，从而刺激了更多场景中的需求。这一逻辑同样适用于计算资源。

过去，CPU 周期极其昂贵，内存以 KB 计量，网络带宽更是稀缺。那时的软件设计以“节省”为核心美德。如今，CPU 多核早已普及，内存容量大幅提升，网络接入几乎无处不在，云服务把计算、存储和模型能力包装成了按量计费的基础设施。于是，过去看起来荒谬的“浪费”，开始在某些场景中变成“合理的权衡”。

例如，为了减少几毫秒的延迟，绝大多数系统仍会选择本地缓存；但如果某个低频管理功能为了降低客户端复杂度，把计算逻辑放在服务端统一执行，即使这会增加一次网络调用，也完全可能被接受。关键不在于“是否浪费”，而在于“用什么样的资源，换取了什么样的收益”。

因此，上述代码真正值得讨论的地方，不是它当前是否正确，而是它是否会成为未来某种开发范式的前兆——当远程计算能力足够稳定、足够便宜，并且能够提供本地无法获得的能力时，开发者自然会开始把越来越多原本本地完成的任务迁移到远端。

三、技术史中的“浪费”与“置换”

这种“看不惯浪费，但最终被浪费所塑造”的过程，在计算机发展史中反复出现。

1. 从汇编到高级语言：用机器周期换取开发效率

上世纪七十年代前后，真正深入底层系统的程序员往往认为，只有汇编语言才能真正发挥硬件性能。高级语言生成的机器码在他们看来充满冗余指令，既占内存又拖慢执行速度。甚至有文章以讽刺口吻写道：“真正的程序员不用 Pascal。”

但后来的发展证明，高级语言赢得了大多数应用场景。原因并不复杂：硬件性能的增长速度，超过了高级语言带来的额外开销；而高级语言带来的可读性、可维护性和开发效率，是纯汇编难以规模化提供的。

今天，我们不仅使用 C，还使用 JavaScript、Python、Go 等语言。许多系统甚至运行在虚拟机或解释器之上。仅从单条指令的执行效率看，这些方案都不可能胜过手写汇编；但它们让更多人能够快速构建更复杂的系统，这种收益显然更大。

2. 从命令行到图形界面：用内存占用换取交互效率

图形用户界面刚出现时，早期极客同样充满质疑。为了显示一个文件夹图标，系统需要持续占用可观的内存，需要渲染位图、处理事件循环、维护窗口状态。而命令行只要几行字符就能完成同样功能。

然而图形界面最终成为主流。因为它把计算机从专业工具变成了大众设备。对普通用户而言，看到图标并点击一次，远比记忆并输入一串命令更高效，也更少出错。图形界面消耗的资源，本质上是为交互效率买单。

3. 从自建服务到云资源：用直接成本换取运维效率

早期企业构建系统时，往往需要自建机房、购置服务器、配置网络设备，并安排专人维护。后来云服务兴起，企业逐渐接受按需租用计算、存储和网络资源的方式。从财务角度看，云资源单价可能高于自建硬件的长期折算成本；但从交付速度、弹性伸缩和运维负担角度看，云服务节省了大量隐性成本。

这种变化也改变了开发者的思路。过去为了避免多一次远程调用，很多团队宁可引入复杂的本地缓存体系；现在，对于大量非核心路径，直接调用一个远程接口可能是更简单的方案。只要服务可用性、延迟和成本整体可控，架构上的简单性本身就具有巨大价值。

四、未来可能的“挥霍式”开发范式

结合上述历史规律，再回到开头的加法示例，我们可以更冷静地审视未来几种可能趋势。

1. 远程推理能力成为基础能力

当模型推理服务逐步成为云上的通用产品形态后，开发者在应用中集成文本生成、图像识别、代码分析等能力的门槛大幅降低。过去需要本地部署模型、准备专用硬件、维护推理服务的工作，可能退化为一次简单的远程调用。

在这种环境下，一个原本需要复杂本地逻辑的功能，可能被拆分为若干次对远端能力的请求。虽然单次请求在资源消耗上不如本地精确计算高效，但它让团队能够更快交付功能，也让系统更容易扩展。对很多业务而言，这种置换是有吸引力的。

2. 确定性计算与概率性计算的边界变化

传统的本地加法是确定性计算：同样的输入必然产生同样输出，执行路径完全可控。远程服务则引入了更多不确定性：网络波动、服务负载、限流策略、模型输出不稳定等。

但与此同时，远程服务也可能提供更强的能力，例如上下文理解、自然语言交互、复杂格式转换等。这些能力无法简单用几行本地代码复现。于是，软件设计中出现了一种新的权衡：哪些部分必须留在本地以保证确定性和低延迟，哪些部分可以交给远端以获取更强能力。

未来开发者需要更清晰地识别这条边界。对于核心交易链路、实时控制逻辑等，本地计算仍不可替代；对于辅助性、探索性、内容生成类功能，远程服务则可能成为默认选择。

3. 成本模型的变化带来代码风格变化

过去，一个合格的后端开发者必须时刻关注每次操作的 CPU 消耗、内存占用和 IO 次数。未来，如果远程推理服务成为常用组件，成本意识会从“减少 CPU 周期”扩展到“控制远程调用频次、输入 token 数量和输出长度”。

这意味着代码审查中会多出一种新的检查维度：这里是否真的需要一次远程调用？能否通过缓存、批处理、结果复用或前置过滤来减少调用次数？这种审查并不完全等同于过去对性能的苛责，它更像是一种对“单位功能成本”的重新评估。

五、回到代码审查：什么才是更成熟的判断

面对开头那段远程加法的代码，真正有经验的工程师不会只停留在嘲讽或愤怒。他们会进一步追问：

• 这段代码是否处于生产关键路径？
• 它的调用频率有多高？
• 远程服务的延迟和成本是否已被明确测算？
• 是否存在更合理的本地降级方案？
• 团队是否理解这种设计与当前架构目标之间的关系？

如果这些问题有清晰答案，那么“远程调用算加法”可能是一次不合理的实现，也可能是某种更大设计取向的极端表现。无论如何，评价它的标准都不应只是“浪费”或“离谱”，而是：它在当前系统目标下，是否用合理的代价换取了足够的价值。

六、结语

程序员之所以能看懂“远程调用算加法”中的荒诞，是因为他们对计算机体系的运行成本有真实感知。但计算机发展史又不断提醒我们：每一次重大演进，几乎都伴随着对旧有资源观念的冲击。

今天看不上的“浪费”，可能只是明天普遍范式的早期版本。

因此，与其把这类代码简单归类为笑话，不如把它看作一个观察窗口：软件工程正在从“尽可能节省每一份计算资源”的时代，逐渐走向“更灵活地组合不同资源以获取更大工程收益”的时代。理解这种变化，比学会某个具体框架或语言，更接近工程师的核心能力。