Agree to poor-quality code?
Sooner or later, all programmers are faced with the problem of writing code of proper quality. But what is behind this quality? No errors? Correctly designed names of fields and methods? Hard distribution of project files to directories?
According to Steve McConnell, the quality of the system reduces the cost of its development; the less effort we spend on understanding our code, the easier we add new functionality. And, as a result, the less we allow for code entanglement, the higher the quality. Many developers repeat: “In order to make the code easier to understand in the future, you need to work out a“ Naming Agreement ”.” Such an agreement makes sense, but indirectly with the quality of the code.
At the initial stages of developing complex applications, leading developers and project managers pose to the team the issue of adopting the “Naming Convention” (Coding & Naming Convention, abbreviated as CNC). Thus, they, in fact, give permission for a "religious" war. An agreement is a way of documenting the experience, preferences, and habits of one of the developers. Mostly documented (imposed) experience of the leading developer. Otherwise, the number of agreements becomes equal to the number of team members. Many teams choose an agreement recommended by an authoritative source (Java, .Net) to avoid disagreements. There is also an option when the team accepts corporate standard agreements.
')
If you look at the process of accepting an agreement from the outside, then you can see that a paradoxical situation occurs: the team forgets that the essence of the agreement is not in naming and not in authority, but in facilitating support and transferring the meaning of the written code. Let's draw an analogy with the Russian language. Grammar and punctuation are a kind of agreement. But if so, THEN now I have written the agreement on the name. But the meaning is clear and I can easily make changes.
It can be concluded that in pursuing the purity of the code in writing the agreement, we follow the stylistic design, not the semantic one. If the agreement is contrary to our experience, we will constantly make mistakes in writing.
It is more important to define not the agreement, but the principles that the developers should adopt and use in order to write the code more easily in support, maintenance and further development. The basic principles are communication, simplicity and flexibility.
Being guided by the first, always think, whether other person can read and understand the code written by you. The second principle suggests that you want to choose the simplest solution, and decompose any complex functionality (for example, a method with more than 10 lines) into several simple ones. Flexibility is the most difficult principle and I propose to turn to design patterns (design patterns) for its implementation.
Based on these principles, it is possible to build not a stylistic CNC agreement, but a semantic one. Indirectly, such an agreement is discussed in the book “Perfect Code” by Steve McConnell. Kent Beck talks more about the implementation of the three principles.
At the practical classes I conducted, a different, but equally important approach was chosen - “from the reverse”, widely used in mathematics. Having defined the agreement in the form of positive statements, we do not identify cases of abuse of structures that do not have a pronounced negative effect. Such cases can only potentially lead to code complexity; they are called "smells". So, if each programmer will allow them to appear, they will accumulate like a snowball. As a result, after a couple of months of development, the code that is correct in terms of “agreements” will be completely unreadable from the point of view of meaning. At the seminars, I invite teams to adopt a new agreement, which should be formed on the basis of the smells catalog. One of the first authors to raise the topic of refactoring and working with smell is Martin Fowler.
To improve the quality of the code, it is not enough to confine ourselves to the formal “Name Agreement”. Quality improvement is a complex process that requires continuous development of developers, the adoption of new agreements (both in form and in meaning) and adaptive principles of work.
The author of the article, Denis Miller, is a trainer and independent consultant on flexible methodologies in the field of software development. The main area of ​​interest: improving development processes and improving the quality of code programmers.
According to Steve McConnell, the quality of the system reduces the cost of its development; the less effort we spend on understanding our code, the easier we add new functionality. And, as a result, the less we allow for code entanglement, the higher the quality. Many developers repeat: “In order to make the code easier to understand in the future, you need to work out a“ Naming Agreement ”.” Such an agreement makes sense, but indirectly with the quality of the code.
At the initial stages of developing complex applications, leading developers and project managers pose to the team the issue of adopting the “Naming Convention” (Coding & Naming Convention, abbreviated as CNC). Thus, they, in fact, give permission for a "religious" war. An agreement is a way of documenting the experience, preferences, and habits of one of the developers. Mostly documented (imposed) experience of the leading developer. Otherwise, the number of agreements becomes equal to the number of team members. Many teams choose an agreement recommended by an authoritative source (Java, .Net) to avoid disagreements. There is also an option when the team accepts corporate standard agreements.
')
If you look at the process of accepting an agreement from the outside, then you can see that a paradoxical situation occurs: the team forgets that the essence of the agreement is not in naming and not in authority, but in facilitating support and transferring the meaning of the written code. Let's draw an analogy with the Russian language. Grammar and punctuation are a kind of agreement. But if so, THEN now I have written the agreement on the name. But the meaning is clear and I can easily make changes.
It can be concluded that in pursuing the purity of the code in writing the agreement, we follow the stylistic design, not the semantic one. If the agreement is contrary to our experience, we will constantly make mistakes in writing.
It is more important to define not the agreement, but the principles that the developers should adopt and use in order to write the code more easily in support, maintenance and further development. The basic principles are communication, simplicity and flexibility.
Being guided by the first, always think, whether other person can read and understand the code written by you. The second principle suggests that you want to choose the simplest solution, and decompose any complex functionality (for example, a method with more than 10 lines) into several simple ones. Flexibility is the most difficult principle and I propose to turn to design patterns (design patterns) for its implementation.
Based on these principles, it is possible to build not a stylistic CNC agreement, but a semantic one. Indirectly, such an agreement is discussed in the book “Perfect Code” by Steve McConnell. Kent Beck talks more about the implementation of the three principles.
At the practical classes I conducted, a different, but equally important approach was chosen - “from the reverse”, widely used in mathematics. Having defined the agreement in the form of positive statements, we do not identify cases of abuse of structures that do not have a pronounced negative effect. Such cases can only potentially lead to code complexity; they are called "smells". So, if each programmer will allow them to appear, they will accumulate like a snowball. As a result, after a couple of months of development, the code that is correct in terms of “agreements” will be completely unreadable from the point of view of meaning. At the seminars, I invite teams to adopt a new agreement, which should be formed on the basis of the smells catalog. One of the first authors to raise the topic of refactoring and working with smell is Martin Fowler.
To improve the quality of the code, it is not enough to confine ourselves to the formal “Name Agreement”. Quality improvement is a complex process that requires continuous development of developers, the adoption of new agreements (both in form and in meaning) and adaptive principles of work.
The author of the article, Denis Miller, is a trainer and independent consultant on flexible methodologies in the field of software development. The main area of ​​interest: improving development processes and improving the quality of code programmers.
Source: https://habr.com/ru/post/19936/
All Articles