我正在开发一个 Java 库,并希望从中删除一些函数。我这样做的原因是公共 API 和设计清理。一些对象有设置器,但应该是不可变的,一些功能在不同的方法中实现得更好/更干净,等等。
我已将这些方法标记为“已弃用”,并希望最终将其删除。目前我正在考虑在几个冲刺(两周的开发周期)之后删除这些。
是否有任何关于删除冗余公共代码的“最佳实践”?
/亚努斯西姆
设置一个日期并在@deprecated 标记中公开它。删除的时间取决于您的代码拥有的用户数量、您与他们的联系程度以及更改的原因。
如果您有成千上万的用户并且您几乎不与他们交谈,那么时间范围可能应该在几十年的范围内:-)
如果您的用户是您的 10 位同事并且您每天都看到他们,那么时间范围很容易在几周范围内。
/**
* @deprecated
* This method will be removed after Halloween!
* @see #newLocationForFunctionality
*/
以这种方式考虑,客户 A 下载您的库文件或框架的最新版本。他在这台机器上点击编译,突然他看到成千上万的错误,因为成员文件或函数不再存在。从此时起,您就给了客户一个不升级到新版本并继续使用旧版本的理由。
Raymond Chen 在他关于 win32 API 的博客中回答了这个问题,
不过,我们在软件公司的经验是,一旦编写了 API,我们就必须将 API 带到产品生命周期的末尾。为了帮助用户升级到新版本,我们在新框架中提供了与旧命令的向后兼容性。
这取决于代码重建的频率。例如,如果有 4 个应用程序使用该库,并且它们每天都在重建,那么一个月的时间足以修复已弃用的调用。
此外,如果您使用 deprecated 标记,请提供一些关于哪些代码替换 deprecated 调用的注释。
使用@deprecated标签。阅读API 弃用文档了解更多信息。
在使用该代码的每个人都告诉您他们已经清理完毕后,开始删除已弃用的代码并等待,看看是否有人抱怨 - 然后告诉他们修复自己的代码......
鉴于这是一个库,请考虑使用已弃用的功能归档一个版本。以源代码和编译形式提供此版本,作为尚未将代码现代化到新 API 的人的备用解决方案。(需要二进制形式,因为即使你可能在几年后编译旧版本也有困难。)明确表示不会支持和增强此版本。在版本控制系统中用符号标记此版本。然后继续前进。
这当然取决于您使用 API 的规模以及您预先向客户承诺的内容。
正如 Vinko Vrsalovic 所描述的,您应该输入他们必须预期放弃该功能的日期。
在生产中,如果它“只是”为了获得更清晰的代码,我倾向于在不推荐使用的日期之后将东西留在原处,只要它不会破坏任何东西。
另一方面,在开发过程中,我会立即进行,以便快速解决问题。
您可能对其他项目中弃用如何工作的示例感兴趣。例如,这里遵循Django 项目中函数弃用的策略是:
次要版本可能会弃用以前版本中的某些功能。如果 AB 版本中的某个功能被弃用,它将继续在 A.B+1 版本中工作。在 A.B+2 版本中,使用该功能将引发 PendingDeprecationWarning 但将继续工作。A.B+3 版将完全删除该功能。
太糟糕了你没有使用.Net :(
内置的Obsolete属性会生成编译器警告。