-
Notifications
You must be signed in to change notification settings - Fork 15
Refactoring
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.
- 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.
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.
- Ongoing: keep dependencies up to date
- Abstracted API hooks -> all-in-one hook
- Github Actions: check for any depreciated actions or commands and create an issue to upgrade