We all write code, even in a relatively short project, for quite a long time. It isn’t just the first few days/weeks (sometimes months…) of the main writing period, but rather also the additions down the road, the fixes, and the patches. This means that the code gets “dirty” with time, no matter how “clean and tidy” it started as.
Our code needs to be maintain even when well written – we have those quick and dirty patches, the lines that no one knows who, when and why are they there, parts of the code that are no longer relevant because of other changes made, parts that could be written better now in view of changes in other sections of the code, and / or in light of advances in technology.
So many things causes the code to get messy. It might be as simple as the fact that different developers write the code. We all know that a ‘clean code’ is important. It usually simply means that it can be read by another person, and they will easily understand it.
Programming is the art of telling another human what one wants the computer to do. Donald Knuth
But it doesn’t end here. ‘Cleaning’ the code can end up with many benefits:
- A more accurate code, shorter and with less failing points
- Performance improvement
- An easier to maintain software
- Decrease in the number of defects (which results in better use of the testers time and efficiency)
- Found defects are easier to fix
- It’s an opportunity to handle all the comments that you previously left in the code for future care (remember those?)
- You can also add in-code explanations (and new updated comments), for better understanding of what was done and why
- Simplify algorithms that were previously written in a wrong way
There are tools that can help find code defects, unused code lines. We use them whenever the time comes for some code cleaning, which we just did as can be probably visible mainly on the desktop client.
Most projects today are a mix of your own code and many external libraries. The process of code-cleaning is an opportunity to check whether these libraries have a newer stable version, and upgrade to this version. The upgrade process can be risky, but the benefits are more important because you’ll find yourself using libraries with less defects, and is more current and maintained.
You can also take advantage of this code-cleaning opportunity to initiate a process of code-refactoring. this means restructuring the code in a more efficient way, and actually cleaning the original design, at least the parts that were defective or that time and code changes made them such.
But it doesn’t end here. The same approach can be applied to software testing. You tests need to be reviewed on a timely basis and ‘cleaned’:
- Unused tests
- Outdated tests
- Tests that consistently show passed status and so, perhaps no need for them any longer
- Tests with too short run-time might reflect ineffective planning
- Tests with too long run-time might be ineffective because testers will lose concentration, and track of their work
- Tests with actual run-time that does not match the estimated-run-time set for them, might impair effective test planning
- Tests with open comments call for action
You should also consider using metrics to help with estimating the quality of your tests, and improve it. Take any of the above examples, and set the numbers you wish to get to, or percentage you want to improve as a goal. Set your realistic and project-oriented metrics to improve the testing project.