过时属性的用法

Question

最近有人告诉我，在代码中使用 [已过时] 属性。

[Obsolete("This property is obsolete. Use NewProperty instead.", false)]
public string OldProperty { get; set; }

[Obsolete("This method is obsolete. Use NewMethod instead.", false)]
public void OldMethod()
{
    // Method implementation
}

这些方法是我们代码库的内部方法，而不是 API 上的方法。这些方法处理较旧的加密函数。

我认为这是一种快速、安全的方式，可以向团队其他成员表明不应使用这些方法，并提供一条消息来建议替代方案。

其他人认为我应该完全删除这些方法，根据需要重写或重构现有代码。此外，人们认为很容易忽视编译器警告。

当第三方不使用代码时，是否有将代码标记为“过时”的“最佳实践”？或者这在很大程度上是主观的？

Answer 1

这不是一个简单的案例。如果您从正在运行的应用程序中删除方法并重构代码，则可能会引入新的错误并破坏正在运行的应用程序。如果该应用程序是关键任务，那么影响可能会很大，并且会让公司花费大量资金，因此需要仔细规划和测试此类更改。在这种情况下，将方法标记为过时可能是值得的，它应该有助于防止人们在进一步的开发中使用它们，从而使最终的重构变得更容易。然而，如果应用程序不是任务关键型或者引入错误的可能性很低，那么如果您有时间，重构可能会更好。最终添加 [Obsolete] 属性有点像待办事项，其使用取决于许多因素。

Answer 2

当我们有旧代码需要重构最终但不是紧急时，我以前曾将它用作一种临时状态。最常见的情况是，编写了一些新代码，比之前的代码更好地完成了工作，但团队中没有人有时间回去替换大量旧代码。显然，这意味着无法立即进行简单的直接替换（有时新代码几乎可以完成旧代码所做的所有事情，但还有一小部分功能尚未实现） ）。

然后，所有这些编译器警告都会持续提醒某人在有一点空闲时间时返回并完成重构。

这到底是好事还是坏事是相当主观的。与其他工具一样，它也是一个工具。

Answer 3

这取决于。是的，您可以重构代码。您可以...吗？

问题是——你可以在一个程序内重构。如果 API 公开，并且您根本无法使用您的 API 重构代码，那么事情就会困难得多。这就是 Obsolete 的用途。

如果 API 是代码内部的，那么重构就是正确的选择。清理代码，不要留下混乱。

但如果公共 API 发生变化，如果可能的话，应该慢慢进行。

其余的仍然是主观的。我不喜欢内部 API 的“过时”。

Answer 4

我认为这是主观的。如果它是内部的并且是一个相当快的过程，那么我会执行更改。

但是，我也遇到过相应的重构花费了更长的时间（整个代码库中的许多调用）的情况，在这种情况下我使用了 [Obsolete] 属性。在这种情况下，新的开发将使用新功能，并且任何有时间的人都会进行重构，直到所有调用都消失，这意味着可以删除该方法。

Answer 5

步骤 1. 将成员或类标记为 [Obsolete]

步骤 2. 更新成员或类的所有内部使用，以使用替换过时方法的新方法，或将该成员或类本身标记为 [Obsolete]

步骤 3.如果您在步骤 2 中将新内容标记为 [已过时]，请根据需要重复此步骤。

步骤 4. 删除所有既不是公共的也不是被过时的公共成员或类使用的过时的成员和类。

步骤 5. 更新文档以更清晰地描述建议替换任何公共过时成员或类的方法。

最后，您将不再有仅由内部代码使用的过时代码。没有什么可说的，你必须一次性完成所有这些；在每个阶段你都取得了进步。开始步骤 1 和结束步骤 5 之间的时间可能是 5 秒或 5 年，具体取决于许多因素（其中大多数与复杂性有关）。

顺便说一句，如果有人发现很容易忽略编译器警告，那么问题不在于[已过时]。然而，不要在代码中长时间保留此类调用（即尽快完成步骤 2）的一个原因是确保人们最终不会习惯编译器警告，因为它们是编译器警告的一部分。编译代码的习惯反应。