What’s wrong with our code quality? I’ve recently came across a talk given by “Uncle Bob” Martin on the object-oriented programming. What struck me most, however, was not how precisely and thoroughly he grasped the very core of OOP, but the introduction he gave. We, as programmers, tend to sacrifice the code quality in order to write it faster, which, in turn, causes a decline the the programming speed. This, in consequence, leads to the inevitable decline of programming speed, which, in turn requires more sacrifices. In the long run, we could say that the following theorem is true: “The faster we want to write code, the more slowly we actually write it.”
From what I observe, this issue is particularly true when it comes to startups. I do understand that it’s crucial to cut down the time to market, and it might require some tradeoffs in order to let the project start making any money at all. After all, if the enterprise goes bankrupt, the most perfect code is of no use. On the other hand, when the situation stabilizes, it is the time to rethink certain solutions and clean up.
Why Code Quality is Important?
So, what is the problem with the code quality? Can’t we just rely on a framework to do some work for us? Can’t we skip the process of writing unit tests and rely only on manual tests?
Let me put it that way: I’ve been there and it was the most unpleasant experience EVER. Code written by a bunch of mid developers, without more than 2 years of experience in a rush with a client, who wasn’t technical and didn’t want to pay for the automated tests. I was responsible for upgrading one of the parts of the project. You know how I checked whether it worked? I started the server. Nothing more. Trying out every possible combination of workflows (which I didn’t know about, since I was new to the project as those devs were already gone) was well beyond any reasonable time I could spend on this task. As you can imagine, actually trying out the system brought one regression after another. When I renamed a field in the API it exposed, imports from external source stopped working. And such connection were countless.
OK, But How Does Testing Influence the Code Quality?
First of all, tests save you from known issues. No real refactoring can take place without proper tests. If I do not know how a system works, any change I introduce imposes a great risk of breaking something unintendedly.
Moreover, when TDD approach is used, it’s hard to write code that is not testable. If the code was initially written without any care for the quality, it might be hard in the future to cover all critical parts with tests.
How Can I Improve Code Quality In My Projects?
There are a few tips and places where to start.
First, try to understand what makes up for a good code quality. The “Clean Code” by Uncle Bob is an absolute must read. I’m not going to rewrite all the important points he makes, but the bullet points for me are:
- take care of the formatting and stick to one style,
- use meaningful names,
- keep you functions and classes small,
- do not repeat yourself,
- extract error handling to make it a single operation,
- follow SOLID principles.
Once you’ve done this, you can start rewriting the project using suggestions from top to bottom.
Even if you have a really poor project, you can use a single tool to reformat it entirely with a single click. Once you’ve done this, you can start changing all the cryptic names you have to something meaningful. This way you’re going to start understanding what is going on. Having done this, you can start breaking your giant methods into smaller ones. As a consequence, you’ll be able to identify repetitions you can get rid of. This will leave you with an easier way to handle errors. Last, but not least, you can start identifying more abstract problems violating the SOLID principles.
I hope I’ve caught your attention and that you’re going to be one of those developers, who at least try not to punish other people with their work 😉