Programmers - designers (how to increase the quality of the code)
Being engaged in software development for several years, I recently began to often think about what affects the quality of the developed product. The introduction of new practices (the same components of XP / Agile / Scrum) very quickly showed that it’s not just the development organization that matters - the personal qualities of the developers always lead. We will not now plunge headlong into all aspects of software quality, but consider only one of them: the quality of the code.
A typical practice is to evaluate a product by its external component, however, when creating Open Source solutions, and also, trivially, when modifying an existing business logic, for a programmer, the source code is the final product with which he has to work.
The goal of this article is not just to list the qualities of a good code, it is done too often, and it would not be so interesting. Here I will just briefly list the items found. Then we look at some analogies.
')
The first thing that most developers call (I don’t know why :-) is the comments to the code (hint: golden mean - there should be neither more nor less). Then they talk about the observance of style (coding style) and the general clarity, simplicity of the code. As a user of the product - Open Source Solutions - I need to know where to look for the functionality that I need to change. This also includes proper thinking through the structure of objects (layout). Everyone is now using OOP, and it must be understood and felt. Very few people call decomposition - mostly TDD-conscious (Test Driven Development), as this is the basis of testing.
Now I would like to consider the concept of quality on the other hand - on the example of graphic design. Once at the institute I saw a special course on “web design”. Since it was still necessary to take a technical course, I decided to sign up - and started going there. The concept of "web design" I knew little, and was surprised a lot when I realized that we were not going to tell HTML at all. Instead, they began to tell us about colors (first lesson), about perspective (the basis of the image), logos-brand-colors-and-styles, about typography. Next went the layout, the reasoning about the need / sufficiency ... When I was told that our main working tool would not be IDE (a medium for writing code), but ... Photoshop, I realized that it was an order of magnitude more interesting than what I expected. Then we shoveled a bunch of sites and looked at their mistakes.
No, I did not become a professional designer. I rarely draw something in Photoshop (except "for the soul"). But all this, as well as dozens of read and viewed articles on design, the basics of drawing, on usability of interfaces, allowed me to become a good designer ... of code.
Let's take a closer look: what is usually viewed as the basis of the craft (or, if you will, art) of graphic design? Let's stop on web design and UI.
Simplicity and transparency for the user. Convenience of passive elements, as well as controls (the fashionable now is the direction of large fonts and input fields). Competent decomposition and layout: grouping related elements by functionality or meaning into one block; Reasonable, user-perceived number of elements in a group (read the article from 37signals “ An Introduction to Using Patterns in Web Design ”). Friendliness: prompts where necessary, but at the same time, the lack of information overload. Acceptable color combination. Necessarily - accuracy and the thought over trifles (pixel-to-pixel, nothing leaves for the given fields, preservation of proportions, typography).
This list is by no means complete - but do you already see that we listed the same thing as above when talking about the design of the code?
For comments on the source code, the analogy in graphic design is various kinds of hints, informational texts, etc. Layout and decomposition are needed both there and there. The desire to remove duplicate elements in a visual design (the “delete”, “edit” links column is bad) is quite consistent with the desire to merge the duplicate code into some method or function. The accuracy in the design layout should be exactly the same as the accuracy of the code (“Oh, I forgot to take into account the variable overflow ...”). And so on. These are just a few examples from the surface that show us the existence of an analogy.
The combination of the basic design qualities of the code I call Code Usability. Your code will be used (read, edited, reused) by other people. How to make it so nice to work with him? Have you ever seen such a code? I am yes. But extremely rare.
Knowledge of design principles applies not only to writing code. It's no secret that no matter how hard you try, no-no-programmers - but you still have to see and edit the layout (I know, it's terrible). Sometimes it happens that programmers design interfaces. Not that it is planned in advance - it is just that the development is often organized in such a way that the engine is first written, and then nothing can be changed, even if you are the most ingenious designer. An example of such a miracle can be the admin panel of Drupal, Joomla (with all due respect to these systems). On the control panel blog LiveInternet just did not write "made by programmers."
You should not limit the design only to the visual design and design code. An analysis of the industrial design (as far as I understand this), the design of the articles (and from several sides: the design of the text itself; the layout; the heading design separately), etc. showed that the same design components are present in all these areas. Three groups of design properties (of course, quite strongly intersecting) were identified: functional requirements , usability (usability) and advertising properties (promoting merchantability). In each of these blocks, 2-7 basic qualities were identified. I will not give a classification here, this is a separate article with a separate analysis and conclusions, and this was not the problem.
What conclusions can be drawn from the conducted analogies - a through vision of the design? I see the importance of this in two aspects.
First, dear colleagues, developers! Do not be one-sided! Develop not only one hemisphere of the brain. Try to draw, arrange, feel the harmony. Think about beauty. Well, well, I omit “play musical instruments”, “write not only programs, but also poems” - this brought me a little. But - remember, no one has yet lost from a more harmonious development.
If we talk a little more practical, and not just throwing slogans incomprehensible to someone, there is the idea of ​​conducting usability workshops for developers. It is very interesting if there was such a practice somewhere in Russia, and not only. If you know, please write to me.
The second conclusions are more scientific. Conducting design analogies between different areas / areas will allow us to see interesting patterns and take a different look at familiar patterns. A few examples were above. Another interesting study is devoted to the comparison of code design principles based on OOP and the design principles of visual interfaces. (Nothing is new under the moon - Larry Konstantin, I remember, already in 1993 he wrote about the flaws of object interfaces. We can see not only the flaws of the object code, but from the analogies to derive solutions to the problem.) A little later I will try to publish.
I understand that much in this article is left overs. Perhaps some thoughts I could not clearly convey. Indeed, many written examples had to be left outside the article. But - it is impossible to fit everything, so for now, probably, this will be enough. And I will try to add something later.
A typical practice is to evaluate a product by its external component, however, when creating Open Source solutions, and also, trivially, when modifying an existing business logic, for a programmer, the source code is the final product with which he has to work.
The goal of this article is not just to list the qualities of a good code, it is done too often, and it would not be so interesting. Here I will just briefly list the items found. Then we look at some analogies.
')
The first thing that most developers call (I don’t know why :-) is the comments to the code (hint: golden mean - there should be neither more nor less). Then they talk about the observance of style (coding style) and the general clarity, simplicity of the code. As a user of the product - Open Source Solutions - I need to know where to look for the functionality that I need to change. This also includes proper thinking through the structure of objects (layout). Everyone is now using OOP, and it must be understood and felt. Very few people call decomposition - mostly TDD-conscious (Test Driven Development), as this is the basis of testing.
Now I would like to consider the concept of quality on the other hand - on the example of graphic design. Once at the institute I saw a special course on “web design”. Since it was still necessary to take a technical course, I decided to sign up - and started going there. The concept of "web design" I knew little, and was surprised a lot when I realized that we were not going to tell HTML at all. Instead, they began to tell us about colors (first lesson), about perspective (the basis of the image), logos-brand-colors-and-styles, about typography. Next went the layout, the reasoning about the need / sufficiency ... When I was told that our main working tool would not be IDE (a medium for writing code), but ... Photoshop, I realized that it was an order of magnitude more interesting than what I expected. Then we shoveled a bunch of sites and looked at their mistakes.
No, I did not become a professional designer. I rarely draw something in Photoshop (except "for the soul"). But all this, as well as dozens of read and viewed articles on design, the basics of drawing, on usability of interfaces, allowed me to become a good designer ... of code.
Let's take a closer look: what is usually viewed as the basis of the craft (or, if you will, art) of graphic design? Let's stop on web design and UI.
Simplicity and transparency for the user. Convenience of passive elements, as well as controls (the fashionable now is the direction of large fonts and input fields). Competent decomposition and layout: grouping related elements by functionality or meaning into one block; Reasonable, user-perceived number of elements in a group (read the article from 37signals “ An Introduction to Using Patterns in Web Design ”). Friendliness: prompts where necessary, but at the same time, the lack of information overload. Acceptable color combination. Necessarily - accuracy and the thought over trifles (pixel-to-pixel, nothing leaves for the given fields, preservation of proportions, typography).
This list is by no means complete - but do you already see that we listed the same thing as above when talking about the design of the code?
For comments on the source code, the analogy in graphic design is various kinds of hints, informational texts, etc. Layout and decomposition are needed both there and there. The desire to remove duplicate elements in a visual design (the “delete”, “edit” links column is bad) is quite consistent with the desire to merge the duplicate code into some method or function. The accuracy in the design layout should be exactly the same as the accuracy of the code (“Oh, I forgot to take into account the variable overflow ...”). And so on. These are just a few examples from the surface that show us the existence of an analogy.
The combination of the basic design qualities of the code I call Code Usability. Your code will be used (read, edited, reused) by other people. How to make it so nice to work with him? Have you ever seen such a code? I am yes. But extremely rare.
Knowledge of design principles applies not only to writing code. It's no secret that no matter how hard you try, no-no-programmers - but you still have to see and edit the layout (I know, it's terrible). Sometimes it happens that programmers design interfaces. Not that it is planned in advance - it is just that the development is often organized in such a way that the engine is first written, and then nothing can be changed, even if you are the most ingenious designer. An example of such a miracle can be the admin panel of Drupal, Joomla (with all due respect to these systems). On the control panel blog LiveInternet just did not write "made by programmers."
You should not limit the design only to the visual design and design code. An analysis of the industrial design (as far as I understand this), the design of the articles (and from several sides: the design of the text itself; the layout; the heading design separately), etc. showed that the same design components are present in all these areas. Three groups of design properties (of course, quite strongly intersecting) were identified: functional requirements , usability (usability) and advertising properties (promoting merchantability). In each of these blocks, 2-7 basic qualities were identified. I will not give a classification here, this is a separate article with a separate analysis and conclusions, and this was not the problem.
What conclusions can be drawn from the conducted analogies - a through vision of the design? I see the importance of this in two aspects.
First, dear colleagues, developers! Do not be one-sided! Develop not only one hemisphere of the brain. Try to draw, arrange, feel the harmony. Think about beauty. Well, well, I omit “play musical instruments”, “write not only programs, but also poems” - this brought me a little. But - remember, no one has yet lost from a more harmonious development.
If we talk a little more practical, and not just throwing slogans incomprehensible to someone, there is the idea of ​​conducting usability workshops for developers. It is very interesting if there was such a practice somewhere in Russia, and not only. If you know, please write to me.
The second conclusions are more scientific. Conducting design analogies between different areas / areas will allow us to see interesting patterns and take a different look at familiar patterns. A few examples were above. Another interesting study is devoted to the comparison of code design principles based on OOP and the design principles of visual interfaces. (Nothing is new under the moon - Larry Konstantin, I remember, already in 1993 he wrote about the flaws of object interfaces. We can see not only the flaws of the object code, but from the analogies to derive solutions to the problem.) A little later I will try to publish.
I understand that much in this article is left overs. Perhaps some thoughts I could not clearly convey. Indeed, many written examples had to be left outside the article. But - it is impossible to fit everything, so for now, probably, this will be enough. And I will try to add something later.
Source: https://habr.com/ru/post/17479/
All Articles