17
在诊断和修复缺陷之前坚持重现每个缺陷是否合理？
我在一家软件产品公司工作。我们拥有实施我们产品的大型企业客户，我们为他们提供支持。例如，如果有缺陷，我们会提供补丁等。换句话说，这是一个非常典型的设置。 最近，针对客户在日志文件中发现的与我方产品的集群实现中的并发数据库访问有关的异常，已发出并分配了票证给我。因此，此客户的特定配置对于此错误的发生可能很关键。我们从客户那里得到的只是他们的日志文件。 我向我的团队建议的方法是尝试在类似于客户的配置设置中重现该错误并获得可比的日志。但是，他们不同意我的方法，即我不需要重现该错误，因为该错误过于耗时，并且需要在VM上模拟服务器集群。我的团队建议我只是“遵循代码”以查看线程和/或事务不安全代码的位置，然后将更改放入简单的本地开发工作中，而不是像发生事件的环境那样的集群实现错误的来源。 对我来说，要制定一个抽象的蓝图（程序代码）而不是一个有形的，可见的表现形式（运行时再现）似乎很困难，所以我想问一个普遍的问题： 在诊断和修复缺陷之前坚持重现每个缺陷并对其进行调试是否合理？ 要么： 如果我是高级开发人员，我是否应该能够阅读多线程代码并对其在所有用例场景中的工作情况有一个清晰的了解，而不是需要运行应用程序，亲自测试不同的用例场景并逐步完成代码一行一行？还是我对这种工作环境的要求很差？ 调试sissies吗？ 我认为，响应事故单提交的任何修复程序都应在模拟的环境中进行测试，该环境应尽可能接近原始环境。您还怎么知道它将真正解决该问题？这就像发布一款新车型时一样，没有用假人对它进行碰撞测试即可证明安全气囊确实有效。 最后但并非最不重要的一点，如果您同意我的看法： 我应该如何与我的团队交谈，以说服他们我的方法是合理，保守和防弹的？