The key to happiness or quality is included. The cry of the soul of the programmer

This time we will talk about unit tests and code inspections. When we in our team started using these two practices in our projects, the drive and the joys of work increased by an order of magnitude. These topics are devoted to a huge number of theoretical and practical works, but today we will focus on the personal benefit of the developer.

How much time do we all spend at work? As an ordinary person, I spend about a third of my life in the office. And if we add the time we devote to our thoughts about work: at home or on vacation, over a beer with friends or on a picnic with a kebab? ..

When was the last time we asked ourselves:
- What do I feel when I go to work? Depression and depression or joy and inspiration?
- Do I like what I do? and the way I do it?
- What do I feel when I leave work? Satisfaction and appeasement or relief and exhaustion?
- Do I go to work out of habit or do I like it?
')
It is obvious that everyone wants to live a full and harmonious life, filled with joy, satisfaction, a sense of their own usefulness and strength, with a sense of self-esteem. Do we live such a life here and now or postpone it for later?

Not broke - do not fix it!

At one of the previous jobs I happened to take part in a project that was already more than 10 years old. There were no traces of unit tests at all, inspections of the code were not carried out, each developer was responsible for his own piece of code (the so-called personal possession of the code). The situation was also worsened by the lack of a common coding style on the project, to the extent that spaces were used for indentation somewhere, and somewhere else were tabs. At that time, I personally knew nothing about unit tests and code inspections.

Have you ever existed in such a project? What are the memories? Can someone survive in such a project right now? B-rr ...

In general, our project was a breeding ground for bugs. The motto of the project was: not broken - do not fix it; nothing needs to be improved. But what about the inner quality? You can say for sure - the internal quality of the project has only deteriorated every day. Neither of which refactoring was out of the question. Weak attempts to conduct a small analysis with the subsequent correction of the most critical jambs ended in the generation of new, and sometimes tricky, bugs. Do you know this situation?

It is not surprising that I spent 80% of my time on patching holes and understanding the intricate logic of the code. My work has become an endless routine and dullness. Day after day, sheer hopeless longing.

Can you call such a project alive? Fear of change turned him into a real dead man. How to enjoy working in such a situation? The spark disappeared from the project, it moved to the “survival” stage ... And what stage did the people on this project move to?

Pleasant feeling of busyness

With all this, team members worked very intensively. But does intensity necessarily mean efficiency? How much energy and strength goes to the treatment of bugs, the understanding of bad code? Is it not depressing to waste time and energy on unnecessary work?

But what about personal pride - pride in what you do? At that time, the sensations were depressing: "Sorry, it so happened that I did it."

If you spend 20% of your time on useful features and project development, and 80% on treating bugs and understanding a bad code, where can you find time for self-education and self-development? ..

In general, as the saying goes: "I want to learn, yes bugs are not allowed ..."

I decided to escape from all this nightmare and went to an interview in a very well-known domestic company, familiar to everyone and everyone (hereinafter referred to as company Y). At the interview I was given a test task, which I did perfectly (you can't praise yourself - no one will praise). Further discussion began.

- How will you test it?
- Well, as ... Manually I will run the user cases.
- All by hand?
- Well, not everything is complete, only the main user scenarios, let the testers check the rest ... In the end - am I a programmer or a quality specialist? (Chukchi is not a reader, Chukchi is a writer.)
- How will you treat the defects that quality specialists and customers will find?
- Well, how-how? I will launch the debugger, find the reason, correct everything - and give testers for testing ...
- Thank you, we will call you ...

Looks like fiction? Not at all. I even remember the faces of those guys that I was interviewed :) As a result, I never worked at company Y.

What to do?

The easiest way to solve a problem is to escape. But will the exit of a company or project change? Come to a new place, and there ...



In fact, we, programmers, are not alien to many "sales" moves. Especially when it comes to the code: bad areas are covered with a fig leaf, and all attention is focused on bright and brilliant merits. Only the tip of the iceberg is visible, 20 percent, not more.

At the interview I will sing about those beautiful 10-20%, and the terrible 80-90% will try to omit. It will not take a couple of months, as everything will return to normal ... And again, the routine treatment of bugs and raking bydlokoda. Shilo on soap.

There is a great parable about this:
- Master, how long to wait for a change?
- If you wait, then a long time.

Should we count on some new result, repeating the same actions all the time? I just exist this 1/3 of my life that happens at work - or live?

Selection

What do I choose?

a) Is it interesting to live, to develop, to work inspiringly, to write elegant code?
b) Is hell at work, disgruntled customers, hard-boiled colleagues, tough bosses?



The choice, in general, is obvious. But to come to this is not so easy. To help the programmer really begin to live at work can code inspections and unit tests. Only two simple practices will set the stage for continuous improvement.

If I don’t make a choice, someone else will make it for me: a colleague, a manager, a manager, a client, who knows? Most importantly, it will be a FOREIGN choice. God forbid, if this choice is on the light side, my experience shows → 99.9% to hell :)

Start small, enter code inspections into your development process.

The first step is choosing a tool. It takes no more than a week, but what does the week mean in comparison with the third life we ​​spend reading the code? You want to get pleasure from this process, including aesthetic, isn't it?

In my experience, all changes begin with yourself. Suffice to say to yourself: “Now all my code that I upload to the repository will be checked by my colleagues.” It sounds simple, but simply - it does not mean easy ... It's like running a marathon. It would seem that he began to run - and run without stopping for 42 km. But you should put yourself in the runner's place ...

Surely there will be conflicts - because of the coding style, the algorithms used, the libraries, the techniques, the approaches, the patterns - but this is only the first couple of weeks. But each developer starts to perceive the code as his own: “I checked it, I accepted it”. The code will start to bring pleasure from working with him. Plus, I also “pump” not only in the ability to write code, but also in the skill of making critical comments.

The next step is to enter the process of developing and writing unit tests.

First of all, it would be good to choose a ready-made framework for testing, since they are already a dime a dozen ( http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks ).

Next, we set up the launch of unit tests on the server. The server is the standard of the hardware-software environment. The only criterion for accepting code and working tests is passing the tests on the server, not on the development machines. Setting up unit tests on the server will save a lot of time.

Actually, these are all actions to prepare the infrastructure. However, difficulties still lie ahead, because preparing the brain for using this practice is much more difficult.

Three of the worst blemishes of unit tests

1. Tests are run irregularly and not on the reference server . If the tests are not run on the build server (you do not have a dedicated build server yet?), Then the developers can start to gradually disable tests that fail. The result is unworkable tests, and their motivation to write falls below the baseboard. Tests "foul".

2. Major tests . Tests must be small, "elephants" are difficult to transform - they turn from helpers to torturers.

3. Testing for testing . There is no universal solution for such a situation, but the most logical thing is to simply choose a sufficient degree of test coverage for your project, to prescribe cases that are necessarily covered by tests. Someone will, in fact, be enough, and 30%, and someone needs and 70-90%. This is the choice of the team.

Life grows even on stones. Even in the most terrible project, sprouts of modular tests can sprout and code inspection can arise. It is we who sow the seeds of the quality of our life.



On an inherited project, you can start small. I don’t know about yours, but I usually have the Pareto principle flawlessly shown: 20% of the code performs 80% of the functionality. We focus our attention on the test coverage on these 20%. In their projects, applying the 20/80 principle, our team managed to reduce the number of bugs in the old code from ~ 30 per month to 2-4.

As a result, we forgot what to treat bugs, and this new feeling was inspiring. Now you can plan your work, leisure, development, life. We forgot about the processing and work on weekends. Began with peace of mind to go on vacation. I personally stopped shy away from phone calls :)

At the same time, no one changed the job or project. We just restructured the work as we want it to be. So that we want to live it.

In conclusion, a couple more questions to think about.

When will we, developers, finish blaming managers, colleagues, clients?

When will we stop postponing life? To the next project, to the next work, to the next ... what?

Everything will not be the way we want - but then when we decide.



That's all. I wish you a quality life! Thanks for attention.

Author : Alexander Pazdnikov, Positive Technologies Research and Quality Control Department.