Skip to content

Latest commit

 

History

History
30 lines (22 loc) · 1.44 KB

renaming_features.md

File metadata and controls

30 lines (22 loc) · 1.44 KB
Raw
stage group info
none
unassigned
To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments

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:

  • Complete, rename everything in the repo.
    • 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, documentation, error messages, etc.
    • 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).
  • The renaming will be difficult to review (feature spans many lines, files, or repositories).
  • The renaming will be disruptive in some way (database table renaming).

Consider a façade-first approach

The façade approach is not necessarily a final step. It can (and possibly should) be treated as the first step, where later iterations will accomplish the complete rename.