使用Obsolete属性
我最近被告知，在我们的代码中使用[Obsolete]属性标记了许多方法是不好的做法。 这些方法是我们代码库的内部方法，而不是API。 这些方法处理旧的加密function。
我觉得向团队的其他成员表示不应该使用这些方法是一种快速而安全的方式，并提供了建议替代方案的信息。
其他人认为我应该完全删除这些方法，根据需要重写或重构现有代码。 此外，人们认为很容易忽视编译器警告。
当没有被第三方使用时，是否存在将代码标记为过时的“最佳实践”？ 或者这主要是主观的？
步骤1.将成员或类别标记为[已废弃]
步骤2.更新成员或类的所有内部使用，以使用替换过时方法的新方法，或将该成员或类本身标记为[已废弃]
步骤3.如果您在步骤2中将新内容标记为[已废弃]，请根据需要重复此步骤。
步骤4.删除所有过时的成员和类，这些成员和类既不公开也不被过时的公共成员或类使用。
步骤5.更新文档以更清楚地描述建议替换任何公共过时成员或类的方法。
最后，您将没有内部代码单独使用的过时代码。 没有什么可说的，你必须一次性做所有这些; 在每个阶段你都取得了进步。 从开始步骤1到结束步骤5之间的时间可以是5秒或5年，这取决于许多因素（大多数因素与复杂性有关）。
顺便说一句，如果有人发现很容易忽略编译器警告，问题不在于[已废弃]。 但是，长期不在代码中留下这样的调用的一个原因（即，尽可能地完成第2步）是为了确保人们最终不会习惯于编译器警告，因为他们是编译代码的习惯性反应。
我认为这是主观的。 如果它是内部的并且是一个相当快速的过程，那么我会执行更改。
但是，我也遇到了相应的重构需要花费更长时间的情况（整个代码库中的许多调用），在这种情况下我使用了[Obsolete]属性。 在这种情况下，新开发将使用新函数，并且有时间执行重构，直到所有调用都消失，这意味着可以删除该方法。
这取决于。 是的，你可以重构代码。 您可以…吗？
问题是 – youCAN重构在一个程序中。 如果API不在公共场所并且您根本无法使用API重构代码，那将会困难得多。 这就是Obsolete的用途。
如果API是代码的内部API，那么重构就是最佳选择。 CLean up代码，不要乱七八糟。
但是，如果公共API发生变化，它应该 – 如果可能 – 应该缓慢完成。
其余的仍然是主观的。 我不喜欢内部API的“过时”。
我之前使用它作为一种临时状态，当我们得到的旧代码最终需要重构而不是紧急时 。 大多数情况下，当编写一些新代码可以比以前更好地完成工作时，但团队中没有人有时间返回并替换现在的许多旧代码。 显然，这意味着无法立即实现简单替换的情况（有时新代码几乎完成了旧代码所做的一切，但还有一小部分function尚未实现）。
然后让所有那些编译器警告都在周围，这是一个不断的提醒，让人回过头来完成重构，当他有一点空闲时间。
这是真的好还是坏都是非常主观的。 这是一个工具，就像其他任何工具一样。
这不是一个直截了当的案例。 如果从工作应用程序中删除方法并重构代码，则会创建可能性，从而引入新错误并破坏正在运行的应用程序。 如果该应用程序对于mision至关重要，那么影响可能会很大，并且会给公司带来很多成本，需要仔细规划和测试这样的变化。 在这种情况下，标记方法过时可能是值得的，它应该有助于防止人们在进一步开发中使用它们，从而使最终重构变得更容易。 但是，如果应用程序不是mision严重或者引入错误的可能性很低，那么如果你有时间，重构可能会更好。 最终添加[Obsolete]属性有点像todo，它的使用取决于许多因素。