What is good code?
Posted on January 18, 2019
– Defining a common language for discussing code quality
I recently started a new task as Tech Lead for a company that wanted to improve the quality of the code produced by their inhouse team. That immediately posed the question: What is good quality? The question is hard to answer without having a common language for discussing good and bad code. All developers are good at writing if statements, compiling their code and generally transforming the business requirements into software. But taking the helicopter view is definitely not a common task for developers.
So how do I approach such a task? The first thing I did was to spend a few days looking at the code. Even though the codebase is several thousand lines of code, I can get an overview within a fairly short time period. I looked for common anti patterns, e.g. having database specific items spread around the code, having no obvious component responsibility etc. These things point to architectural problems and they are usually the result of having a product with many technical drivers over time. Each time responsibility change, a new direction is decided, but we rarely have the time to clean up the existing code base.
With the overview of the code in mind, the next task is to create a common understanding of the anti-patterns and how to avoid creating new anti-patterns while cleaning the existing anti-patterns. One way of approaching this is to shout out loud that the code is crap. But that will rarely do much on team spirit and it will probably not make the developers take ownership of fixing the problems.
I choose a different approach: First of all, we need to define a common language for what good code is. To do that, I arranged a reading group. I placed a copy of Robert C. Martins fantastic book “Clean Code” on the table of each developer and assigned homework. 3 chapters each week and then a meeting where we go through the major points in the chapters. The responsibility for leading the walkthrough is shifting between developers each week.
The book starts out on a quite basic level. How to name things, how to structure code etc. As mentioned before, everybody knows how to write an if statement, but it is surprising how few developers consider naming things. To give an example:
If (numberOfItems > 10 && customerLevel == “Silver” || customerLevel == “Gold”)
{...}
Is very different than
If (CanCustomerGetDiscount())
{...}
It is basic, yes, but changing the naming and extracting the if clause is immediately making the code easier to read and code that is easy to read is easy to maintain (or at least a bit more easy).
The book graduately get more and more advanced and touches areas as class design and unit testing.
The idea is that we can create a common language and that the team itself is capable of defining what good code is. Even more important, spot bad code. They need to drive the improvement of quality by themselves, making me obsolete. I will assist them in the journey, advice on implementation strategies, feature design etc., but I cannot improve a huge code base alone.