Refactoring Guidelines

There are often times where a refactor is necessary or desired, but we should follow some guidelines in doing so to help prevent merge conflicts and more rework. We refactor code to make it easier to work with over time, or to increase performance. Refactoring is best done as you work on the application to help prevent stacking up tech debt, but we need to be careful with how we do this to prevent re-work, merge conflicts, and stepping on toes.

Do

• Refactor a component you're working in currently if you find a better way of writing the existing code
• Refactor a component you are scoped to work in to make it easier to extend with the additional code or features you may be adding
• Write tests before refactoring to cover any cases you may notice that existing tests may miss
• Ask about an approach if you are unsure if something is a good idea
• Fix bugs, misspellings, poor naming while in the component you are working in or very closely to
• Take note of components that need refactoring and bring them to the lead's attention if you are not currently scoped to work on that component.
• refactor code to make it easier to read
• Ask for advice or opinions if you are unsure

Do not

• Refactor unrelated files from your scope of work
• Write hacky code to avoid refactoring
• Ignore code that needs refactoring (this is how you build tech debt)
• Refactor to add things that we may need later
• Add features that are not part of the scope of work
• Worry too much about refactoring
• Refactor for performance unless a performance issue is discovered
• Refactor in the middle of a PR review. If someone has reviewed your code, don't make them re-review things unless it's a necessary change. Make a new PR instead.