c# - 过时属性的使用

Question

最近有人告诉我，在我们的代码中使用属性标记许多方法是一种不好的做法[Obsolete]。这些方法在我们的代码库内部，而不是在 API 上。这些方法处理了较旧的加密功能。

我觉得这是向团队其他成员表明不应使用这些方法的一种快速且安全的方式，并提供了一条建议替代方案的信息。

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

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

Answer 1

步骤 1. 将成员或类标记为 [已过时]

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

问题是——你可以在一个程序中重构。如果 API 公开发布，而您根本无法使用您的 API 重构代码，那就更难了。这就是 Obsolete 的用途。

如果 API 在您的代码内部，那么重构是可行的方法。清理代码，不要留下乱七八糟的东西。

但是如果公共 API 发生变化，它应该 - 如果可能的话 - 慢慢完成。

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

Answer 4

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

然后，所有这些编译器警告都在不断地提醒人们在他有一点空闲时间时回去完成重构。

这到底是好事还是坏事是相当主观的。它是一个工具，就像任何其他工具一样。

Answer 5

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