被分支了

因开源软件而受损

亲爱的 KV，

当大多数开源项目都只是建议你从 GitHub 或 SourceForge 获取最新代码时，如何才能基于开源软件制作合理的软件包？我们可以像 GitHub 鼓励的那样 fork 代码，然后制作我们自己的版本，但这会将我们期望项目方承担的发布工程工作转移到我们身上。

被分支了

亲爱的 Forked，

简短的回答是你不能，但如果我只能说这些，我就不会费心回复这封信了，所以让我对此做更多解释。

从打包系统转向 SaaS（软件即服务）的优势和劣势之一是持续滚动发布。当用户与其软件之间的所有交互都通过 Web 浏览器代理时——减去任何客户端代码，这实际上是在与软件开发人员控制下的服务器交互——那么推出新的软件版本就只是更改服务器上的软件的问题。大多数以这种方式提供软件的公司可以，并且经常这样做，每天甚至每天多次推出软件。 SaaS 为软件行业的某个领域提供了惊人的自由度。为什么还要担心错误呢，反正它们可以在下一次推送中修复？

这种开发思维模式的缺点是，它在接口维护方面引入了一定程度的惰性。如果你可以在下一次推送中推出升级，为什么还要关心维护 API 呢？如果你的 API 的消费者数量很少，这种态度几乎没有负面影响。然而，一旦你将你的软件放到 GitHub 或类似的服务上共享，你就有了一个未知的社区依赖于你的软件。你应该对这些外部用户承担一些责任吗？嗯，如果你不承担，那么你就应该避免共享你的软件，因为它实际上是不可共享的，除非在非常广义的意义上。是的，任何人都可以“fork”你的 repo 或下载代码并使用它，但是如果你的态度对它的公共面——它提供的 API——如此轻率，以至于你甚至懒得在你进行 API 更改时标记你的源代码树，那么他们就无法依赖它。

无论软件是为打包还是为 SaaS 开发的，一旦它有了一组消费者，就需要使用一些标准实践来维护它。你可能不会像术语所说的那样“切一个版本”，即提供一个可供下载的打包软件单元，尽管这样的软件包确实让我们这些维护软件包仓库（如 FreeBSD/Mac Ports、Red Hat RPMs、Yum 等）的人的生活更轻松。然而，至少，你必须表明你何时更改了 API，因为 API 是你的软件包与世界其他地方之间的合同。指示此 API 更改的最简单方法是用发布标签标记你的源代码树。选择标签名称是一个单独的、痛苦的和乏味的讨论，我在这里不会深入探讨，只想说标签含义的一些一致性将对你的下游用户有所帮助。

思考何时用发布标签标记你的代码树有一些方便的副作用。首先，它迫使你和你的团队专注于一个最终目标，这将帮助你避免软件开发的“抛光污物”模式。软件工程师以热爱完美而闻名，并且不愿发布软件，直到它完成为止，而“完成”的定义通常非常模糊。思考什么构成软件的发布，使开发人员专注于他们可以共同努力的终点。 API 更改与创建这样一个发布点一样是一个很好的理由。

其次，它有助于将大型项目分解为逻辑上相关的阶段。很少有项目小到在第一次发布后就完成——除非那是它们完全失败的时候。既然你知道软件会有多个版本发布，最好为此做好计划——尽管，我知道，对许多人和团队来说，“计划”是一个令人讨厌的词。在你这样做的时候，关于变更的维护良好的发布说明对于让下游用户满意大有帮助。

如果你认真对待共享你的软件，那么你应该认真对待你如何共享它：考虑发布点，标记你的代码树，并且不要在不通知用户的情况下更改 API。

亲爱的 KV，

我在使用开源软件时最不喜欢的部分之一是它似乎永远不完整。我会下载、构建和安装一个开源软件包，尝试使用它，然后发现它几乎可以工作，但它会以不可预测的方式失败。然后我会阅读该项目的论坛或邮件列表，或者只是搜索 Stack Overflow，并发现该软件存在项目主页上没有指出的严重限制。应该有一个对开源软件质量进行评级的网页，以便用户可以快速确定一个软件是否适合使用。

因开源软件而受损

亲爱的 Short，

我发现你在信中批评开源软件很奇怪。你难道从未使用过不符合期望或不符合其营销炒作的专有产品吗？如果是这样，我想请你给我分享一点你在抽的东西。

“几乎可以工作的工具”是软件和计算系统中普遍存在的一个问题。开发人员是乐观主义者，他们会承诺给你月亮，但实际上只会把你送到 LEO（近地轨道）。是的，从 LEO 看到的景色很棒，但这不会让你的全球通信卫星获得它真正需要的视野。除了告诉你对所有开发人员和营销声明都持保留态度之外，还能做些什么来避免意外呢？

你不应该在使用工具然后在它没有像你预期的那样工作时才去网上求助，而应该反过来做这些事情。互联网的伟大之处之一是它拥有大量的错误消息，以及评论中的对话几乎从不消失的事实。将一些精选的词语与你选择的软件包联系起来，可能会比“下载并尝试”的工作模式更能告诉你它是否适合你的需求。我特别喜欢这些词：crash、won't build、partial failure、segfault 和 slow。将这些词语与你的软件包名称结合起来，在你喜欢的搜索引擎中输入它们，你至少可能会被预先警告。

你还提到了一个项目的论坛和邮件列表。你为什么不先阅读它们呢？你会在没有检查的情况下买房子吗？你会在没有看到的情况下买二手车吗？如果不会，那么你为什么要尝试一个软件而不阅读它的用户对它的评价呢？虽然罗马人从来没有“下载”这个词，但软件和任何其他你可能购买的东西一样，也受“买者自负”原则的约束。

最后，对于任何作为研究生项目一部分的软件，我都会非常小心。虽然许多此类项目产生了完整的系统，但相当多的项目产生了一个仅够获得学位的系统，然后在学位授予的那一刻就被放弃了。随着各国政府开始要求资助的研究项目不仅将其论文而且将其软件也放在网上——他们应该这样做——我预测我们将看到这种“几乎可以工作”的工具的持续扩散。

喜欢它，讨厌它？告诉我们

[email protected]

Kode Vicious，凡人称之为 George V. Neville-Neil，以网络和操作系统代码为乐和盈利。他还教授与编程相关的各种主题的课程。他的兴趣领域是代码探险、操作系统和重写你的烂代码（好吧，也许不是最后一个）。他在马萨诸塞州波士顿的东北大学获得计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于 Queue 第 12 卷，第 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 年引入并在后来普及，就是这些成熟的解决方案之一。