Refactoring

Software rarely stays unchanged for a long time. New features and improvements are implemented. Old features are removed. Optimizations are done. Sooner or later even simplest or most elegant solutions become too complex. This increases costs, complexity, risk to introduce bugs. It’s time to refactor and get back on track.

Tips

• When changing code for that functionality never change/remove functionality itself without consulting with Product Owner. Functionality should be at least the same as it was before.

Small Refactorings

We often do a lot of small refactorings. Such refactorings are part of the new functionality. Developers are encouraged to do small isolated improvements whenever it is necessary. Small refactorings usually don’t influence entire code base, it doesn’t take a lot of time, so there is no need for the sophisticated process.

Large Refactorings

Sometimes system needs to change significantly. For example, business logic has changed significantly so some of the entities are no longer necessary. Large refactoring is required if those entities are tightly coupled with other parts of the system. Such refactoring is not included in User Stories and is scheduled as a dedicated refactoring task.

Tips and rules for doing large code refactorings:

• Investigate changes that need to be done and identify and isolate small independent parts that can be refactored separately.
• Refactor identified smaller parts first.
• Only when code refactoring task can no longer be divided into smaller stories a single code refactoring should be performed.
• At any given time there should be no more than one active large code refactoring being performed.
• Merge with upstream as often as you can during large code refactoring.

Refactoring Stories

Refactoring stories should be labeled with a custom tag. Example: [Refactoring] Move current_date from phases to protocol