As covered in my post, iterate towards better code reviews, the shared vocabulary is essential. When it comes to the object-oriented design and code quality, the word refactoring is one of the most valuable words of the vocabulary. The team should first come to common understanding of it. You may have a question why this has such high value in object oriented programming activities.
When we come to accept the definition of the refactoring, then we:
- Accept software entropy
- Recognize the bad code
- Develop necessary fluency to communicate bad code
- Make the code changes in safe steps
- Accept the need for tests to create safety net
- Recognize the need for the quality of the tests
- Write the tests before making the code changes if there is no safety net
- Verify the quality of safety net before making the code changes
- Take time in naming things to improve readability
- Take this as a disciplined effort and avoid the ad-hoc code changes
- Let the stories to scope the refactoring
- Refactor towards or away from the patterns letting the stories to pull the good enough design. Patterns may not be obvious in incremental development
When a team does the refactoring as intended, it can pull:
- Habit of recognizing the bad code
- Good estimates allocating enough time for the refactorings and eliminating the need for taking shortcuts
- Incremental design
- Quality tests and the shorter feedback loops they create
- Team can test and improve the vocabulary
- Quality software with few defects
- High satisfaction of delivering quality software
- Respect from the Stakeholders
It is not unusual if you ever noticed people using the word refactoring to describe different things. It is so common, Martin Fowler calls it RefactoringMalapropism.
Here is a screencast(~ 10 minutes) I created to show how to do refactoring in safe steps by running the tests on each step.
Without the link to the book that popularized this useful and important technique, this post would be incomplete. Martin Fowler’s book Refactoring: Improving the Design of Existing Code covers refactoring and presents a catalog of refactorings. It is worthy of the programmer’s time.
Here is the fun part:
you can offer a candy for every defect found in your programming effort as you will not be spending much.
Since your code quality is so high with the disciplined refactoring effort, you can offer a candy for the defects from your programming effort as you will not be spending much. You can feel proud whenever you see the full bag. As you earned the right, you may brag about it if you like :).
Happy programming!
Attribution: Thanks to State Library Victoria Collections for the horses pulling wool picture.