Maintaining Code Quality

With the first post, I want to approach such an important and complex topic as code quality.

A year ago I already wrote a blog post where I tried to define what is it and how to define it for your team: https://blog.spryker.com/how-to-maintain-superior-code-quality. But let’s try to recap what does it mean in simple statements:

• it’s about reducing complexity
• code changes lead to predictable results
• a code base is well documented with up to date content
• the good quality code does not slow you down in the long run with system expansion

When a project just starting code quality usually is not set as an additional requirement. You make things done. And as more you give up on this non-functional requirement as more responsibility you take on to maintain it in the future.

Even you started with a solid basis you will see how with following development iterations a codebase tends to become obsolete, concepts become rotten. Legacy grows like mushrooms after rain.

How to solve this problem when everything is against?

First of all, without conscious enhancements and infinite process tuning chaos nature will take over. With this, we come to the individuals’ responsibility and company IT culture. Changes are painful and require strong IT leadership on the establishment of new IT processes and integrating of best agile practices. IT leadership is especially important for companies which undergo the digital transformation, where the business model is under heavy changes. Are you are one of them?

At the second, start to measure code quality. Without understanding where you are it’s impossible to define where you go. In Spryker projects, we highly recommend starting to measure code quality from day 1. Even it’s bad, not acceptable, but at least transparent for everyone. Use clear numbers, avoid long architecture evaluation reports. There are plenty of free tools available PhpStan, PhpMd, Scrutinizer.

Besides continuous enhancements of the Spryker OS (read more about the last big kernel change at https://documentation.spryker.com/silex_replacement/silex-replacement-201903.htm), we run periodical code evaluations and health checks. One of these evals I will share in the following posts.

To summarize, I want to list the most important points:

• measure your code quality
• set development rules via conventions and code styles
• stop writing bad code: once identified an issue stop producing it
• establish a solid IT culture and individual responsibility. One of the Scouting rules I apply in daily dev process: Leave this world a little better than you found it.
• plan cleanups and refactoring, by including them in the ongoing development