Вопрос

In a product we are rebranding a feature. For example, we have tweets and we are rebranding it to news. On the code side we have tables and structures like tweet, user_tweets, favourite_tweets and so on.

Does simple rebranding justify renames and migrations in code and Data base (structure names, file names, fields, table names)?

Это было полезно?

Решение

To my experience, it is good to be prepared that names in your code need to be changed afterwards, for lots of possible reasons, feature rebranding is just one of many reasons why this may occur. Therefore it is always a good idea to take some measures beforehand to make renamings in your code as simple as possible.

Refactoring tools will help. Statically typed languages with a compiler which warns you when you make an error in renaming will help. Writing DRY code will help (so there are not more places in your code to be modified than necessary). Integration test suits will help to validate you did not make an accidental error, for all cases the compiler cannot catch. Having testers and a good QA process will help you for all cases which your automatic integration tests won't catch. Using unique, searchable names throughout your code will help. Having a strategy and/or tools for introducing changes into your database schema afterwards will help. Having a tested strategy for being "backwards compatible" with any kind of persistent data will help. Having a fully automated build and deployment process will help.

At the end, this is a tradeoff, and there is no "one-size-fits-all" rule here. You have to consider how much effort a specific name change will cause in your case (do not forget the testing and deployment efforts), and compare that to how much benefit you expect to get from the renaming in your case. If the majority of the groundwork detailed above is in place, the effort for changing the names may be small enough to justify it.

Лицензировано под: CC-BY-SA с атрибуция
scroll top