The term Code Smells is not my invention. It has been around for a while. Code Smells are those areas of code that work. They meet the application requirements. But, they aren’t well formed, and benefit from refactoring.
A good example of a code smell is when you see duplication of code. At that point, you know there is a better implementation. But, it works! So why change it? The main reason to change it is that later on someone will come into the application and make a modification in one place, thinking they have made all the necessary changes. Since the behavior is in more than one place, the change made will not be complete, and may be difficult to track.
Why do we call them code smells, why not just fix it right away? Remember, or primary goal is to ship working software. All the “Abilities” we build into our software make it a better product. So, when those times come when you don’t have time now to refactor, mark it up as a Code Smell. Track the location where the problem exists, and place it into a Code Smell backlog.
Some places just keep Code Smells on a board or in a task that is not part of the current project schedule or sprint. When release tasks are caught up, rather than coming up with new features, or picking up future work, a developer can go back to the Code Smells list, and resolve an issue that was important, but not critical at the time it was found.
Try the Code Smells idea for a while and see how it works for you.
Cheers,
Ben