云卡尺

为下一代命名，并记住云只是别人的计算机

尊敬的KV：

为什么这么多程序员在对API进行版本控制时坚持对其进行编号？真的没有比在API末尾添加数字更好的升级方法了吗？为什么这么多系统被命名为“NG”，而它们显然只是升级版本？

API2NG

尊敬的API2NG：

自从源代码控制通过将文件名贴在经理办公室碗里的豆袋上来实现，而文件锁定是通过在所述碗中翻找要编辑的文件来执行以来，软件版本控制已经取得了长足的进步，但是程序员在API名称方面的创造力并没有太大进步。有些语言（例如C++）可以处理多个函数——等等，具有相同名称但参数不同的方法——但是这些方法带来了自身的问题，因为现在程序员不必使用描述性名称，而必须查看函数参数才能知道他们正在调用哪个API。

也许编号API的最大来源是每个人都为其编程的基础系统，例如操作系统及其库。这些是用C语言编写的，C语言是一种可爱的、花哨的汇编程序，它不接受诸如变体函数签名之类的花哨概念。由于这种实际上在我们所有人的集体帮助下完成大部分工作的语言的限制，C程序员在只想创建具有不同参数的库函数或系统调用时，会添加全新的API。

以管道的创建为例，这是一个非常常见的操作。曾经，管道很简单，并向程序返回一个新的管道，但是后来有人想要管道中的新功能，例如使它们成为非阻塞的，并在执行新的子程序时关闭管道。由于pipe()是一个由操作系统和Posix标准定义的系统调用，因此pipe()的含义已经根深蒂固。为了添加flags参数，需要一个新的类似管道的API，因此我们得到了pipe2()。我想说“Ta-da！”，但它更像是悲伤的长号声。鉴于系统调用接口是用C语言编写的，因此除了添加一个新的调用之外，别无他法，这样我们就可以拥有一些标志。命名创造力的完全缺乏令人震惊。因此，现在有两个系统调用，pipe()和pipe2()，但是情况可能会更糟：我们本可以拥有pipeng()。

也许派拉蒙公司所做的最糟糕的事情就是将其星际迷航重启版命名为下一代，因为这似乎鼓励了一代开发人员将他们闪亮的新事物命名为ThingNG，无论那是什么事物。不知何故，没有人考虑下一个版本的下一个版本可能是什么。事物的第三个版本会是ThingNGNG吗？如果您的软件持续十年，它最终会是一串以名称开头的NG吗？使用“下一代”可能比版本化API的数字指标更令人恼火。

解决这些版本控制困境的正确答案是为较新的接口创建一个描述性名称。毕竟，您创建新版本是有充分理由的，不是吗？与其使用pipe2()，不如将其命名为pipef()，表示“带有flags参数的管道”可能更有意义。程序员是出了名的懒惰，让他们多输入一个字符会惹恼他们，这也是版本化API通常以单个数字结尾以节省输入时间的另一个原因。

目前，由于语言的限制，我们很可能继续拥有对其函数进行版本控制的程序员，但让我们希望我们可以阻止他们以下一代的名字来命名他们的下一代。

尊敬的KV：

我的团队已被赋予将我们的一些系统迁移到云服务的责任，以此来降低成本。虽然云看起来更便宜，但事实证明它更难管理和衡量，因为我们以前的许多性能衡量系统都依赖于更多地了解硬件的性能以及操作系统和其他组件。既然我们所有的设备都是虚拟的，我们发现我们不太确定我们是否得到了我们所支付的东西。

多云转晴

尊敬的Cloudy：

请记住，云只是别人的计算机。虚拟化系统已经存在很长时间了，并且出于各种原因被部署，其中大多数与降低成本和易于管理有关。当然，问题是谁的管理更容易。对于非性能关键型服务，将它们从专用硬件迁移到虚拟化系统通常是明智之举，因为此类系统可以轻松暂停和重启，而应用程序并不知道它们已在数据中心内部或之间移动。

当应用程序在存储或网络方面有高需求时，虚拟化架构的问题就会显现出来。虚拟化磁盘可能会尝试报告IOS（每秒I/O操作数），但是由于底层硬件是共享的，因此很难确定该数字是否真实、一致以及是否每天都相同。为虚拟化环境调整系统大小会带来底层系统性能每天都在变化的风险。虽然可以选择特定大小和功率的虚拟系统，但始终存在风险，即如果添加其他虚拟化系统或新服务突然在其他容器中启动，则底层系统将更改其性能特征。在许多情况下，最好的办法是以更抽象的方式测量操作，希望可以用挂钟时间来衡量。在日志文件中添加操作时间戳应该可以提供一组合理的度量，但即使在这里，虚拟化系统也可能会让您失望，因为虚拟系统在跟踪一天中的时间方面非常差。

回顾开始，如果您想了解虚拟化系统中的性能，则必须建立可靠的时间基准，可能使用NTP（网络时间协议）或类似协议，并且在此基础上，您必须通过记录操作所需的时间来建立系统的性能。各种虚拟化环境中可能会提供其他工具，但是您会信任它们吗？您有多信任别人的计算机？

Kode Vicious，凡人称之为George V. Neville-Neil，为了乐趣和利润而从事网络和操作系统代码的工作。他还教授有关编程相关主题的课程。他的兴趣领域是代码探险、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他在马萨诸塞州波士顿的东北大学获得了计算机科学学士学位，并且是、Usenix协会和IEEE的成员。 Neville-Neil与Marshall Kirk McKusick和Robert N. M. Watson合着了FreeBSD操作系统设计与实现（第二版）。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

queue.acm.org上的相关内容

Kode Vicious
胃口大开的API
态度强硬的koder，KV回答您的问题。他不是Miss Manners。

商业计划中的傲慢
- Paul Vixie
假设没有竞争（永远）的技术商业计划

网络犯罪2.0：当云变暗时
- Niels Provos、Moheeb Abu Rajab和Panayiotis Mavrommatis
基于Web的恶意软件攻击比以往任何时候都更阴险。可以做些什么来阻止这种趋势？

最初发表于Queue vol. 14, no. 4—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全需求驱动的加密哈希标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付。直观地，技术领导者普遍接受良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进DevEx的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过介绍使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。在其快速前进的过程中，它容易受到时尚的突发奇想的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的行之有效的解决方案。用例最初于1986年引入，后来普及，是这些行之有效的解决方案之一。