What is code quality?
There are a lot of definitions of code quality out there, but I will try to summarize what I understand when someone is talking about code quality.
Readability
One of the aspects of code quality is readability. It is very important that code is readable and comprehensive, not only by your teammates, but also by yourself. Sometimes it isn’t that easy to understand a piece of code that you’ve written yourself some time ago, imagine how it would be like for someone else.
Code should be as readable as possible, so that anyone that comes in contact with it is aware of what it does. This way it is easier to maintain the code, which brings us to the next aspect of code quality: Maintainability
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Martin Fowler
Maintainability
As applications grow, so does the codebase behind these applications. Sometimes this can cause that making changes to these applications becomes very hard without breaking existing functionalities. To prevent this, efforts should be made to make code as maintainable as possible. This can be done by focusing on the readability of the code, adding enough tests or writing the application in a way that it is extensible.
Testability
An important aspect of developing applications is testing. Whether you are working test-driven or not, there should always be tests! Not only does this help you a lot during development, it also boosts the confidence of whoever will be making changes to the applications in the future. Running the tests after a change will ensure that all the existing functionalities are still working. Note that tests are part of the codebase, and code quality in the tests is as important as code quality in the actual implementations.
Code reviews to the rescue
One of the most important steps to maintain this code quality, is doing code reviews. During a code review, someone else reviews the codechanges that were done and checks it for readability, possible bugs, good practices, if the tests are covering the changes enough, …
Another great aspect of code reviews, besides maintaining the code quality, is learning from each other. If a code reviewer reviews code, it’s very well possible that he or she gains new insights or learns new ways of developing. This works in both ways, when a code reviewer notices something that he would have done differently he can provide the author of the code feedback. In this way, the author also learns from the reviewer.
How to make code reviews fun?
Me, 2 of my fellow ToThePoint colleagues and the rest of our team at Liantis invented a way to make code reviews more fun. We introduced the ‘Battleship’ game.
Every member of the team starts by positioning his ships on his battleship grid. Whenever a code reviewer finds something odd during the review which is:
- Breaking one of the good practices
- Missing tests
- Unused imports
- Something else that is to be found extremely stupid by the reviewer and the majority of the rest of the team
every member of the team gets to shoot ‘a missile’ to the Battleship grid of the author.
Since nobody really likes to lose, this has the great effect that every member of the team is now way more careful with what he or she checks in before the code review. It creates way more awareness during developing to focus on the code quality.
Of course, good code reviews are very importing in the aspect of code quality. So how the keep the code reviewer sharp during the code reviews? Well… If, apart from during a code review, someone finds something odd in the code that breaks our code quality standards, we will backtrack who wrote the code – but also who did the review. In this case, not only the author but also the code reviewer will have to receive a missile shot from every other member of the team.
Whenever someone loses the game, he or she will have to treat every other team member – often with some kind of energy drink.
Conclusion
We are doing this now for almost half a year, and we noticed that introducing battleship had a very good impact on our code quality. The amount of missiles we are launching on each other (in the battleship game of course…) is very low nowadays. Everyone is investing more time in maintaining the code quality – which results in applications that are very maintainable.
Last but not least, we just love this. It’s very fun, and it creates a great team-atmosphere.
