90% 的软件工程工作都是集成那些不完善的 API，而我乐在其中。

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

（题图：Ophelia photos - Creative Commons）

今天偶然看到这条推特帖子和 Hacker News 上的相关评论：如今 90% 的软件工程工作都是在集成文档不完善的 API | Hacker News。我完全无法认同这种观点。事实上，我认为这种态度非常有害。

没人会说：“建造桥梁90%的工作就是用质量参差不齐的水泥塑形。” 众所周知，土木工程涉及选择合适的水泥、设计合理的建筑结构、计算结构应力、组织庞大的施工队伍以及制定项目计划。它既艰辛又充满挑战，但也极具成就感。水泥的质量总是参差不齐的，因为它并非不可捉摸的稀有材料，可以神奇地被塑造成指定形状的桥梁。

软件工程和我们自己的数字粘合剂——API——也是如此。事实上，将各种简陋的API组合起来解决问题既充满挑战又极具成就感，以至于我无法想象自己还能做其他任何事。

两种类型的软件工程

如今，我正在开发一款基于 CRUD 的电子商务应用程序，使用的竟然是 PHP、WordPress 和 MySQL。过去 20 年里，我涉猎广泛，从裸机嵌入式系统到量子密码以太网桥，再到搜索引擎和“非谷歌规模”的数据工程，无所不包。这些经历让我明白，软件工程其实可以分为两种截然不同的类型。

软件工程就像复制字节

其中一种我称之为“复制字节”。你会得到一些与业务相关的输入字节。作为软件工程师，你的工作就是将这些输入字节复制到指定的目标位置。

例如，您收到客户的订单（商品明细 + 收货地址），需要将这些商品明细转发给发货部门，并在转发过程中记录一些日志条目。您可能还会计算一些税费或应用优惠券，稍微修改一下这些数据，但总的来说，您只是按照既定的流程发送它们。

软件工程即“发明”字节

另一种软件工程我称之为“发明字节”，或者“以极其复杂的方式转换字节”。这涉及到奇特的算法、数据科学、数学以及其他复杂的技术。例如：输入一个3D模型，然后输出一些CAM指令，或者在复杂的索引结构中搜索一个字符串。通常，这些高难度的思考工作是由大学或研究实验室的研究人员完成的。

编写代码通常只是整个项目中微不足道的一部分。人们不禁会怀疑这些“字节发明家”是否真的称得上是软件工程师。或许我们应该称他们为“三维模型转换工程师”或“搜索索引数据结构工程师”。通常情况下，他们的代码需要由懂得如何缩进文件（或者说，如何将代码从蹩脚的MATLAB移植到Java）的人重写。

用于创建字节的 API 很奇怪。坦白说，我不太研究创建字节，所以对这些 API 的文档了解不多。

你可能整个职业生涯都在复制字节。

如果你从事的不是思考巧妙的想法或制作像电子游戏这样漂亮的东西，而是赚钱，那么你可能属于软件工程中“复制字节”这一类。

要复制哪些字节，何时复制，在哪里复制，过程中要添加哪些日志条目，如何扩展复制规模，如何确保复制的字节与其他复制的字节在事务上对齐，这些都很复杂。但就像乌龟爬一样，一层层地往下，一个用于复制字节的 API 层层递进。最终你会接触到硬件，而硬件上用于复制字节的 API 简直是一团糟。

你不需要编写有趣的代码才能成为一名工程师。

你可能会觉得这很荒谬：你学过如何平衡树、如何调度进程、如何进行微分曲线几何运算；如何编写编译器、如何设计数据库引擎、如何实现分布式共识；为什么你不能把这些精妙的算法作为日常工作的一部分来编写呢？事实上，聪明的人早就这么做了，而且他们往往以此为生。现在，你可以付费给他们，让他们为自己的聪明才智和辛勤工作买单，希望他们真的比你更聪明，然后继续调用 API 来复制刚刚计算出来的字节。

人们出于各种不同的原因，以不同的方式，在不同的约束条件下传输数据。这意味着，即使是编写得最好的 API 文档，也必须足够通用，以涵盖其设计初衷的使用场景，并尽可能地涵盖人们的实际使用场景。它很少能完全契合你的使用场景。因此，文档不会完美无缺，甚至可能根本无法满足你的需求。

我个人认为，API 文档整体上比以前好太多了。我最近接触的所有 API 都提供了 15 种语言的现成文档，一个快速便捷的搜索索引，大量的教程、文章和视频，以及一个活跃的 GitHub 仓库。这比费劲地去猜测 PC-NFSD 服务器上的文件需要多少空格才能让 COBOL 解析器正常工作要好得多。

通过组合各种糟糕的API来解决问题是我做过的最有成就感的事情。

但我发现，用那些不太好用的 API 复制字节的工作，却让我感到格外满足，原因如下：

复制字节并非易事，尤其是在当今分布式环境中。如何可靠、安全且大规模地完成复制需要深思熟虑。确定哪些数据应该传输给谁，需要对业务有深刻的理解，了解人员情况，并具备系统思维。构建和维护解决方案需要产品和项目规划、团队管理以及应对不断变化的需求。它还需要保持代码库的健康，指导其他工程师，与利益相关者协调一致，并处理遗留代码。

我最终使用的 API 反而是我最不关心的问题。有些 API 很好用，有些很糟糕，有些问题重重，但它们与我工作的“工程”部分关系不大。工程部分其实就是用方框和箭头画图。方框代表别人的系统，箭头代表别人的 API。我画哪些箭头，箭头指向哪里，箭头旁边的小气泡里装的是什么，以及我选择使用哪些方框，这些才是我作为工程师的工作。

一个具体的例子：结账

举一个具体的例子来说明一个难题，那就是如何通过拼凑劣质 API 来实现：在电子商务商店完成订单。

• 使用流畅的用户体验，在客户的浏览器中无缝地向其展示支付流程和结账状态（API：一些粗糙的 REST API、一些不稳定的 WebSocket 或其他 API、一些临时拼凑的 React 代码和一些可疑的 CSS 代码。最终只是将支付处理器的状态码直接发送到用户的浏览器，可能还会添加一些花括号并转义一两个字符串。）
• 记录交易并向业务和运营部门提供指标和分析（一些无意义的像素数据、一些糟糕的跟踪 JS 代码、一些劣质的 SQL 代码，可能还有一些发送到 SQS 队列的蹩脚 JSON 数据）。
• 处理付款信息、订单信息并将其显示在客户帐户部分/后端 CRM/联邦快递中（我甚至都不想列举这里的 API 有多么糟糕）。
• 将收货地址转换为带有条形码的正规货运标签（可以使用 Zebra 和 ZPL）。
• 将订单项分发到所需的配送中心，向仓库工人提供拣货信息，并进行跟踪、指标分析、库存管理等操作……

设计出这样的产品，使其能够正确、高效地运行，具有可见性、可靠性、可扩展性，满足业务需求，并让参与其中的每个人都感到快乐——这才是真正的工程。

你认为把 API 拼凑在一起算是工程吗？

你觉得现在的软件工程很枯燥吗？你讨厌把各种API拼凑在一起吗？你认为“真正的”软件工程应该包含哪些内容？你理想中的软件工程师的日常工作是什么样的？欢迎在下方留言！