The topic of refactoring code was brought up during our development team meetings concerning coding standards. In this post I will summarize the point I made in that meeting here using a quick example.
Sally has just accepted a new sprint story to make an enhancement to an existing system and she is trying to determine what level of standards she should apply to the code she is working on.
There is no easy answer to this. However, remember the over arching goal is to promote stewardship and have code that can be easily maintained.
Sally decides that for this enhancement it is not worth refactoring all of the object names, due to the amount of testing required and since the product uses a naming pattern different than the current standard. She will continue to use a pattern consistent within the project.
However, she decides that she will bring the contents of the stored procedures she is touching up to the standards by:
- Adding schema references
- Adding try catch
- Removing “Select *” and various other minor tweaks.
However, she is not sure the best way to approach this.
The Double Check In
Consider the following:
Sally makes all of her standards updates while she is adding her enhancement and then checks it in with a comment such as “Issue # – Added X Feature so X could do X”
Now she sends Kevin a request to review her code. While Kevin will surely be impressed with the nice easily readable code he will have no idea what the actual feature changes are and it will be difficult to review.
This is where the double check-in comes into play.
Instead of doing the above Sally instead makes the changes in two steps:
First, she refactors the procedure to bring it up to the standards that she identified as making sense to make at this time and she checks it in with “Issue # – refactored code to standards.”
Then she goes back and makes the coding enhancements and checks those changes in separately with a comment such as “Issue # Added X Feature so X could do X”.
Now when she asks Kevin to review her code he can easily see the code changes made for the feature addition, as well as the changes made to bring it closer in line with the team standards.
In conclusion, the double check in practice can really help out your team and speed up code reviews and understanding within source control history.
Are there any tips or tricks you use for handling refactoring for code reviews?
Let us know in the comments below.