苹果记录漏洞的可悲状态(2019年)

您在MacOS或iOS中发现了错误。软件中的某些东西不能正常工作。你决定让苹果知道，然后前往http://bugreport.apple.com，用你的苹果ID登录。你填写了所需的表格，列出了复制步骤，点击了特殊的键和弦，生成了一个胖乎乎的系统诊断，附上了一些屏幕截图，希望他们能修复它。

所有的bug都是通过一个叫做雷达的内部应用程序来跟踪的；苹果内部员工只需将bug直接登录到这个应用程序中即可。外部人员使用网站“Bug Reporter”，该网站只显示特定开发人员与该错误的交互，并隐藏该错误的所有其他详细信息。这些细节是工程师的意见、bug的进度、他们何时“期望”修复它或修复它的版本，以及优先级。优先级对于bug来说很重要；如果没有设置优先级，它们就被认为是“未筛选的”。具有高优先级(1)的错误很可能得到修复，而具有较低优先级(3或4)的错误不太可能得到修复。

每个错误都放在一个特定的顶级组件中，该组件可以有子组件。精明的内部开发人员会将Bug直接记录到Bug对应的组件中，例如“AppKit/NSTableView”。这将把它直接送到需要查看它的合适的人手中。顶级组件有一个很大的下落区域，一般的bug可能会落入其中，例如“iTunes/All”。这些组件充斥着错误报告。

一旦你的虫子击中雷达，就会有人看着它。开发人员支持通常会首先查看与SDK/编程问题相关的错误。然后，它们将把它传递给更具体的顶级组件，或者直接传递给更具体的组件(即：NSWindow)。

这就是事情变得混乱的地方，这取决于你的错误所在的组件，因为错误管理依赖于团队。许多团队只有一两个QA人员来对那些大的投放区域进行错误的初始筛选。QA工程师有时会接到指示，在将错误传递给负责代码的工程师之前，要优先筛选错误并“修复期限”。这很可怕，因为许多工程师不会查看优先级较低的错误。对于“拥有代码”的工程师来说，查看错误并确定优先级要好得多。QA工程师经常要筛选大量积压的错误，一些错误可能需要几周甚至几个月的时间才能筛选出来。有时，这会导致对错误进行大规模筛选，将所有错误标记为低优先级。错误发起者必须注意到这一点，并对此进行抱怨，以获得更高的优先级。更糟糕的是，一些组织大量关闭了超过一年左右的错误，如果问题仍然存在，他们会要求发起者重新打开错误。很多人没有注意到需要验证的bug，它们只是迷失了方向。

从内部开发人员的角度来看，花时间记录一个详细的bug是相当令人沮丧的，结果却看到它一周又一周地“未筛选”。看到这种情况发生在你的虫子身上是令人沮丧的。但更糟糕的是，有时你的bug会上当受骗。其他人稍后会记录相同的错误，并且您的旧错误报告会被复制到该错误中。通常情况下，这仅仅是因为延迟了对错误的筛选。

从外部开发人员的角度来看，情况甚至更糟。当错误正在进行时，几乎没有关于它们的反馈。您不知道bug的优先级，也不知道它是否被查看和筛选过。这是苹果故意不透明。更高的透明度可能很容易泄露功能或产品，因此这是意料之中的。

希望一个bug最终会有一个单独的工程师来处理代码。许多这样的漏洞仍将不会被筛查，苹果的工程师们似乎厌恶筛查漏洞的过程。所以他们让他们坐一段时间，有时是几周或几个月。人们宁愿专注于编写新的代码，或者致力于他们必须修复的已经筛选出来的错误，而不是花时间阅读错误报告并计算出需要对其做些什么。他们不需要马上阅读并修复它，只需做一个筛选：确定优先级，何时修复(这有时是含糊不清的)，并可能要求发起人提供更多信息(或将其标记为副本)。

工程师也不喜欢筛选bug，因为有时他们不得不将它们添加到当前版本的队列中。这增加了他们发布该版本所需的工作量，这是人们不喜欢做的事情。因此，取而代之的是，许多细菌没有经过筛选。

未筛选的错误指示需要修复的潜在软件问题。显然，这很糟糕，管理层不喜欢有高的未筛选的错误数量。经理们会经常指示工程师筛选错误，或者让QA工程师来做这件事(这是不好的)。

有时QA屏幕会出现优先级较低的错误，并将其保留下来。他们永远不会被转移到适当的代码工程师那里，实际上会在系统中迷失方向。可悲的是，这种情况我见得太多了。

具有低优先级和模糊的未来修复日期的错误也会丢失。它们很少会被重新检修和修复。有时候这也没什么大不了的。有些错误太隐蔽或太罕见，无法花时间修复。

一些错误所有者不想花时间与发起者来回查找他们可能需要的一些信息。他们长时间坐在bug上，最终试图在未发布的操作系统的较新版本上重现bug。他们不能复制它，所以他们只是假设它是固定的，然后把它发回给发起人。这对外部开发人员尤其不利，我将在下面描述原因。

当错误作为已修复的错误发回时，引发该错误的内部开发人员应该验证问题是否已解决。如果问题没有解决，他们可以把它送回去。然而，内部开发人员并没有真正的动机去验证错误。管理层不会跟踪需要验证的bug，也不会真正要求开发人员对其进行验证。大多数工程师确实会验证错误；他们喜欢确保问题得到解决。但外部开发人员却陷入了更加悲哀的境地。虫子就会对它们关闭，并且已经死了。

当错误被修复时，外部开发人员确实会收到通知，但只有在操作系统的公共版本中提供修复后才会收到通知。这意味着一些错误可能需要大约一年的时间才能回到外部开发者那里，因为在操作系统向公众发布之前，错误就已经开始修复了。*通常情况下，该错误会要求外部开发人员通过安装最新的操作系统来验证该错误。对于包括我在内的一些人来说，这是不可能的；他们需要运行和支持较旧的操作系统，并且没有能力在特定的机器上安装较新的操作系统。或者，他们只是不想安装最新的操作系统，因为它没有他们想要或需要的任何东西(那就是我，我运行10.13)。即使他们真的安装了操作系统，他们也可能会发现错误并没有修复。在这一点上，已经太晚了；工程技术很可能已经关闭了这个错误，它迷失在了以太中。

这很简单：内部工程师需要承担更多责任，及时筛选错误。管理层需要让工程师有更多的时间来做这件事，这是以开发功能或修复已经屏蔽的错误为代价的。工程师应该总是被期望有一个非常低的未筛选的错误数量。

内部工程师需要在将错误发回给他们时立即验证这些错误。他们需要安装操作系统的测试版，并进行一些测试。如果没有修好，就把它送回去。

如果错误报告指的是某个问题，那么开发人员应该查看与所描述的区域交互的代码，并尝试考虑是什么导致了这种问题的发生。例如，如果一个按钮在iTunes中被错误地禁用，那么开发人员应该试着找出为什么会发生这种情况，而不是仅仅询问“如何再现这个？”

当我在苹果工作的时候，我实践了我现在所宣扬的东西。我会在一天左右的时间里筛选出我所有的虫子。我会在一周左右的时间内验证错误。我会仔细查看代码，并尝试对无法重现的错误进行理论上的修复。我觉得这是我工作的一部分，我只是把这些事情当作日常任务来做。

显然，您必须记录错误报告。记录缺少信息的bug是可以的；开发人员可以询问他们需要的详细信息。一般而言，对于与AppKit相关的错误，我会发现“系统诊断”很少能提供任何有用的信息。我不喜欢人们(通常是QA，而不是编写代码的工程师)问我要系统诊断，而我知道这不会帮助他们弄清楚任何事情。

日志重复。如果您知道其他人记录了错误，但您遇到了相同的问题，则记录相同的错误。它将被标记为副本，但这将有助于提高错误的优先级。这是可悲的，但苹果确实考虑到了这一点，并对“高复制数量”的错误进行了研究。