Code quality is a term that is often thrown around in the software engineering industry. And like the art of coding itself, it is very subjective and its true meaning will differ depending on an individual, or a team’s beliefs. But at its heart most engineers and teams would agree that good quality code is easy to read, well tested, and maintainable in the long term. But how do we achieve this?
Most software systems will suffer from a deterioration of quality over time. Codebases become bloated, software is changed to solve problems nobody knew existed when it was initially written, and the cost of change keeps increasing.
A solution problem is an emergent property of a solution. Experienced Software Engineers avoid creating solution-problems, they create simple solutions for the root problem.
Developers should be allowed to deploy at any time. Many find this a scary prospect since it makes traditional release management and QA very hard. We have found that empowering developers to own the responsibility of deployment allows you to ship software much faster whilst maintaining or even improving the safety of releasing changes when compared to more traditional processes.
As developers we always appreciate a second pair of eyes and an extra brain. The eyes are really helpful for catching that extra whitespace you might have missed. The additional brain power might help you solve a problem in your code with 5 fewer lines. All of this results in better code and more collaboration.
We’ve helped a number of organisations successfully adopt pair programming, giving their teams the ability to increase productivity, improve knowledge sharing and enhance the quality of their software.
“Pair Programming” is two developers focussing on one task and taking turns to “drive” the development. Normally this means sitting down together and passing a keyboard back and forth in ten or fifteen minute intervals, but can also mean screen-sharing remotely.
Design patterns are solutions to software design problems that are presented in an almost conceptual way. That is to say, a given design pattern has the potential to be applied to a piece of software written in any number of languages but, at a code level, it’s up to the developer to interpret that idea and make it work for them.
Keeping your code simple and easy to change is one of the hardest challenges when writing programs. One obvious aspect of this is the amount of code that you have to parse to understand what it aims to achieve.
Software anti-patterns are a well covered topic, but I thought I would highlight some of the ones I’ve encountered most frequently. These may seem obvious and at times innocent looking but make no mistake, they are sinister and will sabotage your efforts to add features to a codebase. I’ve gone ahead and made up my own names for some of the more specific anti-patterns.