How to improve the quality of the code
We all have heard about the beautiful code. Books and pages of specialized resources are full of recommendations, standards, and just good advice. Modern languages offer many ways to elegantly express developer ideas. In general, all is well. It seems to be. But real life is harsh. For a number of completely objective reasons, only the happiest of us have the opportunity to work with a really high-quality code base. The majority, knowing almost all the details of the ideal way of working, live here and now, outside of paradise, being content with what is available.
But how to make your life better? How to make the quality level of the code grow. I will give a few of my own rules-reflections on this topic.
It is necessary to demand from programmers complete awareness of each written line of code. The rule sounds very simple: “I didn’t understand why it worked - do not push changes into the general storage” . Recently, I have been paying special attention to the realization at random. It is quite simple to recognize them: elaborate constructions, lack of comments, or their diligently vague wording ... The most accurate way is to ask the programmer to explain the mechanism for implementing suspicious functionality.
')
The results of the observations look frightening - almost all the "unconscious" functionality contains errors that appear almost instantly. And most often this is the so-called even bugs, when you fix the wrong area and you realize that only thanks to him everything else worked at least approximately correctly.
Pros: realizing the work done, rather than just achieving results that are similar to the truth, programmers grow professionally. The number of errors is also reduced, and most of them, by the complexity of the correction, lie on the level of banal typos. The implementation is more optimal, simple and visual - the algorithm is easy to read, even without additional documentation or comments.
Minuses. By the time it is very expensive. Especially if the level of programmers is not very high. The crutches will get accustomed badly in the team, where they too diligently adhere to this rule. And this is not so good: in difficult times (for example, when you need to urgently prepare a product for release), a pair of high-quality crutches are vital. Yes, and in calm times, they will help the team not to get stuck too long in the analytical deadlocks.
Sometimes you have to give in to the ideals and skip the not quite high-quality code. Even worse. Constantly having to make certain concessions - life is cruel and unfair. However, you need to have clear limits, beyond which no, no. So, in tense periods, you can look through your fingers at non-compliance with the intervals and naming rules, but dangerous negligence is better to stop sharply and cruelly, even if it somehow works and the deadlines are tight.
Pros. If you feel that the implementation is incorrect, despite the appearance of proper operation, you need to fix it. Because, firstly, the tension at crucial moments is so high - there is still not enough torment of conscience and accumulation of negativity. Secondly, to deliver the product is, of course, the primary goal, but it must fulfill its basic functions. It is one thing to release an application with a number of minor issues and another to make the customer happy with a useless piece of compiled code. I don’t know whether it’s a plus or a minus, but one cannot do without a developed sense here. As without stuffed cones. But still leave in the pros.
Minuses. You need to be prepared for pressure, both from below and above. How is it - you need more, and the team is distracted by the shine. Without the loss of nerves can not do. In addition, you can strongly substitute in case of failure of the project. In short, a solid risk.
Suppose a person is unable to solve problems fully consciously. Maybe there is simply no time to do it right - we had to pick up part of the parameters by typing. Or the right decision is too difficult - it is easier to make a simplified version and support it with a pair of crutches. This happens more often than you want. But just put up a little. Much better to cultivate candor in the team. Did not do very well - admit it in the comments, the text describing the commit, and even better, leave a note in the project management system.
Naturally, there should be no penalties for confessions.
Pros. Good times happen, the more clues left, the greater the chance that they will return to unfinished tasks and do everything correctly. Even if they do not return - an honest warning comment will save a lot of time and nerves to other programmers in the future, if not to correct the error, then at least to search for it ... It’s better that people know that the file parsing function does not fully support some of its formats from the description this function than after a week of strange problems will understand it myself. In addition, there is always a chance that, confessing to the unfinished work, the author will be ashamed and rework well.
Minuses. It’s very easy to lose control - employees can get used to it that it’s enough to admit to a jamb so that you don’t have anything for it. Here everything again rests on the sense of leadership. Shortcomings should not turn into a "fragrant" handful of guano, proudly scattered throughout the project. In other words, the main difficulty of this approach is the correct dosage of impunity.
Of course, no rule guarantees anything. In addition, each of them admits excesses that can negate any positive result. But something needs to be done. And to begin with a recognition of the problem: ideally, surely it will not work out, but we must strive to use resources as efficiently as possible .
But how to make your life better? How to make the quality level of the code grow. I will give a few of my own rules-reflections on this topic.
1. Full awareness of the actions performed.
It is necessary to demand from programmers complete awareness of each written line of code. The rule sounds very simple: “I didn’t understand why it worked - do not push changes into the general storage” . Recently, I have been paying special attention to the realization at random. It is quite simple to recognize them: elaborate constructions, lack of comments, or their diligently vague wording ... The most accurate way is to ask the programmer to explain the mechanism for implementing suspicious functionality.
')
The results of the observations look frightening - almost all the "unconscious" functionality contains errors that appear almost instantly. And most often this is the so-called even bugs, when you fix the wrong area and you realize that only thanks to him everything else worked at least approximately correctly.
Pros: realizing the work done, rather than just achieving results that are similar to the truth, programmers grow professionally. The number of errors is also reduced, and most of them, by the complexity of the correction, lie on the level of banal typos. The implementation is more optimal, simple and visual - the algorithm is easy to read, even without additional documentation or comments.
Minuses. By the time it is very expensive. Especially if the level of programmers is not very high. The crutches will get accustomed badly in the team, where they too diligently adhere to this rule. And this is not so good: in difficult times (for example, when you need to urgently prepare a product for release), a pair of high-quality crutches are vital. Yes, and in calm times, they will help the team not to get stuck too long in the analytical deadlocks.
2. The presence of a clear framework of permissible evil.
Sometimes you have to give in to the ideals and skip the not quite high-quality code. Even worse. Constantly having to make certain concessions - life is cruel and unfair. However, you need to have clear limits, beyond which no, no. So, in tense periods, you can look through your fingers at non-compliance with the intervals and naming rules, but dangerous negligence is better to stop sharply and cruelly, even if it somehow works and the deadlines are tight.
Pros. If you feel that the implementation is incorrect, despite the appearance of proper operation, you need to fix it. Because, firstly, the tension at crucial moments is so high - there is still not enough torment of conscience and accumulation of negativity. Secondly, to deliver the product is, of course, the primary goal, but it must fulfill its basic functions. It is one thing to release an application with a number of minor issues and another to make the customer happy with a useless piece of compiled code. I don’t know whether it’s a plus or a minus, but one cannot do without a developed sense here. As without stuffed cones. But still leave in the pros.
Minuses. You need to be prepared for pressure, both from below and above. How is it - you need more, and the team is distracted by the shine. Without the loss of nerves can not do. In addition, you can strongly substitute in case of failure of the project. In short, a solid risk.
3. Frankness.
Suppose a person is unable to solve problems fully consciously. Maybe there is simply no time to do it right - we had to pick up part of the parameters by typing. Or the right decision is too difficult - it is easier to make a simplified version and support it with a pair of crutches. This happens more often than you want. But just put up a little. Much better to cultivate candor in the team. Did not do very well - admit it in the comments, the text describing the commit, and even better, leave a note in the project management system.
Naturally, there should be no penalties for confessions.
Pros. Good times happen, the more clues left, the greater the chance that they will return to unfinished tasks and do everything correctly. Even if they do not return - an honest warning comment will save a lot of time and nerves to other programmers in the future, if not to correct the error, then at least to search for it ... It’s better that people know that the file parsing function does not fully support some of its formats from the description this function than after a week of strange problems will understand it myself. In addition, there is always a chance that, confessing to the unfinished work, the author will be ashamed and rework well.
Minuses. It’s very easy to lose control - employees can get used to it that it’s enough to admit to a jamb so that you don’t have anything for it. Here everything again rests on the sense of leadership. Shortcomings should not turn into a "fragrant" handful of guano, proudly scattered throughout the project. In other words, the main difficulty of this approach is the correct dosage of impunity.
Of course, no rule guarantees anything. In addition, each of them admits excesses that can negate any positive result. But something needs to be done. And to begin with a recognition of the problem: ideally, surely it will not work out, but we must strive to use resources as efficiently as possible .
Source: https://habr.com/ru/post/196280/
All Articles