完全披露：我受雇于Zend为ZendFramework编程。也就是说，以下是我的全部意见，基于我使用ZendFramework的经验，以及对各种邮件列表和其他OSS项目（尤其是PEAR、Solar和Cgiapp）的问题的回答。
我在OSS世界中最大的烦恼之一是模糊的错误/问题报告和功能请求。我已经数不清有多少次看到类似下面的报告了：
不起作用；你需要现在修复它！
不起作用；你需要现在修复它！
如果这样的报告出现在问题跟踪器上，它总是被标记为关键和高优先级。
有什么让我烦恼的？简单地说：它给那些负责维护功能X的人绝对没有任何信息可以处理：他们收到了什么结果，预期是什么，或者他们如何使用该功能。审稿人现在不得不进入一个或多个循环，与记者一起寻找该信息——浪费每个人的时间和精力。
这些报告只是稍微好一点：
不起作用—我一直从中获取，这是不正确的。
不起作用—我一直从中获取，这是不正确的。
至少这告诉审稿人他们的记者收到了什么……但它没有告诉他们他们是如何到达那里的，或者他们期待什么。
因此，在报告问题或提出功能请求时，以下内容应该成为您的口头禅：
- 重现问题或显示所需API所需的最少代码是多少？
- 预期结果是什么？
- 实际结果是什么？
李>
好的问题报告由什么组成？
一份好的问题报告必须包含以上三点，简单明了。如果没有这些信息，审稿人就没有适当处理问题的工具。
重现代码
您经常会发现应用程序出现故障。由您来找出该破坏的根本原因：我需要编写多少代码才能导致破坏发生？有时这需要一点挖掘——您可能会得到意想不到的结果，但这可能是早期出现问题的征兆。
例如，在过去几周处理Zend_Form时，我收到了一些关于新的MultiCheckbox元素如何工作的问题报告。Oneissue指出populate()没有正确填充复选框。
当按下重现代码时，记者提供了他们试图填充表单的$_POST数组：
$_POST = array(
'foo' => array(
0 => array(0 => 'bar'),
1 => array(0 => 'baz'),
2 => array(0 => 'bat')
)
);
在查看它时，我立即知道它与已报告的另一个问题有关。在那一期中，记者注意到Zend_Form为MultiCheckbox元素渲染的输入元素有多余的数组符号：
<input type="checkbox" value="foo" name="foo[][]" value="bar" />
在前一种情况下，我们看到了后一种情况的症状：冗余数组符号导致表单提交根本无法填充元素。如果前一个案例的报告者查看了用于发送他们在跟踪器中发布的$_POST数据的表单，他们可能不会注意到跟踪器中已经报告的类似问题——或者我，作为审查者,将能够快速将错误标记为重复。
无论如何，要点是：使用POST请求的值来重现问题并不是在做功课。您需要寻找重现问题所需的最少代码，$_POST中提供的值通常是问题的症状已经发生了。
创建重现代码的另一个经验法则是保持环境最小化。尝试在草稿本中编写新鲜代码，您可以一遍又一遍地运行，直到获得您要报告的结果。这做了一些事情：它有助于简化导致问题的用例，并且它通常会帮助您准确地找到问题开始出现的地方。有时，我可以证明这一点，它可以帮助您首先找到您在自己的代码中做错的地方，从而完全减少提交报告的需要。
审阅者用这段代码做什么？好吧，优秀开发人员会将它用作单元测试套件中的测试用例——这是将代码保持在重现问题所需的最低限度的另一个原因。此代码通常会出现在测试套件中，以记录问题报告，并在解决方案到位后证明问题已得到解决。
即使在报告功能请求时，上述建议也很有用，此信息很有用。然后，审阅者了解所需的API，他们可以针对它编写测试用例。
预期结果
除了重现案例，你还应该提供预期的结果。这些清楚地表明了你对代码的期望。审稿人可以通过多种方式使用此信息：
- 在测试套件中，审阅者可以使用断言中的预期结果来验证问题（或证明它现在已得到纠正）
- 以表明报告者的假设存在缺陷。在某些情况下，代码的预期与记录的断言不同，然后审阅者可以指出差异所在——这有助于教育报告者正确使用代码。
- 在功能请求，这将表明报告者期望新功能的行为方式。然后，审阅者可以将该期望用作测试套件中的断言。
实际结果
实际结果很重要，因为它们与预期结果形成对比，显示破损所在。如果审阅者无法重新创建这些结果，则可能意味着提供的重现代码不是重现问题所需的实际代码，或者可能意味着环境差异——例如操作系统或PHP版本的差异——可能是影响问题的一个因素重现问题。
在功能请求的情况下，您可以省略实际结果，因为不会有任何结果。
始终搜索您的问题或功能请求
最后，要添加到您的曲目中的一个额外的咒语：在报告问题或请求功能之前搜索问题跟踪器和/或邮件列表。。我无法告诉你我关闭了多少重复的错误，或者我不得不用“这是一个已知问题”这句话回复电子邮件多少次。做功课是值得的：搜索并查看其他人是否提出了同样的要求。在许多情况下，您实际上可能会找到其他人发布的针对您的问题的解决方案—扩展类以获得您期望的行为的方法、软件的补丁，甚至是关于什么的注释公开发行版或快照包含修复。没有理由通过报告已知问题来浪费人们的时间。
无论您相信与否，搜索问题的最佳时间是您完成其他步骤之后。除非您确切知道是什么代码重现了问题，并明确定义了您的期望和实际结果，否则很难确定您的问题何时与另一个问题相匹配。
总结
- 重现问题所需的最少代码是多少？
- 预期结果是什么？
- 实际结果是什么？
- 您是否在公共论坛中搜索过类似的请求？
如果您可以在发布您的问题之前开始回答上述问题，您将开始从那些审查您的问题或功能请求的人那里收到更详细和有用的回复，并减少“我不知道”的次数不明白”或“我需要更多信息”的回答。保证。
