如何处理功能嘲在图书馆？

题

我工作的一个Java图书馆和希望删除某些职能。我的原因是公共API和设计清理工作。某些对象有者，但应将不可改变的，一些功能已实施更好的/清洁在不同的方法，等等。

我已经标明这些方法'弃用'，以及想要消除他们最终。目前我正在考虑删除这些后几冲刺(两个星期发展的周期)。

是否有任何"最佳做法"有关删除多余的公共编码吗？

/JaanusSiim

解决方案

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

如果你有成千上万的用户并且几乎没有与他们交谈，那么时间框架应该在几十年的范围内： - ）

如果您的用户是您的10位同事并且您每天都会看到它们，那么时间范围很容易在几周内完成。

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

其他提示

以这种方式考虑，客户A下载最新版本的库文件或框架工作。他在这台机器上遇到编译，突然他看到成千上万的错误，因为成员文件或函数不再存在。从现在开始，您已经向客户提供了不升级到新版本并保留旧版本的原因。

Raymond Chen通过他关于win32 API的博客

回答了这个问题

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

这取决于代码重建的频率。例如，如果有4个应用程序使用该库，并且它们每天都在重建，则一个月的时间足以修复已弃用的调用。

此外，如果您使用已弃用的代码，请提供一些注释，说明哪些代码替换了已弃用的代码。

使用 @deprecated 标签。阅读弃用API 文件了解更多信息。

每个使用该代码的人都告诉你他们已经清理了他们，开始删除已弃用的代码并等待，看看是否有人抱怨 - 然后告诉他们修复自己的代码......

鉴于这是一个库，请考虑使用已弃用的函数归档版本。以源代码和编译形式提供此版本，作为那些尚未将代码现代化到新API的人的备份解决方案。（需要使用二进制形式，因为即使您在几年内编译旧版本也可能会遇到问题。）明确表示不支持和增强此版本。在版本控制系统中使用符号符号标记此版本。然后前进。

这当然取决于在其规模API用和什么你答应提前给你的客户。

如通过Vinko Vrsalovic，你应该进入一个日期时，他们必须期望放弃的功能。

在生产，如果这是"只是"的问题获得更清洁的代码，我倾向于留下的东西在地方，甚至过去的嘲日期，只要它不会破坏任何东西。

另一方面在发展我立即这样做，以便把事情整理出来的快。

您可能对某些其他项目中弃用的工作原理感兴趣。例如，下面是关于函数弃用的Django项目中的策略是：

次要版本可能会弃用先前版本中的某些功能。如果不推荐使用版本A.B中的功能，则它将继续在版本A.B + 1中工作。在版本A.B + 2中，使用该功能将引发PendingDeprecationWarning但仍将继续工作。版本A.B + 3将完全删除该功能。

太糟糕了，你没有使用.Net :(

内置的已过时属性生成编译器警告。

许可以下： CC-BY-SA 和归因