使用Obsolete属性

Question

我最近被告知，在我们的代码中使用[Obsolete]属性标记了许多方法是不好的做法。这些方法是我们代码库的内部方法，而不是API。这些方法处理旧的加密函数。

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

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

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

Answer 1

步骤1.将成员或类别标记为[已废弃]

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

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

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

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

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

顺便说一句，如果有人发现很容易忽略编译器警告，则问题不在于[已废弃]。但是，长期不在代码中留下这样的调用的一个原因（即，尽可能地完成第2步）是为了确保人们最终不会习惯于编译器警告，因为他们是习惯性地回应编译代码。

Answer 2

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

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

Answer 3

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

问题是 - youCAN重构在一个程序中。如果API在公共场所出局并且您根本无法使用API​​重构代码则要困难得多。这就是Obsolete的目的。

如果API是代码的内部API，那么重构就是最佳选择。 CLean up代码，不要乱七八糟。

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

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

Answer 4

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

然后让所有那些编译器警告在周围，不断提醒有人在他有一点空闲时间后回去完成重构。

这是好事还是坏事是非常主观的。它就像其他任何工具一样。

Answer 5

这不是一个直截了当的案例。如果从工作应用程序中删除方法并重构代码，则会创建可能性，从而引入新错误并破坏正在运行的应用程序。如果该应用程序对于mision至关重要，那么影响可能会很大并且会给公司带来很多成本，需要仔细规划和测试这样的变化。在这种情况下，标记方法过时可能是值得的，它应该有助于防止人们在进一步开发中使用它们，从而使最终重构变得更容易。但是，如果应用程序不是mision严重或者引入错误的可能性很低，那么如果你有时间，重构可能会更好。最终添加[Obsolete]属性有点像todo，它的使用取决于很多因素。