我负责管理一个 Rails 应用程序，该应用程序即将重命名一些面向用户的关键部分（例如 url，以及其他此类更改，例如将“博客”重命名为“期刊”等），
我有点担心随着时间的推移，有大量代码库中所有方法、路由和类名的旧名称将难以阅读和维护。
应对此类变化的最佳方法是什么？
当对方法和类名使用别名或在此处运行迁移时，问题在哪里？
谢谢
I look after an Rails app, that's about to have some key user facing parts renamed (like urls, and other such change like renaming 'blogs' to 'journals' and so on)
I'm slightly worried that over time, having loads of older names in the codebase for all the methods, routes and classnames is going to be difficult to read and maintain.
What's the best way to deal with changes like this?
And where are the gotchas like to be when aliasing methods and classnames, or running migrations here?
Thanks
发布评论
评论（2）
如果应用程序正在开发并且尚未投入生产，您可以安全地返回并重命名迁移/模型/视图等...并执行
rake db:migrate:reset并就这样吧。您应该进行足够的测试以确保重命名不会破坏任何内容，如果破坏了，您应该增加该区域的测试覆盖范围。就目前正在生产的应用程序执行此操作而言，我建议逐步执行此操作，以便减少更改的表面积：
更改路线
这可能是最大的更改。首先更新您的路线将使您有机会修复所有视图。
更新您的模型/控制器
您可以在不更改数据库的情况下执行此操作。您可以使用
set_table_name "OldTable"使模型指向新的数据库表。这意味着您可以在发行版之外进行任何数据库更改。更改数据库
希望您正在使用迁移，在这种情况下，只需重命名表并删除 set_table_name。
If the app is development and hasn't yet gone into production you're safe to just go back and rename the migrations/models/views etc... and do a
rake db:migrate:resetand be done with it. You should have enough tests to ensure that the rename didn't break anything, and if it does you should increase your test coverage in that area.In so far as doing this for an app that is currently in production I suggest doing it incrementally so that the surface area for the change is reduced:
Change your routes
This is probably the biggest change. Updating your routes first will give you a chance to fix all of your views.
Update your models/controllers
You can do this without changing the database. You can make your model point to a new database table by using
set_table_name "OldTable". This means you can make any database changes out of band of the release.Change the database
Hopefully you're using a migration, in which case just do a table rename and remove the set_table_name.
我会重命名内部类以匹配外部名称，否则在谈论代码时只会引起混乱。当然，路由可以使外部更改轻松切换，但是没有什么比在代码中读取您在网页上看到的内容更好的了。
重命名后，我将使用实时数据将应用程序加载到临时环境中以测试迁移，然后运行类似 tarantula 的东西（ http://github.com/relevance/tarantula ）来抓取您的应用程序，查找您发现的明显损坏的问题。你的测试可能错过了。
I would rename the internal classes to match the external names, otherwise it just causes confusion when talking about the code. Sure, routing can make the external changes easy to switch, but there's nothing like reading in the code what you see on the webpage.
After the rename, I'd load the app up in a staging environment with the live data to test the migration, and then run something like tarantula ( http://github.com/relevance/tarantula ) to crawl your app looking for obvious broken issues that you & your tests may have missed.