当把Rails应用升级到新版本的框架时，你会经常看到应用日志和测试套件输出中出现弃用警告。弃用警告让你有时间在问题变成彻底的错误之前解决它。好的弃用警告也会给你一个提示，告诉你在哪里以及如何解决这些问题。
Rails让你在实际的应用程序代码中添加良好的弃用警告也变得非常简单。让我们先看看如何做到这一点，然后再谈一谈什么时候这可能是一个好主意。
在你想要弃用的方法中，使用ActiveSupport::Deprecation.warn ，用一个字符串来描述被弃用的内容，以及开发人员应该如何绕过弃用的问题:
def process_widget
ActiveSupport::Deprecation.warn(
"#process_widget is deprecated. " \
"Use #send_widget_to_processor instead."
)
# other code ...
end
然后，在你的应用程序日志中（甚至更好，你的测试套件的输出），你会看到:
DEPRECATION WARNING: #process_widget is deprecated. Use
#send_widget_to_processor instead. (called from create at /path/to/
my_app/app/controllers/widgets_controller.rb:55)
弃用警告清楚地标明了你的应用程序中哪里还在使用过时的代码。如果你在测试输出中没有看到弃用，而且你对你的测试覆盖率有信心，那么就可以安全地删除过时的代码了
当你可以，你知道的，直接修复它的时候，为什么要弃用代码呢？问几个问题可以帮助做出这个决定:
- 转换到较新的代码需要多长时间？一个小时？一天？一个星期？更长时间？
- 你的团队现在可以进行切换工作吗，还是更优先的项目更紧迫？
- 你是否需要在多个团队之间沟通废弃的问题？
停止使用被弃用的代码所需的时间越长，或者需要了解它的人越多，明确的弃用警告就越有利。
就我个人而言，我喜欢弃用警告，因为它们太吵了，我不会忽略太久，而且它们与代码本身而不是像Jira或Trello这样的东西耦合在一起。不过，像任何工具一样，是否在你的代码中使用它们，取决于你和你的团队。
我希望你觉得这个小提示有帮助。谢谢你一直以来的阅读!
