February 7, 2008 at 17:20Agree to low-quality code?
Sooner or later, all programmers are faced with the problem of writing code of good quality. But what is hidden behind this quality? Lack of mistakes? Properly designed field and method names? Hard distribution of project files in directories?
According to Steve McConnell, the quality of the system reduces the cost of its development; the less effort we spend on understanding our own code, the easier we add new functionality. And, as a result, the less we allow code entanglement, the higher the quality. Many developers repeat: “To make it easier to understand the code in the future, you need to develop a“ naming convention ”.” Such an agreement makes sense, but is indirectly related to the quality of the code.
At the initial stages of the development of complex applications, leading developers and project managers pose the team with the question of adopting a “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. The experience of a leading developer is mainly documented (imposed). Otherwise, the number of agreements becomes equal to the number of team members. Many teams, in order to avoid disagreements, choose an agreement recommended by an authoritative source (Java, .Net). There is also an option when the team accepts agreements at the corporate standard level.
If you look from the side at the process of accepting the agreement, you can see that a paradoxical situation is happening: the team forgets that the essence of the agreement is not in the name and authority, but in facilitating the support and conveying the meaning of the written code. Let us draw an analogy with the Russian language. Grammar and punctuation are some kind of agreement. But if so, THEN THIS 4A I HAVE FINISHED THE AGREEMENT BY NAME. But the meaning is clear and I can easily make changes.
It can be concluded that in pursuit of the purity of the code in writing the agreement, we follow the stylistic design, and not the semantic. If the agreement is contrary to our experience, we will constantly make spelling mistakes.
It is more important to determine not an agreement, but the principles that developers must learn and use in order to write code that is easier to maintain, maintain and further develop. The basic principles are communication, simplicity and flexibility.
Guided by the first, always think whether another person can read and understand the code you wrote. The second principle suggests that you need to choose the simplest solution, and decompose any complex functionality (for example, a method of more than 10 lines) into several simple ones. Flexibility is the most complex principle, and for its implementation I propose to turn to design patterns.
Based on these principles, we can no longer build a stylistic agreement CNC, but semantic. Indirectly, such an agreement is discussed in the book "Perfect Code" by Steve McConnell. Kent Beck talks even more about the implementation of the three principles.
In my practical classes, I chose a different, but no less important approach - “from the opposite”, which is widely used in mathematics. Defining 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 every programmer will allow their appearance, then 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 in terms of meaning. At the seminars, I invite the 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 smells is Martin Fowler.
To improve the quality of the code, it is not enough to limit ourselves to the formal “Naming 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 agile methodologies in the field of software development. Main area of interest: improving development processes and improving the quality of code for programmers.
According to Steve McConnell, the quality of the system reduces the cost of its development; the less effort we spend on understanding our own code, the easier we add new functionality. And, as a result, the less we allow code entanglement, the higher the quality. Many developers repeat: “To make it easier to understand the code in the future, you need to develop a“ naming convention ”.” Such an agreement makes sense, but is indirectly related to the quality of the code.
At the initial stages of the development of complex applications, leading developers and project managers pose the team with the question of adopting a “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. The experience of a leading developer is mainly documented (imposed). Otherwise, the number of agreements becomes equal to the number of team members. Many teams, in order to avoid disagreements, choose an agreement recommended by an authoritative source (Java, .Net). There is also an option when the team accepts agreements at the corporate standard level.
If you look from the side at the process of accepting the agreement, you can see that a paradoxical situation is happening: the team forgets that the essence of the agreement is not in the name and authority, but in facilitating the support and conveying the meaning of the written code. Let us draw an analogy with the Russian language. Grammar and punctuation are some kind of agreement. But if so, THEN THIS 4A I HAVE FINISHED THE AGREEMENT BY NAME. But the meaning is clear and I can easily make changes.
It can be concluded that in pursuit of the purity of the code in writing the agreement, we follow the stylistic design, and not the semantic. If the agreement is contrary to our experience, we will constantly make spelling mistakes.
It is more important to determine not an agreement, but the principles that developers must learn and use in order to write code that is easier to maintain, maintain and further develop. The basic principles are communication, simplicity and flexibility.
Guided by the first, always think whether another person can read and understand the code you wrote. The second principle suggests that you need to choose the simplest solution, and decompose any complex functionality (for example, a method of more than 10 lines) into several simple ones. Flexibility is the most complex principle, and for its implementation I propose to turn to design patterns.
Based on these principles, we can no longer build a stylistic agreement CNC, but semantic. Indirectly, such an agreement is discussed in the book "Perfect Code" by Steve McConnell. Kent Beck talks even more about the implementation of the three principles.
In my practical classes, I chose a different, but no less important approach - “from the opposite”, which is widely used in mathematics. Defining 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 every programmer will allow their appearance, then 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 in terms of meaning. At the seminars, I invite the 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 smells is Martin Fowler.
To improve the quality of the code, it is not enough to limit ourselves to the formal “Naming 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 agile methodologies in the field of software development. Main area of interest: improving development processes and improving the quality of code for programmers.