您是否跟踪了您的Bug跟踪系统中的“潜在错误”以及发生的错误？
我的意思是，如果您开发了一段代码，您最终意识到在特定条件下它可能会失败，但由于严格的截止日期，您没有时间实施解决方案。因此，您在代码中添加了警告，并在跟踪软件中创建“潜在错误报告”以供将来使用。希望它会被分配给某人 - 很可能是你 - 在即将到来的一个版本中为其工作。
谢谢！
答案 0 :(得分：4)
是的，如果您可以为它编写测试用例，请编写一个“贪睡”单元测试。这些测试检查了日期，因此可以在一个月左右开始失败“如果”它还没有修复。
答案 1 :(得分：3)
首先：是。
我建议在代码中使用测试驱动开发而不是警告。然后，每个人（尤其是新的团队成员）都会看到失败的测试，并且比未分配的错误或评论更好地发出警告。
答案 2 :(得分：2)
据我所知，这正是一个错误。我认为大多数人认为这些类型的错误是“可接受的”，当你必须平衡修复它与推迟发布日期时。
答案 3 :(得分：1)
长答案：“哎呀”
你永远不知道将来会花多少时间在你重新分配它时再次尝试找到那段代码。最好是积极主动。
答案 4 :(得分：1)
可能只是我，但是当我部署其中一个时，它总是首先出错。这可能很难，但更好的方法就是解决它。
答案 5 :(得分：0)
我会像跟踪任何其他错误一样跟踪“潜在错误”，但也许可以清楚地表明它是一个尚未发生的错误，但可能会因某些条件而发生。尽可能清楚和具体，因为它可能需要一段时间，直到你解决这种错误，如果它需要修复。好问题！
答案 6 :(得分：0)
经常。它是“做光”口头禅的一部分;如果您已通过验收测试，那么您已完成功能，但如果您可以检查该代码并发现它可能会失败，则应在代码或错误跟踪器中记录该代码。如果您的PO / BA引入了另一个验证测试，该测试将修复代码中的缺陷，或者记录您知道它将失败的案例的缺陷，那么您重新访问该代码并重构它以使其更加健壮。这只是比赛的一部分。
答案 7 :(得分：0)
更好的是，在发布文档中包含那些容易出错的条件，这样当它们发生时，您就不会失去客户的信心，是的，在xls或bug跟踪器中的某处跟踪它们。
答案 8 :(得分：0)
潜在的错误只是您想要跟踪的另一种工作，所以是的，跟踪它。您是否在TODO列表上执行该项工作取决于许多其他优先级