The MOST major programming pattern

All the good time of the day, I have been programming for 8 years already, and programming in all its manifestations: server development in different programming languages, client development, network programming, linux administration, performance optimization. And when you do something for such a long time, sincerely you love him and strive for self-development, various causal relationships in the relevant field inevitably begin to appear, you begin to see those relationships that you didn’t even guess about before, or simply considered them to be insignificant, this is what people call experience.

And it is about one of these causal relationships that I would like to share with you in this article. I thought to write that this is one of the most important causal relationships for being a little less radical, but still not, this causal relationship is the most important causal relationship in programming with a huge margin. It runs like a red thread through absolutely all areas of programming: writing code, designing an interface, deploying an application, organizing the work of a team, keeping a bug tracker, and so on. And I call this sacred causal relationship minimization of variables .

By the term variable, I mean not only ordinary variables (which are declared through the keywords var , let , function ), but also variables in a more abstract sense of the word: folders created in the project tree, libraries connected, number of ajax calls per server, number components in the interface, the number of protocols that a programmer must follow when committing a code (for example, code review, each feature in a separate branch), and so on.

In fact, the entire programming process is a search of variations in the direction of how to implement this or that functionality using the maximum minimum number of variables (at least I look at programming from this perspective). The code that implements the feature with fewer dependencies / files / lines of code is better than the one that implements the same functionality with a larger number of variables. If the utilitarian class contains only one function - you need to get rid of this utilitarian class, if the function consists of only one line - you need to get rid of this function, if the component contains only 10 lines of code - you need to delete this component, if there is only one file in the folder - you need to get rid of this folder, and so on. And when several thousand of these seemingly minor changes are added together, the result is a beautiful, concise and minimalistic code that is very easy to read. The devil is in the details as they say.

Here is a list of positive effects that occur when you start programming based on the principle of minimizing variables:

• Less bugs. Since a smaller amount of code is written, the number of places where you can make a mistake, respectively, also decreases.
• It is easier to introduce new people into the project. The complexity of the project is directly proportional to the number of variables in this project; the fewer the variables, the easier it is to introduce new people.
• Easier to add new functionality. Since you need to study a smaller amount of code, it becomes easier to “load” the functionality into the head, and as a result, add new functionality or modify the existing code.
• Predictability. The programming process becomes much more predictable, it becomes easier for you to predict how long it will take to develop a particular feature due to the decrease in the number of gags. Usually, it is precisely the plugging that causes the greatest number of problems, and leads to the delaying of the deadlines.

But very often the opposite happens; programmers start to assert themselves by introducing new variables. Introduced 20 different libraries, CSS frameworks, creates a huge number of multi-level abstractions like UserFactoryManager (especially Java programmers sin for some reason), creates too many directories, introduces more advanced development methodologies, adds more protocols before committing files, and so on. And the motivation behind such decisions can be understood, because it creates the illusion of professionalism, say, look at how much I know, and with what complex abstractions I can operate. But often it causes enormous harm to the project.

Don't misunderstand me, I don’t mind using more advanced methodologies, frameworks and technologies. I’m just saying that they are often introduced simply because of the hype, and not because this technology solves any pressing problem in the project.

Solving a problem with too many variables can be called Overengineering . But agree that if you describe this situation as the fact that the problem is solved by too many variables, it is a much more accurate description of this phenomenon.

Often, the introduction of new variables is justified by scalability, they say if you create a UserManagerFactorythen we will be able at any moment to take and add a function if the need arises. But in reality, scalability is not when many variables are introduced, but vice versa when there are few variables. Think about where it will be easier for you to write a new functionality: in the chrome browser engine or in a completely new project that you are writing from scratch? The introduction of new variables does not lead to the scalability of the architecture. What really improves the scalability of a project is when you remove unnecessary variables and simplify existing code.

A huge number of unnecessary variables - this is the reason why I hate the fierce hatred of the Scala programming language, and the reason why I love JavaScript. Scala is just the quintessence of an over complicated, very confusing type system, many concepts that duplicate each other, implicit conversions, a huge number of ways to do the same thing. When I use this programming language, I think not about what needs to be done, but about howdo it. I often find myself just now, my goal is just to shut the compiler. On the other hand, JavaScript is the complete opposite of Scala, it is an order of magnitude more minimal, using it I spend a significantly smaller amount of mental effort to express a particular concept. Of course, such simplicity also has its drawbacks, for example, in Scala, the compiler reports an error at the compilation stage, while in JavaScript you can learn about an error only in runtime and it’s also impossible for JavaScript to write the same functional IDE as for strictly typed languages, but these are the victims that I am willing to accept.

The principle of minimizing variables should also be applied when designing interfaces, for example, let's compare web interfaces for two competing social networks for dating Tinder and Badoo. In fact, there is only one page in the Tinder web interface; a user profile, active chat and a search for new acquaintances are displayed on one page and there is no need to switch to other pages; in this interface, all user needs are met by the minimum number of components. While on Badoo, the functionality for switching to the user profile, the message interface and the page for searching for pairs are implemented as separate pages, the user needs to do more actions to meet the needs, and accordingly this interface is less effective. Of course, this is just one very small example, but when there are tens and hundreds of such examples, they all together determine whether the interface is thought out or not.When designing an interface, it is necessary to create the minimum number of components in order to satisfy the user's needs.

For the same reason, I absolutely do not like the approaches that share logic, data and representation, because in this case we get a situation where you need to create three files to write one piece of functionality, then the number of components starts to grow, and when the project has already become large, then the number of files begins to go off scale beyond all reasonable limits. For example, when writing web interfaces, styles are usually described in separate files, while the nodes to which these styles are attached are in another file. The main motivation for this separation, oddly enough, is scaling, say if you separate the nodes and their styles, then it will be easier to navigate the project, and you can independently develop these two parts of the functional. But let's see which variables are added with this approach: new files with styles for each component, selectors (they describe to which node styles are attached), cascading rules (if several selectors address the same node). While writing styles directly in the nodes to which these styles should be connected (for example, through the style attribute), then all these additional variables are not necessary, which greatly simplifies the code greatly. Recently, this approach is becoming more and more popular, there are many libraries that allow you to write styles directly in the style attribute. to which these styles should be connected (for example through the style attribute), then there is no need for all these additional variables, which greatly simplifies the code. Recently, this approach is becoming more and more popular, there are many libraries that allow you to write styles directly in the style attribute. to which these styles should be connected (for example through the style attribute), then there is no need for all these additional variables, which greatly simplifies the code. Recently, this approach is becoming more and more popular, there are many libraries that allow you to write styles directly in the style attribute.

New variables should be introduced into the project always gradually. For example, at the very beginning when writing a project, I have all the files in the root directory, generally without any subdirectories, simply because it is easier, and only when the number of files grows to 40-60 files, some files are grouped into directories. At the very beginning, no development methodology is needed, just throw all the programmers in a heap, give them tasks, then they will figure it out themselves, if it is too early to introduce a development methodology, it will feel like some kind of surrogate concept. When variables are introduced before they are needed, this is called premature optimization.

In the same way, it is necessary to minimize variables when writing documentation / articles, when I write documentation, I always think about exactly what minimum number of sentences I need in order to convey my thought. I literally analyze every sentence, and if it seems to me that there is no need for this sentence, it does not bear any additional semantic load, then it is deleted, the result is a very compressed page with documentation that contains the maximum amount of necessary information in the minimum amount of text.

In fact, in general, any variable has a presumption of guilt, no variable is needed until proven otherwise.

You can argue with me, say the same to me, discovered America, it has long been known and described by such principles as: Okama Razor , SOLID . But I prefer to call this concept precisely “minimization of variables”, simply because this interpretation is very concise in the head and, accordingly, is much easier to follow in practice. How many of you can boast that every point of the SOLID principle is remembered?

Beginners write simple code, because they do not know how to write complex, average programmers write complex code, simply because they can, professionals write simple code, because they do not want to write complicated code.

It must be remembered that any extreme is bad: if you fanatically minimize variables, right down to the atomic level, then this approach, as well as introducing too many variables, is extreme. And any extreme is known to be bad, the truth is always somewhere in the middle.