The perfect programmer. Part 2

This is the second part of an article on the book Robert Martin "The Perfect Programmer" . In the first part of the article, we began to study how the ideal programmer differs from the non-ideal one. We considered responsibility, learned to say “no” to unrealistic tasks and say “yes” so that the customer was sure that everything would be ready on time. We decided on how to write code, accept help and help others. We continue.

7. Development through testing

About TDD say a lot of different things, for example, here's an article on Habré . Robert Martin, however, says that this technique is very good.

Short working cycle . The shorter the time interval from writing the code to its launch, the more productive your work is. You can run the code every hour (long), or you can every couple of minutes (great!). Auto tests contribute to an increase in speed. Posted by → launched tests.
')
Three laws TDD:

1. Working code is written only after a unit test is written that fails.
2. You write exactly the amount of unit test code that is needed so that this test does not pass (does not compile = does not pass).
3. You write exactly the amount of working code that is needed to pass a unit test, which currently does not pass.

Benefits:

1. Are you sure of the written code
2. Less bugs
3. You make the bolder changes. When all the code is covered with tests, refactoring is done painlessly.
4. Tests are excellent documentation. Your tests are great examples of using code.
5. Good architecture. Only well isolated and loosely coupled code is testable. With TDD, you no longer write a method that calls another method, which calls another method that calls another method.

8. Training

If we do not develop, then we are degrading. Musicians play scales, F.G. The angles in his book "The Heart of the Surgeon" (http://fb2bookdownload.ru/modern-prose/213-serdce-hirurga.html) tells how he has been training all his life (and he lived for 104 years) in stitching. Lawyers train speech, the military participate in exercises. And what about programmers? Do they need to train too?

The pianist does not think about how to press the keys: he thinks about music, i.e. his thoughts are at a higher level. We don’t think about how to click on the keyboard: the fingers themselves type the text, while the brain works at a higher level: it thinks about the article or about the code. It would be nice if we don’t think about trivial programming tasks: data types, basic code constructions and patterns, and instead we’ll think about the client’s business. Practice to improve programming.

Kata You train to implement a specific algorithm (for example, quick sort). You do not solve the problem, but train in performing the actions necessary for the solution. This helps to remember the hot keys, to fix in the subconscious of the task-to-solution pair.

Waza This is work with a partner. You choose kata for training and are divided into roles: one writes a solution, and the other unit tests. Then change. If you took a new kata, which was not taken before, the game becomes competitive and interesting. A partner who writes tests affects the decision: sets limits and evaluation criteria.

Randori . Going group. On the general screen, the first participant writes a test. The next participant writes the test and the next test. And so on in a circle. This technique helps to find out how other people approach solving problems, broadens the mind and improves their skills.

9. Acceptance Testing

Requirements will always be inaccuracies and changes. The customer will change the decision, and the performer will change the implementation. The contractor will think out for the customer and misinterpret his words. I personally saw three major projects that died for this reason. But there is a solution: enter the exact and understandable acceptance tests.

Different people have a completely different understanding of the word "do." At our enterprise, it is customary to use this ; when done, it means to make and pass. However, not everyone accepts this definition. I have seen cases when the developer coded something and decided that he did. It seems that the formal requirements are met, however, the customer is not satisfied. This is a freelance approach to life.

Acceptance testing with rigorous algorithms will solve the problem. This is TDD, only at a higher level. You write the test in any language (it is possible in Russian) and coordinate it with the customer. The task should be covered by acceptance tests at 100%. The author of the book writes that these tests should be clear to the customer and automated. Personally, I do not know how to do this at an early stage: you can write unit tests, but they are not understandable to the customer. And you can write tests in Selenium, but this is a later stage. If anyone shares recipes for .NET, I will be grateful.

What if the test is written incorrectly? You are a developer and you have brains. With their help, you can see errors in the acceptance test. The “do as it is written” position is the worst thing you can think of: you will make it worse for yourself and people, therefore the only way to correct the situation is to talk with the test developer.

The interface will change. To change the interface did not break the selenium tests, think about it during development. Use id elements for testing (ok_button, select_tour) or BEM notation.

Continuous integration. Make sure that the tests run themselves after each push to the repository. If suddenly you received a notification that the tests turned red, the work of the whole group should stop. This is a very important point that came from lean manufacturing: you will see this technique at the Toyota or Tesla plant. If a quality defect is detected in the quality control, the entire conveyor stops and the search for a problem begins. Machines are reset or repaired and the process starts further. The cost of mistakes is too high to ignore.

10. Testing strategies

Testers should not confront developers. Although it seems that their roles are antagonistic, such opposition is counterproductive. It is good when the tester helps the developer with all his might: he looks for bugs and describes them so that the developer can understand as quickly as possible what is the matter, how to reproduce and how to fix it.
The author describes the test automation pyramid.



We all know about unit tests, and a little more about the rest.

Component tests test a separate piece of the system. Analysts describe business rules just at the component level, and component tests become acceptance tests for business rules. Example: testing the patient search system.

Integration tests test the interaction between components. Example: “How will the search by patient work if the patient storage module fails?” Or “how will the bundle of invoice storage module work with the payment module, if the external acquiring stopped giving currency?”

System tests are the ultimate case of integration tests. Typically, these are performance and throughput tests. They check not the behavior of the system, but its construction.

Research tests are not automated. This is the case when we go through the system and look for where and what can be broken. We are looking for unexpected behavior and confirm the expected.

11. Planning

Robert Martin writes about his routine. He says that he gets up at 5 am, rides a bicycle to the office, writes the schedule of the working day on the blackboard. The schedule divides into 15-minute intervals, leaving 15 minutes for distractions every hour. After 3:00 pm the chaos reaches its climax and further planning is meaningless: there is a raking of the accumulated cases.

It turns out, the author uses the buffer, which is described in the article “ Make Tomorrow ”. Such a scheme can give failures, but in general, allows you to restore order in working time.

Meetings are evil and only sometimes good.

When I worked in the largest transport company in the country, I understood what a lot of meetings meant. Meetings are held there for any reason and for no reason. Coordination of the page layout of the promotional site is a meeting of five people, each of whom will bring together a mini-meeting after the meeting. In order to transfer some data from the external part of the site to the accounting system, you need not one meeting, but five. It is insanely exhausting and serves as a reason for dismissal.

The author writes that in the United States the meeting costs $ 200 per hour for each participant (salary, bonuses, premises). I figured it turned out that in Russia it is much cheaper: ≈ 13 dollars per hour for each. But still a little expensive.

Cancellation and departure from the meeting
You can refuse to participate. If the meeting is useless, does not carry benefits for your current project, does not pay off in the future - boldly refuse. A normal leader will protect your right to refuse: for him, your time is as valuable as it is for you.

If you came to the meeting, and it is delayed or it is useless, specify whether you are really needed, whether it is possible to change the agenda and discuss important issues for your participation immediately. If this does not help, choose the right moment and leave the room.

Agenda
I do not attend meetings without an agenda. It eats up your time and does not bear any useful effect. When you are invited to a meeting, clarify its purpose and agenda. If they tell me that “discuss current issues,” I say this: “For a meeting, you need a goal and an agenda. Let's clarify these things and make a meeting if it is really required. ” Most often, the agenda is not formed and such meetings are held without me. Well, thank God.

Five minutes - good
This is part of a flexible methodology and without it anywhere. Each participant in turn says:

1. What did I do yesterday?
2. What will I do today?
3. What difficulties do I have to solve?

It is fast and does not take much time. However, there are companies in which a five-minute turns into a forty-minute minute. So do not need to.

12. Concentration

Manu concentration is easy to lose, although it is very necessary. We have creative work and without concentration we have nowhere. There are several important things to maintain concentration.

Normal night sleep. Manage your sleep time so that you get enough sleep and have maximum performance during the day. Too much, too, do not need to sleep. Take an example from the greats .

Caffeine . The author writes that it is possible to absorb moderate doses of caffeine, but calls for caution. I disagree with him and I attribute coffee and tea to intoxication, which is better not to use. On this occasion, there is a book " Useful bad habit ." I did not read it myself, but here is the summary .

Exercise . The body needs exercise. Chase blood and lymph by riding a bicycle or crouching 20 times in the office. I measure time with tomatoes and, in pauses, crouch, wring out, do “Surya Namaskar”.

Input and output . In order for something good to come out of you, it is necessary that something good come into you. Stimulate their own creativity helps someone else's creativity. Well suited science fiction.

13. Evasion from work

Priority inversion
Several times I have noticed such a thing with me: there is a task with first priority, however, I don’t like it, and I’m looking for any excuse to do something else. When I was small, I was somehow given the task of updating test scripts of an almost dead system. This task was so uninteresting for me that I found any reason to distract myself. This behavior is called priority inversion: for less important tasks, we assign the highest priority. For professionals, this behavior is not suitable. We must solve problems in order of priority, and not according to personal preferences.

A dead end is when you make a decision, but it turns out to be not very good and the farther you go, the worse. You need to let go of the cactus. They say that if you are in a hole, first of all, stop digging. Take courage and abandon the dead-end branch. Admit that you were wrong, listen to alternative opinions and retreat. By the way, courage is also needed to retreat.

Dirt in the code reduces performance to zero. We all want to write clean perfect code. However, the time comes and the customer comes to us with changed requirements. Here you have two options: go back and change the architecture or fasten a crutch. Crutches in the code have the habit of breeding very quickly. As soon as you screwed the first, - wait for the second, third and twentieth. So a system is born that cannot be maintained and, after you leave, those who come to your place will say: “This is complete shit. Here you need to rewrite everything. ” So your project inevitably goes to failure .

14. Evaluation

Business considers valuation an obligation, and the developer an assumption. This is a fundamental difference. I hope everyone understands how the commitment differs from the assumption. The manager will always seek commitment from the developer:

- Will you make the transition to ESB in two weeks?
“We can, but I think I need three weeks.” I have never worked with tires.
- Then we write three weeks?
- No, it may take 10-11 weeks, if our partners can not quickly restructure themselves to the ESB.
The author of the book writes that the PERT method can be used for evaluation and three evaluations are optimistic, nominal and pessimistic.

Optimistic assessment is given as optimistic as possible. This is the case when everything goes perfectly and there are no problems. The probability is low, but it must be taken into account. A nominal rating is a standard situation where everything goes more or less well. There are some expected difficulties. A pessimistic assessment is when everything goes bad: the partners do not understand what we want from them, the tech support answers for a long time, the bus loses packages, and there is no documentation in your native Arabic language.

Often, to assess your task is not enough just your opinion. Well, when the task will appreciate someone else. The author proposes to assemble a group of experts and discuss the problem until an agreement is reached in its assessment. Methods of voting are many: from verbal expression of will to the distribution of tasks by time on the board.

Read the original book: there are given formulas and mathematics, which is not in the article.

15. Work under pressure

If you work under pressure, this is most likely unproductive. When they shout at you, they demand something all the time, they beat their fists on the table, they blush, turn green and lose prizes - this is not the best incentive to work.

In my work, such situations do not occur. However, the author writes that it was so with him.
It is best to avoid situations that cause pressure, do not take obligations under pressure and do not make dirt in the code. It so happens that a business accepts obligations for you, but you are not at all obliged to take responsibility for these obligations: let it rest with the one who accepted them.

Another manager can say: “We need an urgent, urgent, so now we don’t need to write tests. Then we finish. Do not get fooled and defend your point of view. Even in crisis situations, you need to apply TDD or TLD, but in no case do not refuse testing. This will result in big problems in the future.

16. Programmers

I will retell the rest of the book in brief theses without detailed transcripts.

• Programmers do not like working with people. That is why they and programmers: they prefer to work with predictable machines than with unpredictable people.
• The programmer accepts the rules of the employer. If the programmer does not accept the rules, he leaves or is dismissed.
• The programmer writes the code that belongs to the team. Any other team member can make changes to your code and you can make changes to someone else's code. This imposes responsibility for the way you write.
• Programmers work in pairs. If not always, then at least sometimes. Sometimes it is very useful to spy on how someone works. Single programmers instead of pair programming watching screencasts.
• Programmers work in groups. And good groups are not formed immediately. The adjustment process can take half a year or even a year. It is better to give the project to the group than to temporarily form a group for the project, and then disband and redistribute.
• The programmer has mentors. Best of all, if it is living people. But perhaps they are authors of books, articles, blogs, and video tutorials. Almost all of our knowledge, we get a parampara and only sometimes we invent something ourselves and often invent a bicycle.
• Programmers use modern tools. Use a source code management system, problem statement, continuous build, testing tools.

Conclusion

The book turned my understanding of professionalism and gave an understanding of where to strive. Someone in the comments to the first part writes that all this is written about the spherical programmer in a vacuum. But take a look at the title of the article. It says "perfect", so what is described here is what you need to go to. Start with two or three points and constantly return to the book, remembering what else you can improve.
I wish you happiness!

Illustrations by Alexander Kornilov

← The first part of the article