How do you explain the single responsibility principle to a programmer?

Question

Programming

I can’t prove to my colleague in any way that it’s not good when the form class method is engaged in creating a socket, receiving data, determining the type of package, parsing the package into a structure depending on the type of package, and displaying data on the form. How do you deal with such situations? How to make a person share the responsibility of classes, abstraction? Or leave everything as it is, so that in a year they will take up their heads with shouts of “who wrote this code”?

Answer 1

I think it would be useful to approve internal standards for the design and implementation of software solutions in your company from above. Then there will be no need to prove to the militant amateurs that they are not only going to the rake themselves, but also dragging everyone else who does not share their wise approach.

Answer 2

It needs to be explained with examples. Show why division into layers is good, why it is convenient - with a specific example. Show how much more convenient it is to test separate classes into which you can make a dependency injection of a stub or mock. Yes, there are a lot of examples, so show them, preferably in relation to your specific case.
It is much easier for people to first understand concrete things and only then realize more abstract principles through them.

Answer 3

Arrange (possibly through the authorities) so that a small console utility is needed that implements some of the functionality.

Answer 4

Google articles about SOLID, make them read.

Answer 5

You can't convince someone of something if they don't want to. That's when he gets tired of looking for errors in his code or when a senior programmer yells at him that it's impossible to understand his code, that's when it's time, as it were, to say casually that the principle of single responsibility was recommended on Habré. And if the right moment does not come ... then his code is good, and this is the most important thing.

Answer 6

Lobby for the introduction of a mandatory code review in the company. Attach hooks to commits with checking code-style, dead code, commenting, method length, and other features (there are already a lot of written tools for this). A colleague simply will not have the opportunity to hand over his govnokod. If it doesn’t work out to push the idea, then the company doesn’t need it, but it needs the code that your colleague writes. Then find a better company.

Answer 7

Well, as always - the ruler

Answer 8

I doubt that anything here can help other than personal experience.
If he, as a specialist, is competent enough, you can make sure that no one intersects with his code.
Usually this means that he will do peripherals. Make and redo if needed. At the same time, sometimes let him make kernel fixes written in a good style. To feel the difference.
At the same time, I would not be in a hurry to quit. Often a specialist with such an approach does the work in good conscience. Difficult to maintain and develop, but it works. Perhaps even immediately :) If a team needs such a person, they can be used.
Otherwise, try to find the next one. For the manager, this will be another reason to practice in the selection of the team :)

Answer 9

Are you sure this is necessary? I once saw how a programmer spent three days optimizing code that was supposed to be executed ONCE. Code running time has been reduced from 10 minutes to five.
In general, there really is no way to convince a person here. Every programmer has to go through the stage “What asshole wrote this code???? Oh, it's me ... what an asshole!
If you can say: “You must write like this because I said so,” then say it.
If not, take it easy :)

Answer 10

The beautiful name SRP is just a synonym for strong cohesion - one of the two components of modularity along with low cohesion. You can shame a colleague by saying that his code is not modular. If he starts to bend towards the fact that he does not need modularity, try to resort to the argument that his code is not readable. Usually poorly understood code is more error prone than cleanly written code. This is explained as follows: a person is able to keep in memory only a limited number of objects at the same time, and only in one context. Thus, context mixing (SRP violation) leads to buggy code.
But if your colleague is stubborn, just ditch him. If he can't understand, he won't understand.

Answer 11

Invite him to voluntarily-compulsorily engage in refactoring after school hours. In voluntary - means, without payment of hours.
To enhance the effect, I recommend making this offer when the approximate (in your opinion) number of hours required approaches and / or exceeds a couple of hundred.

Answer 12

I set a condition for students: in your application, I should easily replace the molds with the console. At least in terms of separating UI and logic, this helps. And then, by the same principle, you explain about the division within the logic, and so on to (almost) infinity.