Project manager: three steps of the team to perfect code

Preamble

Let's imagine that you were asked to head one of the areas in your company. You, of course, know all the people in the team, repeatedly crossed paths in the corridors and drank beer at corporate festivals. The previous leader was a good person, but his plans changed and he quit.

And so, you, taking the post, get acquainted with the team: there seems to be potentially strong developers with experience, there are several promising juniors. But something immediately catches the eye. And the longer you look at these smart work faces, the more you realize that this is not a team, but a “development team”. And what they write ... You never thought that programmers could write code like that. You look at the plasticine architecture , at classes in 6000 lines of code, at methods that occupy ten pages of typewritten text, at cases, branching like heads of the Lerney hydra. And you have an involuntary question: is it possible to do something with such a team at all?

And my answer is - you can. And you need!

Awareness

So where to start? We must begin with the understanding that no one ever deliberately writes badly. Most likely, the previous manager either did not follow the quality of the code of his beneficiaries at all, fully concentrating on current financial indicators and plans, or deliberately sacrificed the quality of the code to the same current financial indicators.
')
I specifically focused on the word "current." A bad code, in any case, will eventually get in the way of further product development and make its support not only a hell for customers and programmers, but also an extremely unprofitable business for the company. In this case, your firm, instead of investing in development, will be forced to invest huge sums in correcting mistakes and maintaining the life of the dying person under the weight of their own internal disgrace product. Or spend resources on writing new versions of the product, which, with the proper approach, could live for a long time and bring profit to business and the joy of the developer.

In general, in order for existing programmers to suddenly write correctly, you need either a miracle or a long hard work. Despite your optimism, I recommend choosing the second path. This path consists of three unequal steps, which I will reveal below.

Remember that Ivan Tsarevich in fairy tales, animating, was first watered with dead water and only then alive. Probably at the end he married some Vasilisa the Wise. In software development, about the same.

Step one. Hatred

This is probably the most controversial thesis of all that I will give here. They often did not agree with me (it came to the transition to personalities and offended sniffs in the corner), but its effectiveness was tested in practice.

So, at the very beginning, programmers need to instill hatred. Hatred of bad and dirty code, stupid mistakes, cases of five hundred lines and classes consisting of one method the size of a house.

How to do it? Start conducting open code inspections. Get together with the whole team once a week and let someone search for dirt and anti-patterns in the code. If you have the skills to distinguish a bad code from a good one, participate in them yourself, if not, ask someone you trust in this regard.

After several such reviews, programmers will most likely already understand what a magic button is and where to call refactoring “take out a method”. Once again: proceed from the fact that nobody likes to write bad code. Just many do not understand that he is bad.

And one more thing: do not become personal (who wrote IT ? Vasya? Vasya, how are you not ashamed? You will remain without a prize!). But do not spare bad code. I think it is perfectly normal to inquire “for what purpose this subconscious dump was filled in with the code”. Because the code is rubbish. Because programmers do not understand this until you say. It is tough, but effective.

Step two. Passion

Show programmers patterns, examples of good architecture, and beautiful code. Infect them with this. Let them rush with clever words like “factory” and “decorator”, realizing their professional competence, and their code is replete with useless strategies and defiant calling methods. Make this step easier, but it should be done about the same time as the first. Let them design, think and revel in the fact of their knowledge of the theoretical foundations of software architecture. This is only good and, by the way, very motivating.

But the main thing that needs to be realized is that in no case should we stop at this step , despite the fact that it seems very tempting and creates the feeling of working with a team of professionals.

Step three. Sanity

Now, when your programmers are able to catch the smell coming from the rotten code, and design a factory to create window interfaces of different colors, it's time to think about the main thing - realism. Explain to the guys that the design pattern is applied only in the right place and at the right time, the method may consist of more than two lines, and string constants in the text are, in general, sometimes acceptable. Explain that, first of all, you need to write a simple and transparent stable working system, and only then “a perfect architectural solution, 93% covered with design patterns”.

This is the hardest. The most difficult thing to explain is why the “subconscious dump into the code” is difficult, but no less complicated and the implementation of the factory to create constant strings for the labels to the buttons (we assume that localization is not provided). But getting rid of this is necessary. Not to take this step means to leave the programmer in an eternal certainty that he writes well and understands architecture then, as he writes a little better than before, and his architectural solutions make him clutch his head. And it is a disaster for any team.

Therefore, it is necessary to make every effort here to explain why there used to be “factory is good,” and now “factory is bad.” But I'm sure they will pay off in full.

A couple of words in conclusion

Well, actually, that's all. I can only say from my own experience that “hatred” and “passion” are imparted in about six months, and sometimes it takes more than two years to bring “Sanity” to the step, and it comes with experience. And get ready that your "current financial indicators" are likely to shed for a while. But the team received in return, able to create a light, neat code, suitable for long-term support and expansion, in my opinion, is worth the investment.