如何处理函数库中的反预测?

设置日期并在@deprecated标记中公布。删除所需的时间取决于代码拥有的用户数量、您与他们的联系程度以及更改的原因。

如果你有成千上万的用户,而你几乎不与他们交谈,那么时间范围应该在数十年之内:—)

如果你的用户是你的10个同事,你每天都会看到他们,那么时间范围很容易在几周之内。

/**
 * @deprecated
 * This method will be removed after Halloween!
 * @see #newLocationForFunctionality
 */

以这种方式考虑,客户A下载库文件或框架的最新版本。他点击了这台机器上的compile,突然看到数千个错误,因为成员文件或函数不再存在。从这一点开始,你就给了客户一个理由,为什么不升级到你的新版本,继续使用旧版本。

Raymond Chen在他的关于win32 api的博客中对此作出了最好的回答,

不过,我们在软件公司的经验是,一旦编写了API,我们就必须将API带到产品生命周期的末尾。为了帮助用户使用新版本,我们提供了与新框架中旧命令的向后兼容性。

这取决于代码重建的频率。例如,如果有4个应用程序正在使用库,并且每天都要重新生成它们,则一个月的时间足以修复不推荐使用的调用。

此外,如果使用不推荐使用的标记,请提供一些注释,说明哪些代码替换了不推荐使用的调用。

使用 @deprecated 标签。阅读 Deprecation of APIs 文档以获取更多信息。

在所有使用该代码的人都告诉您他们已经清理了自己的代码之后,开始删除不推荐使用的代码,然后等待并查看是否有人投诉-然后告诉他们修复自己的代码…

鉴于这是一个库,请考虑使用不推荐使用的函数来存档版本。使这个版本既可以是源代码,也可以是编译后的版本,作为那些没有将代码现代化为新API的人的备份解决方案。(二进制形式是必需的,因为即使您在几年内也可能在编译旧版本时遇到困难。)请明确表示,此版本将不受支持和增强。在版本控制系统中用符号标记此版本。然后往前走。

这当然取决于您的API使用的规模以及您预先向客户承诺的内容。

正如Vinko Vrsalovic所描述的,您应该输入一个日期,当他们需要放弃这个功能时。

在生产中,如果只是“简单”地获取更干净的代码,那么我倾向于在不破坏任何东西的情况下,将事情保留在适当的位置,甚至超过了降级日期。

另一方面,在开发过程中,为了快速地解决问题,我会立即进行处理。

您可能对一些其他项目中折旧是如何工作的示例感兴趣。例如,下面是 policy in the Django project for function deprecation 是:

小版本可能会取消先前版本的某些功能。如果版本A.B中的某个功能被弃用,它将继续在版本A.B+1中工作。在版本A.B+2中,使用该功能将引发挂起的拒绝警告,但将继续工作。版本A.B+3将完全删除该功能。

很遗憾您没有使用.NET:。(

内置的 Obsolete 属性生成编译器警告。