Notes on Refactoring

When you refactor, consider these points:

• is the code you're touching part of the core logic of the component
  • e.g. your App is a todolist, so the core logic is the todo handler (edit update delete functions)
  • e.g. your backend handles queries from the frontend, transforming data, building SQL and formatting return data, so the core logic is the code that encompasses that logic (which might be a large, single file)

If they are touching core logic, any change that is less than "very confident you will not change other logic" should be flagged, and if a refactor is needed in order to make the logic more understandable, ask for resource allocation to do the refactoring before you start on the feature.

If you are asked to deliver a feature

• and it involves touching the core logic of the app you're working on
• and the core logic is extremely convoluted (too complicated / very brittle)

Give management a choice:

• allow for a refactor ticket before the feature is Implemented
• let management know that if we still go through with the feature, we cannot guarantee that other behaviour will not be affected by the feature

This ensures that management understands the risk they are taking, whichever route they decide to take.

This also shares the responsibility in case of bugs that crop up due to the change.