Programmers - designers (how to increase the quality of the code)

    Having been engaged in software development for several years, I recently began to often think about what affects the quality of a developed product. The introduction of new practices (the same components of XP / Agile / Scrum) very quickly showed that the matter was not only in the organization of development - the personal qualities of developers always turn out to be the leaders. We will not dive headlong into all aspects of software quality, but consider only one of them: code quality.

    A typical practice is to evaluate a product by its external component, however, when creating Open Source solutions, and also, corny, when modifying an existing business logic, for a programmer, it is the source code that is the final product with which he has to work.

    The purpose of this article is not just to list the qualities of good code, this is done too often, and it would not be so interesting. Here I just briefly list what I’ve found. Then we look at some analogies.

    The first thing most developers call (I don’t know why :-) is the code comments (hint: middle ground - there should be neither more nor less). Then they talk about adhering to the coding style and 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 competent thinking over the structure of objects (layout). Everyone is using OOP now, and it needs to be understood and felt. Very few people call decomposition - basically, conscious TDD drivers (Test Driven Development), since 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 in web design. Since it was still necessary to take a technical course, I decided to sign up - and started going there. I knew little about the concept of “web design,” and I was quite surprised when I realized that we were not going to tell HTML at all. Instead, they started telling us about colors (first lesson), about perspective (the basis of the image), logos-branded-colors-and-styles, about typography. Next came the layout, reasoning about the need / sufficiency ... When I was told that our main working tool would not be an IDE (code writing environment), but ... Photoshop, I realized that this 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 (unless "for the soul"). But all this, as well as dozens of read and viewed articles on design, the basics of drawing, on the usability of interfaces, allowed me to become a good designer ... of code.

    Let's take a closer look: what is usually considered as the basis of the craft (or, if you like, art) of graphic design? Let's dwell on web design and UI.

    Simplicity and transparency for the user. Convenience of passive elements, as well as controls (now trendy is the direction of large fonts and input fields). Competent decomposition and layout: grouping of elements related by functionality or meaning into one block; a reasonable user-perceived number of elements in a group (read the article by 37signals “An Introduction to Using Patterns in Web Design "). Friendliness: hints where necessary, but at the same time lack of information overload. Eye-acceptable color combination. Necessarily - accuracy and thoughtful little things (pixel-to-pixel, nothing leaves the allocated fields, maintaining proportions, typography).

    This list is by no means complete - but you already see that we listed the same as above when we talked about code design?

    For comments on the source code, analogies in graphic design are various kinds of hints, informational texts, etc. Layout and decomposition are needed both there and there. The desire to remove duplicate elements in visual design (the “delete”, “edit” link column is bad) is quite consistent with the desire to combine the repeating code into some method or function. Accuracy in the design layout should be exactly the same as the accuracy of the code ("Oh, I forgot to take into account the overflow of the variable here ..."). Etc. These are just a few examples from the surface that show us the presence of an analogy.

    The set of 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 pleasant with himwork? Have you ever seen such a code? I am. But extremely rare.

    Knowledge of design principles is not limited to coding. It’s not a secret for anyone that no matter how hard you try, programmers no, no - but still you have to see and edit the layout (I know, this is terrible). Sometimes it happens that programmers design interfaces. Not that it is planned in advance - it’s just that the development is often organized so that the engine is written first, and then you won’t change anything, even if you are the most brilliant designer. An example of such a miracle may be the admin panel of Drupal, Jumla (with all due respect to these systems). On the blog control panel, LiveInternet just did not write "made by programmers."

    You should not limit design only to visual design and code design. Analysis of industrial design (as far as I understand this), article design (and from several sides: text design; layout; separately - headline design), etc. showed that the same design components are present in all these areas. Three groups of design properties (of course, quite strongly overlapping) were distinguished: functional requirements , usability (usability) and advertising properties (conducive to selling). In each of these blocks, 2-7 basic qualities were identified. Here I will not give a classification - 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 - the end-to-end vision of design? I see the importance of this in two aspects.

    The first is dear colleagues, developers! Do not be one-sided! Develop not only one hemisphere of the brain. Try to draw, compose, feel harmony. Think of beauty. Well, well, I omit “play musical instruments”, “write not only programs, but also poems” - it brought me a little bit. But - remember, no one has yet lost from a more harmonious development.

    Speaking a little more practical, and not just throwing slogans incomprehensible to someone, there is the idea of ​​holding usability workshops for developers. It is very interesting whether such a practice was already somewhere in Russia, and not only. If you know, please write to me.

    The second conclusions are more scientific. Carrying out design analogies between different areas / directions 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 comparing the principles of designing code based on OOP and the principles of designing visual interfaces. (Nothing is new under the moon — I remember Larry Konstantin writing about the shortcomings of object interfaces already in 1993. We can see not only the shortcomings of the object code, but also derive ways to solve the problem from analogies.) I'll try to publish a little later.

    I understand that much of this article remains behind the scenes. Perhaps some thoughts I could not clearly convey. Indeed, many written examples had to be left out of the article. But - it is impossible to fit everything, so for now, probably, this will be enough. And I'll try to add something else later.

    Also popular now: