Refactoring code

Refactoring code is an important part of the lifecycle of software. As we add features, or learn new techniques it often makes sense to make significant code changes to support improved maintainability in future.

However, refactoring can often be a contentious area, and not everyone might agree on the best approach. It can also take time away from developing features, or making bug fixes.

Refactors needs to be weighed up against these factors and planned in as part of the sprint planning work.

Refactor Process

• Discuss with a teammate first to make sure that more than one person sees the value of the change
• Raise a new Github Issue For Refactor (using the refactor issue template)

In some cases, where a small refactor is needed and is directly related to the task, the team might agree that a separate issue isn't needed

• Discuss the issue with the wider team, if it's a small enough issue the team might agree to take it on as part of the current sprint. If not the issue can be left to be considered as part of the triage and sprint planning process.
• If there isn't consensus with the team on the best approach for a refactor, the options might be considered in a KDD style process.

Long Term Refactoring

Some refactors involve updating code in a lot of different places. These kinds of refactors can sometimes be done, piece by piece. E.g. Switching out an old table component for a new more powerful one. In this case it often makes sense to set a pattern on how to do the refactor, then plan in small chunks on how to refactor as we go.