Some time ago in one of my articles I described the concept of plasticine architecture . In continuation, I would like to describe one of the most common “programming styles”, which, unfortunately, is very often found among young and inexperienced specialists.

So, let's imagine that a programmer has to write a new module or add some functionality to an existing system. What will an experienced specialist do? He poured himself Chinese tea, leaned back in his chair, took a pencil and began to think. He will draw the structure of the module, consider the entities, the interfaces and the interaction between them, go down to the level of specific methods, and probably write unit tests on the interfaces. Only then will he begin to fill the existing structure with code (or delegates this task to a dozen Hindu coders).

Now let's see what a typical junior will do in this case. There is a task - it must be solved. They were so taught in universities. Many of them are still under the influence of the marginal slogan “Write the code, b ## db!”. So, he pours himself instant coffee, puts on headphones with something harder and louder and goes into the stream for a couple of hours.
')
All anything. I have nothing against coffee, headphones or flow conditions. Moreover, it is usually the most efficient and often the only way to write good code. But we are considering a typical case of a young and inexperienced programmer, so let's look at the results.

What it looks like

First, the functionality is implemented. She works on most cases and looks quite satisfactory to herself. The first thing I want to do is to rejoice that the intern has so quickly accomplished the task, to praise him and give the next one. But try to look into the code. You will immediately understand why the fragment was implemented so quickly. And it will be scary.

Here is the code that I usually call the “dump of the stream of consciousness” . I call the code this way because it is written in a single block, without trying to realize it, without trying to return and change something. Below I will list its main characteristics.

First, the code usually consists of one long, very long method. In it, for example, it can sequentially initialize the connection to the database, form the necessary request, retrieve data, process it and (let it be webdesigns) generate HTML for the final presentation. The author writes about what he is thinking at the moment, he is completely in the flow and focused on solving the problem. His consciousness gradually solves the problem and these steps are immediately reflected in the code.

Secondly, this code is usually filled with commented lines and more unnecessary pieces, which are a pity to throw out and do not need to be left.

Thirdly, usually in such code only basic use cases, standard conditions and branches are processed. With a slight deviation from the standard user behavior, the code mercilessly fails and falls with unhandled exceptions.

Why is that bad

Partly I wrote about this a little higher, but there are still quite a large number of factors that need to be said.

The greatest evil from such a code is the absolute impossibility of accompanying it . Indeed, in a few days, not only the “man from the street,” but also the author himself, will not be able to understand what is happening inside this piece, and for which this branching is responsible. It is obvious that programmers, including the author, will be engaged in supporting such code not only reluctantly, but also extremely inefficiently.

By the way, this will affect not only the project objectives, delaying the deadlines and lowering the quality , which will undoubtedly upset PMA. Working with such a code will seriously undermine the motivation of the team from two directions at once, depriving the programmer of his favorite aspects of work: “I am doing something cool and interesting” and “I am doing an excellent job with my task.”

Another of the sick and unpleasant properties of the “dump of the stream of consciousness” is that the problems are not immediately visible, since at first glance “everything works.” Very often, when testing such a code (of course, according to the black box principle), the tester encounters bugs, which are very difficult to reproduce . Usually they arise from the intertwined, completely devoid of structure of the mass of calls and the implicit “interferences” associated with it, when one piece of code affects the other in a completely surprising way.

Thus, in the piggy bank of the "victims" to the programmer and project manager already existing there, a specialist in testing is added. And, in conclusion, in order to assemble a complete project team under this leaky umbrella, we’ll add that the product manager (or the customer in the case of customized development) cannot effectively add new features to the product, and the analyst has no idea whether it’s possible to make a minimal change , and whether he will hear transcendental deadlines (and even obscene expressions) from programmers for the simple sentence “to slightly change the operation of the search filter”.

The conclusion is simple: a “dump” is an evil that must be fought.

To prevent this article from being too theoretical, I will try to give some tips on how to do this, which I put into practice in my company.

How to deal with it

The first and most important thing to understand when you encounter such code is “this is normal” .

If you have not yet begun to deal with “dumps” (and your predecessor did not do this), then most likely you have several programmers in the team who use this approach, absolutely sincerely believing that they are doing everything right.

Chances are that they are also abused by newcomers taken into your team right from college.

And this is the normal behavior of yesterday's student, who is faced with a task, and who must fulfill it. He sees the goal - to implement the desired feature, but does not understand that creating bad code does not come close, but only moves away from it.

So, the first thing that needs to be done to combat the “dumps” is to introduce regular code inspections .

If you have an experienced specialist in your team who understands the “spirit and letter” of good architecture, proper decomposition, transparent code and other good tone rules, then the first inspections should be entrusted to him.

At the same time, both he, as a performer, and you, as a manager, need to understand that the purpose of inspections is not to arrange a dressing out for a careless coder, but to teach him to write correctly and “infect” with his love for beautiful (no frills!) Code and architecture.

If your team consists of beginners and there is no such specialist, you will have to educate him yourself.

Improving the code is best to start with the separation of large (sometimes just huge) methods into small and neat. Usually it is enough to ask the programmer what this or that piece does step by step and put these steps into separate methods. Then it is necessary to divide each of the methods according to the same scheme (there is such a word - recursion) until the meaning of each is simple and clear. I plan to describe this recursive approach in more detail in one of the following articles.

In addition, you can easily set the rule "do not write methods more than 20 lines long" and check it on inspections. The programmer will be forced to reflect on how to divide his “dump” in order not to violate the established “standards”. Of course, this rule, like any others, should not be regarded as dogma. I can easily imagine a method for describing which will have to be used much more than 20 lines. But, in any case, the programmer will think about it, making the process of writing code more meaningful.

In fact, thinking about it is already a very big and often decisive step on the path to quality code.

Then, using the same scheme, you can teach a programmer to divide one class into several classes, organizing the latter in the form of layers and modules, and so on.

But that's another story. But now the programmer looks at you in surprise and does not understand why his wonderful method, which took two days of work and which “makes everything work” you suddenly did not like.

Explain to him!