版本厌恶

解决代码依赖性问题

亲爱的 KV，

最近，我一直在尝试拼凑一组本应协同工作的软件包，但它们似乎非常脆弱。它们脆弱性的主要来源在于开发人员如何“解决”包、库及其自身软件之间的依赖关系。他们使所有部件协同工作的解决方案是将库或包的版本编码到文件系统中，例如，/opt/pkg-v2.87/lib/.... 正如您可能想象的那样，当库或包升级时，这给我们这些软件使用者带来了无尽的麻烦。我已经数过至少有 30 个地方是这样做的。您不能告诉我这是处理这个特定问题的正确方法，但这些人是付费的专业人士，而且我们为他们的软件付了钱。KV 会怎么做？

版本厌恶

亲爱的厌恶，

解决您的问题有很多种方法，其中只有一种方法需要将一些尝起来像苦杏仁的东西溶解到向您出售该软件的 корпоративный субъект 的咖啡壶中。如果您这样做并被抓住，请不要告诉任何人您从哪里得到的这个主意。

依赖性分析和解析以及版本控制的问题，自从软件库的早期就一直困扰着我们，而一些解决方案，例如用于包系统的 SAT 求解器，既聪明又优雅，而且大多工作良好。构建依赖性通常由诸如 automake 和 autoconf 之类的系统处理，只要您从不查看它们内部，它们就非常有用。如果您查看内部，您看到的与其说是香肠是如何制作的，不如说是动物是如何被杀死、切块、切片、折叠成三份、出售、购买、用作卫生纸、回收成面巾纸，最后又作为 makefile 吐出来，长到会让您头晕目眩——而不是那种令人愉悦的头晕目眩，而是一种您必须躺下休息一个小时才能让头晕消失的方式。所有这些都说明这些问题已经解决，解决方案通常复杂而曲折，但我们都举起一杯——或一小瓶——向那些着手解决这些问题的人致敬。

然后还有一些人，要么出于无知，要么出于愚蠢，决定只是随意尝试，并以他们自己独特的方式解决问题。您今天肯定是在与这些人打交道。我想您可以针对该软件提交一个错误报告，看看是否有人修复它。但是考虑到他们已经给您的东西的质量，我认为这不太可能。

既然您已经能够计算出软件中犯下的这些“罪行”的数量（您数了 30 个），我假设您拥有一定数量的源代码；也许甚至全部作为源代码交付。一个快速而非常肮脏的解决方案是使用独特的 sed（流编辑器）程序来根据需要更新版本号。您可以在这里找到手册页，但我相信 Stack Exchange 或其他一些作弊网站会给您提供代码来“在我的代码中交换版本号”或其他类似的东西。只需将代码放到某个 repo 中，找到 sed(1) 的正确咒语，牺牲您选择的活体动物，然后瞧？，您就可以更新版本以匹配最新的库。纯粹主义者会尖叫说这不是解决问题的正确方法，他们是正确的，但纯粹主义者很少有必须在星期五晚上赶赴的热门酒吧约会，因此有足够的时间来做正确的事情，而我们其他人则在努力把事情做对。

当然，更好的方法——同样您需要源代码才能做到这一点——是更新代码以实际接受路径参数或查询某种环境变量 (MYLIBPATH)，该环境变量可用于将软件指向正确的位置，无论您想使用哪个版本。如果您走这条路线，请务必告诉开发人员您会向他们发送补丁，只要他们还没有喝您为他们煮的咖啡。

这里更深层次的观点是，永远不应在代码本身内部硬编码版本或路径。代码需要具有灵活性，以便它可以安装在任何地方（硬编码 /usr/local 是公然愚蠢的，但仍然存在）并在任何地方运行，只要必要的依赖项可以解析，无论是在静态编译代码的构建时还是在解释代码或具有动态链接库的代码的运行时。正如 KV 刚刚指出的那样，目前有很好的方法可以正确地做到这一点，因此令人遗憾的是，仍然有这么多人继续犯错。

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

最初发表于 Queue 第 19 卷，第 1 期—
在数字图书馆中评论这篇文章

更多相关文章

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 年首次引入并在后来普及，就是这些行之有效的解决方案之一。