debian-mirror-gitlab/doc/development/renaming_features.md

31 lines
1.4 KiB
Markdown
Raw Normal View History

2021-01-29 00:20:46 +05:30
---
stage: none
group: unassigned
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2021-01-29 00:20:46 +05:30
---
2020-03-13 15:44:24 +05:30
# Renaming features
Sometimes the business asks to change the name of a feature. Broadly speaking, there are 2 approaches to that task. They basically trade between immediate effort and future complexity/bug risk:
2021-02-22 17:27:13 +05:30
- Complete, rename everything in the repository.
2020-03-13 15:44:24 +05:30
- Pros: does not increase code complexity.
- Cons: more work to execute, and higher risk of immediate bugs.
- Façade, rename as little as possible; only the user-facing content like interfaces,
2021-09-30 23:02:18 +05:30
documentation, error messages, and so on.
2020-03-13 15:44:24 +05:30
- Pros: less work to execute.
- Cons: increases code complexity, creating higher risk of future bugs.
## When to choose the façade approach
The more of the following that are true, the more likely you should choose the façade approach:
- You are not confident the new name is permanent.
- The feature is susceptible to bugs (large, complex, needing refactor, etc).
2021-02-22 17:27:13 +05:30
- The renaming is difficult to review (feature spans many lines, files, or repositories).
- The renaming is disruptive in some way (database table renaming).
2020-03-13 15:44:24 +05:30
## Consider a façade-first approach
2021-02-22 17:27:13 +05:30
The façade approach is not necessarily a final step. It can (and possibly *should*) be treated as the first step, where later iterations accomplish the complete rename.