Code quality is at the heart of informatics development, as it tells if you’re going to handle your next task with ease or not. Indeed, maintaining a code base is mostly about quality and flexibility. The cleaner you code, the easier it will be to make changes afterwards.
Quality measurement comes in various flavors, with different meanings associated to them. Coding standards, decoupling, commenting and testing are some of these and are easy to measure with standard tools. Even if there is probably no way to achieve perfect quality in a real-world case, we can always improve the way we work and find new ways to get better.
I used to work in teams of multiple developers, each one coming with his own experience and habits, some being experienced, some others just newcomers to web development. While the last ones are more probe to errors than the others, we all do mistakes and it often occurs at the end of the project that some parts of the application were just not properly designed. Having acknowledged that, we started to do global code reviews at the end of each project, in order to have a global idea of the work done and check that the code was basically clean and efficient, so we could guarantee a minimum quality.
This was the first step that we took to improve code quality. Still something was missing in my own opinion, something letting us stop code mistakes before they would get into the code repository. Wouldn’t it be great if we could avoid commits like “Fixing code style according to recommendations” or “Improving the SQL queries that were too slow” ? Well that’s possible, and that’s exactly what is done in big open source community projects, as some people guarantee the quality of the code of all the contributors, by just reviewing before it gets in the core.
Applying this to your own project comes with many advantages and it is in the end quite easy to set up. If you work with git as your VCS, on a platform like Github or Gitlab, every developer should just create his own branch each time he starts a development, and push this branch to the main repository. Once the feature is completed, he should just open a merge request of his branch over the master branch. Afterwards, some other guy in the team will be able to review the code produced and validate it, so that the merge can happen. If there are mistakes identified, the merge request can be annotated with comments line by line, so that a discussion can happen and a fix can be developed if needed. The same process can apply to subversion users but as I haven’t heard of good tools to follow it strictly, it can be a bit crafty to do : sharing a diff file of the modifications through a platform like Review Board is the way we are doing it.
This process has proven its efficiency for me. After a few weeks of these reviews, the most common mistakes almost disappeared, and we went from around ten comments for each merge request to no more than one or two. Indeed, having your code being reviewed before you can even push it to the main branch forces you to modify it while it’s not good enough, so the advices get in your head more easily. This benefits to everybody, as everybody should get his code reviewed. Beginners will obviously learn from their elders, but seniors will also get a feedback from somebody with an other point of view. In either cases, the discussion that will follow up will make both people better in some way.
Of course, some people may be reluctant about this kind of process. Managers will wonder if the time spent for these review is worth it. The answer to this concern is easy, because as the team learns how to write better code, the bug fixing part and technical debt will lower dramatically eventually, and so will the cost of your next project.