我正在研究Java库，并希望从中删除一些功能。我这样做的原因是公共API和设计清理。一些对象具有设置器，但应该是不可变的，某些功能已通过不同的方法实现了更好/更干净的实现，等等。

我已将这些方法标记为"已弃用"，并希望最终将其删除。目前，我正在考虑在几个冲刺(两个星期的开发周期)后删除这些内容。

是否有删除冗余公共代码的"最佳实践"？

/贾努斯·西姆(JaanusSiim)

解决方案

使用@deprecated标签。阅读API弃用文档以获取更多信息。

在每个使用该代码的人告诉我们他们已经清理完毕后，开始删除不推荐使用的代码，然后等待是否有人抱怨，然后告诉他们修复自己的代码...

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

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

以这种方式考虑，客户A下载了我们库文件或者框架的最新版本。他在这台计算机上命中了compile，突然间他看到成千上万个错误，因为成员文件或者函数不再存在。从现在开始，我们已向客户提供了一个理由，为什么不升级到新版本并继续使用旧版本。

Raymond Chen在其有关win32 API的博客中对此做出了最好的回答，

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

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

如果我们有成千上万的用户，并且几乎不与他们交谈，则时间范围可能应该在数十年之内：-)

如果用户是10个同事，并且我们每天看到他们，则时间范围很容易在几周之内。

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

鉴于这是一个库，请考虑使用不推荐使用的功能来归档版本。将此版本以源代码和编译形式提供，作为尚未将代码现代化为新API的用户的备份解决方案。 (需要二进制格式，因为即使我们在几年后仍可能无法编译旧版本。)请明确说明此版本将不受支持和增强。在版本控制系统中用符号符号标记该版本。然后继续前进。

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

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

当然，这取决于我们使用API​​的规模以及我们向客户承诺的前期准备。

如Vinko Vrsalovic所述，我们应该输入一个他们必须放弃该功能的日期。

在生产中，如果只是为了获得更简洁的代码而已，那么我倾向于将其保留在原定日期之前，只要它不会破坏任何内容。

另一方面，在开发中，我会立即执行此操作，以便快速整理内容。

我们可能对折旧在其他一些项目中如何工作的示例感兴趣。例如，下面是Django项目中用于函数弃用的策略：

A minor release may deprecate certain features from previous releases. If a feature in version A.B is deprecated, it will continue to work in version A.B+1. In version A.B+2, use of the feature will raise a PendingDeprecationWarning but will continue to work. Version A.B+3 will remove the feature entirely.