Long-time code (code that was written a long time ago)
There is such a native Russian word - legacy. And this word is translated quite beautifully, it is translated as heritage. I have often seen in job descriptions that we have “legacy”. And I thought that this was an advantage of the company, that they had a heritage, ancient traditions of writing code that developers honor to this day.
In practice it turned out that this is completely untrue. And in the literature, in addition to legacy, another concept is used, which corresponds to the fact that this is a code that was written a long time ago - a long time ago. And now we have to work with this old code. Here you need to understand that any edit can lead to system failure. Therefore, until we understand how this code works, we don’t correct it, but continue to write in the same “old style.”
Indignation
Once upon a time, a story happened to a very good friend of mine, almost a relative. He somehow looks at the code and begins to be indignant and indignant about the low quality of the written code. What a joy it is that we work in Git and there you can see the history and find out who wrote this code. I looked at the story and found out that he wrote this code himself. Before you complain about the low quality of the code, make sure that you didn’t write it.
Number of lines of code(More cheese - more holes. More holes - less cheese. More cheese - less cheese.)
You and I know the laws of dialectics very well. One of these laws tells us that quantitative changes will inevitably turn into qualitative ones. For this reason, we can draw a rule that the more code we write, the better it ends up being. At the same time, it is not at all necessary to produce all this amount of code in a working project. You can create a pet project, a startup, or take part in a hackathon. And many, many other ways to write more code.
The number of errors per unit lines of code is a constant value. For this reason, the following rule can be distinguished: unwritten error code does not contain. Closely related to this rule is another refactoring rule - less code - fewer errors. This rule is closely related to another, which in the literature is designated by the acronym KISS (keei it simple) - make it simple. The simpler the code you write, the better.
We write code not for computers, but for other developers
Writing code is the easiest part of a programmer's job. Today it is important to write code that other developers will understand. Today we write code not for computers, but for other developers.
The more code we write, the better it ends up being.
We listen carefully to the employer/client
Coding is used in almost all aspects of life and work now, be it directly or indirectly. It’s not just for companies in the tech sector. “An increasing number of businesses rely on computer code,
Coding is used in almost all aspects of life and work now, be it directly or indirectly. It’s not just for companies in the tech sector. “An increasing number of businesses rely on computer code,
Coding is used in almost all aspects of life and work now, be it directly or indirectly. It’s not just for companies in the tech sector. “An increasing number of businesses rely on computer code,