在进行其他操作时，是否应该修复先前存在的缺陷？

难题：在使用新功能或修复缺陷的过程中，您会在代码中发现遗留问题。你该怎么办？对其进行修复，并有可能改变代码的行为。直到现在为止，由于某种偶然原因，它一直在工作，或者还没有发现缺陷，或者值得任何人报告。您是否应该不理会它，并允许该问题使以后的代码难以使用？解决问题只会增加原始任务的时间，并迫使您进行回归测试。很少有人会欣赏这项工作。但是，以某种方式修复它似乎正确。问题较少的代码更易于重构和构建。

当我们致力于使Web应用程序现代化时，我一次又一次地发现自己处于这种情况。当我不切实际地处理这些旧错误时，我无法分辨自己是痴迷还是光荣。您如何处理这些情况？

谢谢，科里

我在一个非常小的团队中工作，所以这取决于变化是什么：

如果它是一个很小的，显而易见的错误修复程序，那么我肯定会这样做。如果我必须处理别人的代码以及属于我的“ boyscout规则”下的其他小改进，我还会提出一些额外的评论。

如果代码纠缠在一起，以至于您不得不问“是否会改变此中断并需要测试”，那么否，则不应更改它。如果您担心，请在您的错误跟踪系统中进行介绍。

顺便说一句，这就是为什么我也尝试编写具有更明显类型签名的较小方法的原因。如果您知道没有副作用，并且可以使输入和输出匹配，则可以无风险地修复，重新排列或调整任何内部代码。

但是，不要以为缺乏理解是不以任何理由修复发现的错误或改善代码库的原因。如果没有别的，那么您对未来很友善，您肯定会回到那里修复其他问题。

编辑：您还需要注意您在该项目上的时间。显然，在紧迫的期限内，您需要专注于完成主要工作，但是如果您处于“正常负载”之下，那么我认为这里的一些清理工作会使长期的每个人都变得更加快乐。

与往常一样，这取决于。

• 如果它很小，您确定可以修复它，请修复它。
• 如果有大量的单元测试，则可以确定没有损坏任何东西，请对其进行修复。
• 否则，添加一个// TODO，将其添加到您的错误跟踪中，无论如何

基本上，您正在进行风险评估：变更与不变更的风险是什么。如果您觉得您没有足够的经验（一般而言，尤其是系统编程），请询问团队中的其他人。

实用程序员将其称为“残破的窗口”。

如果您不修复损坏的窗口，则它们有可能导致代码质量下降。而且它们越多，修复它们的工作就越大，因此修复它们的可能性就越小。

是现在还是以后修复它们，取决于判断。这是一个简单的解决方法吗？您确定代码正在执行您认为的操作吗？可能会分散您当前的工作吗？您是否有时间限制？可能会引入更多错误吗？

至少，在跟踪系统中标记该项目，并确保以后对其进行修复。即使您决定立即修复它，也要在跟踪系统中进行标记，以确保它也经过测试并记录更改，这一点很重要。

如果这是一个明显的错误，例如会破坏安全性，破坏数据或引发向用户显示的异常，请对其进行修复。否则，请问一个比您更了解代码库的人。

这取决于，如果它是一个小的错误，您可以确定您的修复影响不大，那么我个人将其作为其他工作的一部分进行修复，然后通知项目经理。

如果有任何对客户风险，用户或公司与项目经理把它和讨论过程中向前发展。他们评估风险的工作是要引起他们的注意，并提出解决方案。然后遵守他们的决定。

我们的测试人员讨厌这个。除非非常琐碎，否则我们将其记录在错误数据库中，然后将其分配给发行版并编写回归测试。如果开发人员将要进行未按计划进行的更改，那么您如何才能保留最后期限？

我曾在团队中将非严重缺陷或违反标准的问题提交为“弱代码”缺陷。我要说的是，发现严重缺陷的人有责任举起某种旗帜

这取决于错误。主要关注的是引入新的错误。最好处理一个已知问题，而不是一个未知问题。如果它很简单（例如说文本更改）或简单的逻辑错误，则我们将其修复，否则将其保留。

需要注意的一件事情是，我们是一家由4名开发人员和一名实习生组成的小商店，我修复的错误可能是我创建的错误。

如果代码显然是错误的，则修复非常简单，并且您认为影响用户的风险较低，那么请继续。这取决于专业判断。

但是，您必须记住，如果找到它，那么大概是用户还没有，或者他们已经报告了它。与其花费时间来解决用户永远不会遇到的问题，不如花时间去解决导致用户问题的问题，这可能更好。

最好先记录观察结果，然后再决定是否修复它。

与您的同事进行一些正式讨论（例如，在例行会议中）或非正式讨论（例如，在午餐期间），并在您对要修复的代码的行为有更多的信心之后进行更改。

尽管对您来说似乎是一个错误/缺陷，但这一次实际上可能是“功能”。在上一版本的最后一分钟解决一些极端的情况可能是一个实施不佳的解决方案，并且您的“干净修复”可能会复兴一些以前已解决的问题。

我将在这里逆潮流。除非您处于开发的早期原型阶段，否则永远不要立即对其进行修复，而应该提交错误报告。这有几个优点：

• 团队可以对其进行评估。它是一个真正的错误，修复它的风险是什么？
• 管理层可以确定是否足够重要，以影响将其包含在此版本中的时间表影响
• 可以将一种检测它的方法添加到测试套件中，希望以一种足够通用的方式来发现类似的错误。
• 它提供了有关前几个阶段中有多少个漏洞的有价值的指标