Get best of the week

Pure code: causes and effects



Author: Victor Svirsky, Senior Python Developer / Team Lead, DataArt

How many programmers, so many definitions, what is clean code. When interviewing, I often hear that good code is one that is easy to read. I agree, but as my personal experience suggests, this is only the tip of the iceberg.

The first bell that tells us that the code is no longer clean is an increase in the development time of new functionality and an increase in regression scopes at the slightest change in the system. This is due to the fact that technical debt is accumulating, the components in the system are very closely connected, and there are no autotests. The reasons for this may be:

  • External - such as pressure from the business and its desire to get new functionality faster.
  • Internal - poorly developed development processes and interaction within the team, lack of control and development standards or a banal lack of competence.

Do not postpone work on the quality of code and architecture in a long box. During the sprint, it is important to be able to separate tasks that are of direct value to the business (tasks with new functionality) and technical tasks that have only an indirect effect on the business. The proportion of separation depends on the current state of the project, the time frame and the number of free hands.

What is clean code?


It turns out to say that the code is clean and the system is designed correctly, easy reading of the code is not enough. He must possess other qualities:

  • . . , . , , .
  • , , . , . . , . , .
  • . . . -, OWASP.
  • — , . , , . , , . , .
  • . , . , .

In order to avoid a subjective assessment of the quality of its code, the term “code smells” or “stock code” was introduced in 1961. This is a group of rules and recommendations that clearly define whether it is time to do refactoring. The "odor" leads to code decay, and developers should always strive to eliminate it. The need for refactoring directly follows from the smell of the code, and by preventing the cause, we can avoid the consequences. You can read more about the key signs that you should start refactoring in Martin Fowler’s book “Refactoring. Improving existing code. "

Should I write clean code?


Definitely worth it! But not always and not everywhere it is worth paying too much attention to cleanliness.

Do not forget about the usefulness and life of your code. For example, if you are faced with the task of developing a concept - PoC (Proof of concept), and you prove that the selected technology stack performs the task, your code will become irrelevant in a week or two. It’s not worth the effort to improve this functionality.

There is an opinion that it is not necessary to monitor the quality of the code or parts of the system that will soon be replaced. And this is not true for several reasons. High quality workmanship will make the transition or integration with new parts easier, more seamless and faster. It will certainly simplify life in cases where several versions of the code have to be supported at the same time. The number of regression errors with clean code will be many times less. Also, do not forget that there is nothing more permanent than temporary. Perhaps the task of improving this part of the code for several months will lie in the backlog.

What will help improve your code?


Most programmers dream of writing code quickly and beautifully, so that everything works perfectly the first time. But not everyone succeeds in making the code not only working, but understandable. How to succeed in writing clean code? There are two ways - self-organization and teamwork.



Self-organization


Consider several possible ways to improve individual code quality. These recommendations are suitable for developers at any level.


  1. , — . — . IDE ( ) , , . IDE , . — .

    . , .
  2. open source
    . , . , . !

  3. , . . . , , 10, , . .

    . -, .

  4. . . . .

    . .


  5. . . - . , .

    — , , , , .


  6. , . — .
  7. !

    , .


Most tasks are solved in a team. It is very important to share responsibility for quality between its participants. The larger the team, the more difficult it is to keep the product in good condition. Let's consider several approaches of code retention in the above conditions.

  1. Code Review
    This is a simple principle for understanding and execution. At least two people, including the author of the code, check the code.

    There are several things to consider when checking your code:

    • One of them is to check if the code violates the rules of the code agreement. This is a process that can and should be automated using static analyzers in CI (continuous integration).
    • Others are code maintainability and error handling that cannot be verified automatically.
    • , , . , ?

  2. (Continuous integration)

    , .

    , :

    • . . , . , , .
    • , , .
  3. (Coding onventions)

    . , . , , .

    , , , . . , , . , . , . .

    , , . — , - .

    . , . .


  4. , . , , .

    , . , . , , .

    -. . , . . , .


  5. , , . . , .

    , :

    • ? , . , .
    • ?
    • ()?
    • ?
    • — ?

    , , . , .


  6. , . SonarQube. :



    • — . , . , .


    • , — DRY (Don’t repeat yourself).


    • . . . , .


    • , , , .


    • . , . , .

***


Errors in the code are akin to a carbon footprint. It is completely impossible to escape, and excess exhaust alone will not kill either humanity or its surrounding nature. Nevertheless, to reduce the negative effect of one's stay on the planet today seems a natural need. In approximately the same way, writing clean code is the responsibility of every developer. No matter which path you choose, you must strive to write working and understandable code.

Well, if you can not turn purity into a fetish, given the life of our code and evaluating the feasibility of further improvements. The main thing to remember about people: users who can fail even a small part of the system developed by us, and engineers who have to support this system.

More articles:


All Articles