What is code quality, how to improve it, and why sometimes good code is bad.
Bad code is like bad repair. It can work and even works, but it’s bad and not for long, it looks so-so and it’s not easy to fix something in it. It is chaotic, has an incomprehensible structure, and you won’t immediately understand what the author wanted to say.
Signs of poor quality code:
it is difficult to navigate in it;
parts that can be written in two lines are written in ten;
by the name of the function it is impossible to understand what it does (xyz, function, n);
if you add something to it, the rest will stop working.
What threatens a project with bad code
At first glance, bad code is not a disaster. The program works, isn't that the main thing? In fact, it brings many problems, especially in the long run. And that's why:
making changes to low-quality code takes a lot of time and is expensive, and over time, the price and duration only increase;
adding something new is also difficult;
code is unpredictable - you never know what will stop working and when;
team spirit falls if people have to work with such masterpieces ("Who wrote this at all?!").
As a result, the development speed is reduced, the timeline is lengthened, and the cost of changes is growing. If this is critical for the consumer or customer, then bad code can bury the project.
How to write good code
To write quality code, you need to know what it is. Here are its main qualities:
the code is easy to read, it has a clear structure, there is no confusion in it;
it is easily maintained: small changes do not cause a desire to write it again;
it can be expanded;
the code has been tested;
it is documented;
productive.
Comments are really very important to make the code easy to read. This will not only help other programmers when they work on your code, but also you in the future.
Here are five actions that improve the code.
1. Follow coding standards. This is one of the simplest and most important guidelines - when you agree with colleagues in advance how to format the code and how to act in some situations. Then the code written by different programmers will be visually similar: it will be easier for you to work with someone else's code, and vice versa. There are also generally accepted coding standards and even programming platforms that will tell you how to follow these standards. This is important both when working in a team and if you write code alone.
2. Refactoring. This is a reworking of the program code without changing its behavior. That is, first you have a creative process: you write so that the program works, and then you “clean up after yourself”, put the code in order, to the desired look. As a bonus, refactoring helps to rethink the architectural decisions of the program.
3. Typing. Let's explain with a real example. Players wrote to the developers of one game about problems, and then suddenly stopped. At first, the developers were delighted: everything is so cool that there are no problems. Later it turned out that the username had changed to a nickname in the game, and because of this, the feedback form stopped working: complaints were simply not sent. Typing (declaring a data type) will help avoid such errors and simplify maintenance and refactoring.
4. Code review. This is when you and a colleague check each other's code and give each other feedback. This practice helps to avoid stupid mistakes and thoughtlessness. In addition (and this is also important), you are aware of what the other person is doing, and you do not have to duplicate functions. A wonderful bonus - this method will help to gently adapt beginners.
5. Automatic tests we will talk about them in a little more detail. These are simple programs that run code with different parameters and check against already known results. What are the tests?
Unit test individual parts of the program.
e2e test the system as a whole.
Loaders check how well the program handles loads.
Screenshots compare before and after screenshots and react to changes.
Others: mutational, penetration…
With tests, you really need to be careful so that it doesn’t turn out that you spend hours looking for an error in the code, but the problem is in the tests themselves. Therefore, it is useful to write tests first, and then take on the code itself, when you have a clear structure and understanding in your head of what needs to be done and what you want to get.
There are other ways to improve the code (for example, pair programming). The best results can be obtained if you use several methods at once: this is more reliable.
When good code is bad
We've been talking so much about how important quality code is now, and now we're saying the opposite? Yes. Sometimes good, "correct" code isn't all that great.
The reason is very simple: in programming, unfortunately, you have to choose between quality and speed of work, and in some cases speed is more important.
To understand how important speed is, imagine two developers: John and Steve. One is thorough, pedantic, and the second is its complete opposite. Both came up with the idea to make some kind of product. John sat down, came up with the architecture and started to do it well and slowly. And has been doing it for six months now. Steve did everything in a month, with errors, bugs - but immediately launched it, found customers, made the second release... As a result, six months later, when John had just completed his wonderful product, Steve already has many users and the name of the product is already well known. And he fixed some of the bugs in the second release.
Moral of the story: sometimes it's more important to get to the market faster and occupy a niche than to do it perfectly.
How then to be? Bad code is bad, good code is not always good either ... The point is this:
Code quality is a parameter that
we change depending on the goal.
If you are writing an application for a bank, then you will spend a lot of time testing and developing, because a mistake can cost hundreds of thousands of dollars.
If you are making a landing page that simply tells about a temporary promotion and collects emails into a database, then speed is already important here. You know that once the promotion ends, your code will no longer be needed. There is no need to refine and maintain it, and other developers will not use it either - it is enough to write quickly and check that it works, the rest is not important.
These are the basic principles of creating quality code: do not forget about standards, look back at what you have already written, do not be afraid of feedback from colleagues and do not forget to test. But at the very beginning, it is worth weighing: quality is important to you now, or you need to finish development as soon as possible.
Top comments (0)