一切皆是 Bug (或 Issue)

by David Boreham | Mar 26, 2025 | Programming

如果我告诉你，我发现了一种高效、有效、可靠甚至令人愉悦的软件项目运行方式，你会怎么想？

“请继续……”，我希望你会这样说。

首先要说明的是，这并不是一个新的发现。实际上，这是一个故事，开头是“很久以前，在一个遥远的办公室里”。让我们登上便捷的时光机，回到我在硅谷第一份正式工作的第一天。那个地方有点像今天所谓的 FAANG：

从人力资源部门的入职介绍中解脱出来后，我来到了大楼、楼层和隔间，在那里我兴奋地终于加入了真正知道自己在做什么的人的行列。或者至少非常接近。

但是所有的隔间都是空的。周围没有人。我想知道现在该做什么，我看到有人朝我走来：我的新老板，后来我意识到她是一位出色的经理。“你要参加 bug council 吗？”她问道。我不知道什么是 bug council，尽管它模糊地让人想起一群严肃的人坐在低矮、高靠背的皮革转椅上。也许在决定宇宙的命运。

事实证明，它由产品团队的每个人坐在会议室里组成，每个人都拿着一份产品的 bug 列表打印件，按优先级排序。P0 在顶部（CS 编号，据说是因为一位主管想要比最初的 P1 更紧急的东西，就像吉他上的旋钮“转到 11”一样）。

按照列表向下工作，我们的负责人会打电话给拥有每个 bug 的人，让他们提供状态更新、突出显示任何阻碍进度的因素，并回答团队的任何问题。每个人都在同一页上。字面上地。有时需要更新 bug——更改其优先级，添加另一个阻塞它的 bug，将其重新分配给另一个团队，或将其标记为在未来的版本中修复。虽然这在 Wi-Fi 出现之前，但有人将一台笔记本电脑插入墙上的插座，实时进行请求的 bug 更新。一旦 P0-P2 bug 被覆盖，会议就结束了，每个人都回去工作：修复剩余的 bug。

这似乎很简单：通过按优先级顺序列出所有 bug 并从列表中向下工作来修复它们，直到没有剩余的 bug，从而交付优秀的软件。但我会了解到，在简单性之下，存在着深刻的心理力量驱动着这个过程，这些力量是通过我们使用的 bug 跟踪系统中设计的四个关键原则来发挥的。

该系统今天仍然存在，很久以前被重写为 Bugzilla。那时它被称为 BugSplat。它是在内部通过草根努力开发的，并且是最早的纯 Web 应用程序之一，其功能已经过磨练，可以满足其用户的需求。优质的狗粮。

第一个关键原则是，所有需要完成的任务都进入系统。新功能、缺失的文档、令人困惑的 UX、糟糕的性能，当然还有用户报告的实际 bug。我们将一切都视为 bug。BugSplat 是唯一的项目规划系统。这意味着组织中的所有计划，都可以被视为是在这一组连贯的 bug 上的预测，并朝着任何目标进行管理。稍后会详细介绍。

第二个是 bug 记录的模式是通用的，在很大程度上是固定的，并且是有主观倾向的。这些主观倾向是通过长期使用该系统获得的。下图给出了一个概念。Bug 不仅仅是打开或关闭。Bug 的状态有细微差别。如果没有以一致的方式在模式中捕获，最终会以令人困惑的文本注释的形式捕获，或者只是丢失。通过使用捕获 bug 状态、优先级、严重性和相互依赖性的单个综合模式，该系统会提示其用户在他们的流程中也保持一致、清晰和具体。

Image from: https://www.bugzilla.org/docs/3.6/en/html/lifecycle.html

第三个原则是，只能有一个人被分配对 bug 的责任。一次只能有一个人——根据需要，bug 可以并且经常被重新分配。只有在细粒度的基础上捕获明确的责任时，bug 系统才能用作项目管理工具。这样，任何人（包括他们的经理）都可以轻松地看到一个人正在做什么，接下来要做什么，以及最近做了什么。很容易看出某人是否超负荷。每个人都可以享受所有权和成就感的温暖。

最后一个原则是，bug 列表的查看方式是作为强大查询的结果。与一致的固定记录模式相比，查询可以丰富、具有表现力、可保存和可共享。这允许用户策划和共享一组适合其特定目的和上下文的 bug 列表视图。这就是 bug council 列表的创建方式：针对我们的产品和正在开发的当前版本的所有新的和打开的 bug 的查询，按优先级排序，然后与团队共享。个人开发人员可能希望专注于显示分配给他们的所有 bug 的列表，跨所有产品和版本，再次按优先级排序。安全工程师可能更有兴趣查看按严重性而不是优先级排序的 bug。这里要注意的是，查询集是无限的：bug 本身不需要更改模式来适应这些不同的目的和上下文。每个人都可以制作自己的任务清单。清除这些任务清单就是取得进步的方式。

经过几十年的反思，正是这四个原则，被融入 bug 系统中，构成了我们产品发布列车运行的轨道。

由于所有这些都发生在很久以前，并且显然运行得很好，所以如果我们回到 DeLorian，我想我们应该期望今天的人们正在做一些同样好或更好的事情。

然而，我的经验是：事实并非如此。我们首先会注意到的是（除了 Dr. Evil 被解冻之外），bug 现在被称为“issue”。据推测，这源于希望使 Bugzilla 之后的商业 bug 跟踪系统（JIRA 及其同类产品）具有更广泛的吸引力。但这与词源相矛盾：bug 这个词比计算机还要早。

我们还会注意到，用于管理软件项目的 Web 应用程序主要关注源代码控制（这是一种令人困惑的说法：每个人现在都在使用 GitHub）。GitHub 在如何管理 bug 方面制造了一个难题：使用与源代码控制紧密集成的 bug 系统（他们称之为：GitHub Issues），或者不使用（例如，JIRA 用于 bug，但 GitHub 用于源代码）？这是一个艰难的决定，意见肯定不同，但我坚决站在前者阵营。我喜欢我的 bug 和我的源代码紧密地依偎在一起。

为什么呢？第一个原因与用户管理有关：如果我们将 bug 放在 JIRA 中，那么现在有人必须确保需要在 JIRA 中配置需要查看 bug 的用户。这至少是一种麻烦，并且可能还会产生额外的成本。但是如果 bug 在 GitHub Issues 中，我知道任何可以查看代码的人都可以看到 bug，即使他们在不同的组织中。对于开源项目来说，这是一个很大的好处，可以避免分裂项目成员资格。第二个原因是紧密集成允许一些非常有用的功能。例如，自动列出版本说明中修复的一组 bug 以及 bug 和 pull request 之间的轻松来回引用。在代码管理和 bug 管理之间具有一致的 UI 也很不错。最后，除非 GitHub Issues 被禁用，否则用户无论你认为你在哪里管理你的 bug，都会在那里提交一些 bug。现在你有两个问题……

因此，假设我们打算使用 GitHub 及其 Issues 作为统一的 bug 和项目管理系统，那么它与我们过去四个关键原则相比如何呢？（剧透：不太好）。

第一个原则：是否所有项目任务都被视为 bug 并输入到 bug 系统中？好吧，这取决于谁在运行项目，根据我的经验，通常不是，因为（见下文）GitHub Issues 的功能非常差，以至于人们最终会同时使用一个或多个其他的项目规划系统。

第二个原则：bug（对不起…… issue），应该具有一致的主观模式，以支持开发过程。GitHub Issues 在这里得分和人们能想象的一样糟糕。开箱即用，模式非常少。您唯一可以添加到其中的是用户可定义的标签。标签是按存储库定义的（最近也在组织级别定义），但每个人都可以并且通常会定义不同的标签集。无论您在标签上有多么的创造力，它们的局限性都将成为一个……问题。例如，我可以尝试定义 bug 优先级的标签：P0、P1、P2 和 P3。但是由于任何标签都可以分配给一个 bug，因此没有什么可以阻止一个 bug 同时具有所有优先级（请参见下面的“Bad bug”）。

第三：bug 应该只分配给一个人。GitHub Issues 将允许您将一个 bug 分配给任意多个人。我在野外见过 10 个受让人的例子。扩散的责任已经进入房间。下面的 Bad bug 被分配给了我和 Thomas。

第四：灵活的查询。甚至在查看 GitHub Issues 的查询功能之前，它缺乏高质量的模式使得您可以做的任何查询都不太有用。但即便如此，查询仅限于对标签、所有者和受让人的等式匹配，并且仅支持在创建和更新时间戳上进行排序。例如，无法查询由特定人员解决的 bug，并按解决时间排序。当然，也无法进行 bug council 查询：按优先级排序的 bug 列表，因为没有优先级字段，也无法对其进行排序。也没有办法保存或共享查询，但您可以尝试从地址栏复制查询 URL 并将其保存在某处以供以后粘贴。

screenshot with GitHub Issues query results

由于 GitHub Issues 目前在我们的四个原则上表现不佳，因此仅使用它来管理项目的任何尝试都将非常令人沮丧。是否有避免永远令人沮丧的替代方案？我们可以尝试说服 Microsoft 添加缺失的功能，但街头巷尾的传言是这不会发生，因为 Microsoft 有一个 类似于 JIRA 的产品，几乎没有人听说过，Microsoft 宁愿尝试向您出售该产品，而不是改进 GitHub Issues。只是说说而已。

当然，有一些 GitHub 替代方案，例如 GitLabs 和 Bitbucket。通常，这些提供比 GitHub 更好的 issue 管理功能，但仍然没有达到我们的四个原则。

因此，我们所处的情况是没有现有的商业服务具有我们想要的功能。在这种情况下，最好的选择可能是选择同一类别中的一个优秀的开源项目，然后将这些功能添加到其中。这甚至不需要内部专业知识或与项目团队的直接赞助安排，因为有像 Bozeman Pass 团队这样的独立开发人员，他们将（收取适度的费用……）承诺向任何开源项目添加功能。此服务包括收集客户的需求、编码、测试、创建 pull request，并最终与项目团队积极互动以使新代码“上游”。

让我们快速看一下我们添加到名为 Gitea 的项目中的一个功能。在我们开始开发新功能之前，与 GitHub 相比，Gitea 已经进行了一些升级，包括支持“范围”标签集，这是一种表示标签应仅具有多个可能值之一的方法。此功能可用于实现具有优先级语义的字段，例如在下面的屏幕截图中，我们定义了一个 priority 标签集，其可能值为：low、medium、high 和 critical。请注意，尽管 Gitea 可以表示优先级字段，但它无法按优先级对 bug 列表进行排序。

screenshot with Gitea v1.23 query results

输入我们添加到 Gitea 的一项功能。它旨在添加缺少的排序功能。虽然添加该功能不需要大量的代码更改，但正如您从 pull request 中的注释中看到的那样，通常需要一些不可预见的问题和相关的调整才能完成上游过程。这是结果，终于可以使用类似于 GitHub 的系统对优先级排序的 bug 列表进行排序：

screenshot with Gitea PR #33206 query results

除了当前的工作之外，我们的目标最终是将剩余的缺失的“四个原则”功能添加到 Gitea 中。然后我们可以回到“bug council 方式”创建软件。

敬请关注！