How important it is to write good code
I have to read a lot of code. This is open source, and all sorts of frameworks, and enterprise application code. About the last I would like to talk today.
Most of the enterprise application code sucks. Applications are buggy and slow, they are difficult to test, constantly having problems with deployment and updating. It is as if no one is surprised.
But the people who wrote the suck code are surprised. These people, with considerable experience, know several languages, have read many books, know OOP, SOLID, refactoring, patterns and other obscure words. That is about the same as many of you reading this post.
')
In 1969, an experiment was conducted. During the experiment, two identical cars were left in two places - in a prosperous campus and a disadvantaged area of ​​a large city. It is not surprising that in a dysfunctional place the car only stood for a couple of days and was gutted, and in a safe place the car stood untouched for a week. But as soon as the surviving car broke the glass, the inhabitants of this most prosperous town in a few hours dismantled it into parts and turned it upside down.
Later, scientists called this phenomenon "Theory of Broken Windows." According to the theory, any manifestation of disorder or violation of the norms provokes people to forget about the rules as well. The theory has received several experimental confirmations and it can be considered quite reliable.
There is also the opposite effect. Maintaining order leads to the fact that others also maintain order.
In enterprise development, pressure on the timing and uncertainty of requirements is so high that it seems to be “quick and dirty” - a much better option than doing it right. Immediately, the “fast and dirty” approach begins to spread throughout the application, both through clipboard inheritance (aka copy-paste) and due to the effect of broken windows.
Another factor affecting the quality of the code is the complexity and imperfection of the platforms and frameworks used in development. Because of this, hacks and ridiculous workarounds often appear in the code. Over time, it starts to seem that these hacks are good code. Even when the problems of the frameworks are fixed, people continue to use hacks. By the way, these hacks can eventually get on the Internet through forums, blogs or pastebin and spread far beyond the limits of a single application.
You can say that the quality of the code does not affect the quality of the application. Alas, it still affects. Programmers make mistakes. The worse the code, the more difficult it is to find and correct these errors so as not to create new ones. Pressing the timing and complexity most likely will not let you write good code and another hack will appear.
In open source and product development, this is less common. There are more quality control and less time pressure.
Often, programmers forget that program code is written primarily for people. Even if you write the program alone, then after looking at it in a month, you do not remember why you wrote this or that piece of code and what it is responsible for.
A good code must, first of all, express intentions very clearly. Unfortunately, the “fast and dirty” development methods hit primarily on the understanding of the code. Improving the code is deliberately postponed until better times, when there will be a pause to refactor. Those best times never come, and the code begins to be read and refined immediately after being hit by the source control.
Even if you are completely satisfied with your code (in most cases, programmers are happy with code), then think about how your code will be read by another person (in most cases, programmers are unhappy with someone else's code).
The only way to achieve high productivity and efficiency is to write good code right away. The only tool for improving the quality of the code is yourself. If you do not always strive to make good code, then neither tests nor static analysis tools will help you. Even the review of other programmers will not help. The code can always be made so confusing that it will be impossible to find an error when reading, while pretending that the code is very important and no one will undertake to rewrite it.
First you need to think about structure and naming. A code with encrypted identifiers and an obscure execution flow is likely to contain errors. Do not allow such a code, it is much cheaper than correcting errors.
Clearly express intentions in your code, minimize non-obvious implicit aspects. No need to strive to make the code as concise as possible, strive to make it as clear as possible.
If you have to edit the code, then do not create hacks. Spend a little time, write normally. Save on support. If the code is completely bad, was made “quick and dirty” and covered with hacks, then just drop it and rewrite it. Just do not try to rewrite everything. Consider productivity: the programmer writes 40-60 debugged lines of code per day at a normal pace and 120-200 in an accelerated (high concentration, clear goal, it is clear what to do).
If you write “quickly and dirty” yourself, for example, a prototype for specifying requirements, then throw out the code and rewrite it normally right after your code does its job.
If you copied a part of the code from another place or, God forbid, from the Internet, then understand how it works before uploading changes to the source control. In general, do not use code snippets that are incomprehensible to you.
Always keep your code clean and tidy, use tools that help you do it. You will not do this - the code will very quickly turn into a garbage can. Collect statistics on the density of problems in the code, it will help you better understand how to write good code.
Reread your code. Refactor constantly while writing. Remember that refactoring “later” never comes.
Think about what kind of code you want to write before you start writing it. Code writing itself is such an absorbing process that there is no time to think about quality. The state of flow is a state of freedom of expression. It is necessary to limit self-expression in advance so that the code is good.
Everyone is familiar with the error cost curve:
The error found and eliminated at the coding stage is 10 times cheaper than the error found during testing and 100 times cheaper than the error found in production. In the history there are real examples of errors, the correction of which cost tens of thousands of dollars.
Therefore, it is very important to eliminate errors at the development stage, and by the efforts of the developers themselves.
Do not confuse good and perfect code. The ideal code does not exist, it makes no sense to engage in endless improvement in the pursuit of the ideal. Good code is a code that is readable, understandable, solves a problem, is properly structured and contains no errors. Writing a good code is not just your goal, it is your responsibility.
Most of the enterprise application code sucks. Applications are buggy and slow, they are difficult to test, constantly having problems with deployment and updating. It is as if no one is surprised.
But the people who wrote the suck code are surprised. These people, with considerable experience, know several languages, have read many books, know OOP, SOLID, refactoring, patterns and other obscure words. That is about the same as many of you reading this post.
')
Broken window theory
In 1969, an experiment was conducted. During the experiment, two identical cars were left in two places - in a prosperous campus and a disadvantaged area of ​​a large city. It is not surprising that in a dysfunctional place the car only stood for a couple of days and was gutted, and in a safe place the car stood untouched for a week. But as soon as the surviving car broke the glass, the inhabitants of this most prosperous town in a few hours dismantled it into parts and turned it upside down.
Later, scientists called this phenomenon "Theory of Broken Windows." According to the theory, any manifestation of disorder or violation of the norms provokes people to forget about the rules as well. The theory has received several experimental confirmations and it can be considered quite reliable.
There is also the opposite effect. Maintaining order leads to the fact that others also maintain order.
How does this affect the code
In enterprise development, pressure on the timing and uncertainty of requirements is so high that it seems to be “quick and dirty” - a much better option than doing it right. Immediately, the “fast and dirty” approach begins to spread throughout the application, both through clipboard inheritance (aka copy-paste) and due to the effect of broken windows.
Another factor affecting the quality of the code is the complexity and imperfection of the platforms and frameworks used in development. Because of this, hacks and ridiculous workarounds often appear in the code. Over time, it starts to seem that these hacks are good code. Even when the problems of the frameworks are fixed, people continue to use hacks. By the way, these hacks can eventually get on the Internet through forums, blogs or pastebin and spread far beyond the limits of a single application.
You can say that the quality of the code does not affect the quality of the application. Alas, it still affects. Programmers make mistakes. The worse the code, the more difficult it is to find and correct these errors so as not to create new ones. Pressing the timing and complexity most likely will not let you write good code and another hack will appear.
In open source and product development, this is less common. There are more quality control and less time pressure.
Code is written for people
Often, programmers forget that program code is written primarily for people. Even if you write the program alone, then after looking at it in a month, you do not remember why you wrote this or that piece of code and what it is responsible for.
A good code must, first of all, express intentions very clearly. Unfortunately, the “fast and dirty” development methods hit primarily on the understanding of the code. Improving the code is deliberately postponed until better times, when there will be a pause to refactor. Those best times never come, and the code begins to be read and refined immediately after being hit by the source control.
Even if you are completely satisfied with your code (in most cases, programmers are happy with code), then think about how your code will be read by another person (in most cases, programmers are unhappy with someone else's code).
Commitment to quality
The only way to achieve high productivity and efficiency is to write good code right away. The only tool for improving the quality of the code is yourself. If you do not always strive to make good code, then neither tests nor static analysis tools will help you. Even the review of other programmers will not help. The code can always be made so confusing that it will be impossible to find an error when reading, while pretending that the code is very important and no one will undertake to rewrite it.
First you need to think about structure and naming. A code with encrypted identifiers and an obscure execution flow is likely to contain errors. Do not allow such a code, it is much cheaper than correcting errors.
Clearly express intentions in your code, minimize non-obvious implicit aspects. No need to strive to make the code as concise as possible, strive to make it as clear as possible.
If you have to edit the code, then do not create hacks. Spend a little time, write normally. Save on support. If the code is completely bad, was made “quick and dirty” and covered with hacks, then just drop it and rewrite it. Just do not try to rewrite everything. Consider productivity: the programmer writes 40-60 debugged lines of code per day at a normal pace and 120-200 in an accelerated (high concentration, clear goal, it is clear what to do).
If you write “quickly and dirty” yourself, for example, a prototype for specifying requirements, then throw out the code and rewrite it normally right after your code does its job.
If you copied a part of the code from another place or, God forbid, from the Internet, then understand how it works before uploading changes to the source control. In general, do not use code snippets that are incomprehensible to you.
Always keep your code clean and tidy, use tools that help you do it. You will not do this - the code will very quickly turn into a garbage can. Collect statistics on the density of problems in the code, it will help you better understand how to write good code.
Reread your code. Refactor constantly while writing. Remember that refactoring “later” never comes.
Think about what kind of code you want to write before you start writing it. Code writing itself is such an absorbing process that there is no time to think about quality. The state of flow is a state of freedom of expression. It is necessary to limit self-expression in advance so that the code is good.
Economy code quality
Everyone is familiar with the error cost curve:
The error found and eliminated at the coding stage is 10 times cheaper than the error found during testing and 100 times cheaper than the error found in production. In the history there are real examples of errors, the correction of which cost tens of thousands of dollars.
Therefore, it is very important to eliminate errors at the development stage, and by the efforts of the developers themselves.
At last
Do not confuse good and perfect code. The ideal code does not exist, it makes no sense to engage in endless improvement in the pursuit of the ideal. Good code is a code that is readable, understandable, solves a problem, is properly structured and contains no errors. Writing a good code is not just your goal, it is your responsibility.
Source: https://habr.com/ru/post/206294/
All Articles