Code Smells is something I picked up from an Agile group. I don’t know if the concept was formalized as a term in the Agile SDLC or not; I guess it really doesn’t matter where it came from. The concept works effectively in both Agile and Waterfall SDLCs.
If you’re like me, you never write code where you are completely satisfied. There is always some tweaking or new technique you have learned that will make your code better in some way. Maybe it is more understandable, performs better, using new techniques or more accurate.
The problem is that you often don’t have time to deal with it when it occurs. The code remains in the code tree. That is a “Code Smell”. Some are worse than others and should be addressed soon. Others are more ambiguous and may never be addressed.
Having a list of Code Smells is extremely valuable. They should always be addressed whenever you begin planning for a new sometime (depending on your SDLC). For a Scrum Agile SDLC you would address the highest priority Code Smells as you are planning a release or a sprint. That doesn’t mean you will do them in the release or sprint…but it keeps things that you said, “we’ll come back and fix that later”, from falling through the cracks.
Another time you can take advantage of a list of code smells is on those rare occurrences when you have completed all the available work and need something to do. No more glazed looks while trying to find something you remember seeing and not liking. It is readily available for your use, and the value of making the change is well known.
Have you been practicing the technique of Code Smells? How has it benefited you and your employers? Share your experience here online, or drop an email to btaylor@sswug.org.
Cheers,
Ben