Refactoring has become code for "go back and redo everything" in software development. When is refactoring valuable? What makes it not valuable?
What is NOT refactoring?
2. Good, clean code is ready for change.
If the code is good enough to change, there’s probably no refactor needed
3. Refactoring is the practice of breaking up code or logic in preparation for change.
Refactor before you make a change to the code:
● Add tests to make concrete the logic
● Simplify or clarify the logic
● Uniform the business language
● Change the data model so it easy to modify
Refactoring after a change is made is Clean up.
Why Refactoring
4. What is not refactoring
Refactoring is not "gardening", or "grooming".
Refactoring is not cleanup
Refactor is not a rewrite
Refactoring keeps the existing process in place and keeps existing contracts.
Grooming the code for solving a more generalised problem may drive us to make
incorrect choices for the future
5. Refactoring steps
1. Add tests to make concrete the current logic, make the code testable enough
2. Run the tests: green result
3. Refactor the code
4. Rerun the tests: correct till green result
5. Repeat till code is simple “enough”
6. Ready to make logic changes
6. I can stop whenever I want!
Stop refactoring when the logical unit is "small enough".
Small enough?
To easily reuse?
To easily test?
To easily change?
To easily extend?
Refactoring steps have upper and lower limits, usually in the current logic unit. Do not "go deep".
Refactor only the immediate unit so that the change is small enough to easily test
Sometimes the "refactoring" is just adding tests or renaming to business language. Other times it is a data model change or the extraction of logic to make the problem space "smaller".
Sometimes we refactor before we "get to work", sometimes it is broken down into cycles of refactor-test-change
Cleanup: done after the change was made
Rewrites solve architectural issues or approach the problem in a completely new way