Geekly Articles each Day
📜 ⬆️ ⬇️

Extreme Programming: Pair Programming



Pair programming is one of the XP practices. This practice embodies the extreme (exaggerated) idea of ​​the Code Review. If the review allows you to improve the quality of the code, then let's do it all the time while refactoring and writing new code.

The problem with the usual Code Review is that programmers give very superficial feedback when they just look at your code. But as soon as they begin to work with him, this is when real feedback arrives in all subtle places and shortcomings.

How to do it?


When paired programming, two people sit shoulder to shoulder at the same computer. One of them is a “driver”, he has a keyboard and a mouse in his hands. The second makes a permanent review of the code of the first to identify tactical and strategic flaws in the code, including errors in syntax, program logic, typos and implementations that are not suitable for the existing system design. After a certain time, programmers change roles or change pairs.
')

Research


The biggest skepticism is the question: Is it not going to be a slower development when two programmers are engaged in the same task?

Studies show that working in pairs does either as fast as one by one, or slightly (15%) more slowly . But the code is much better, it contains less errors (60%) and technical debts .

The results of the research below are very similar to my observations in everyday work. Besides, as a teacher at SUSU, I started giving pair programming from the very beginning of my course. My results will be at the end of the school year, but for now a selection of public studies on the topic:


Bonuses from pair programming
  1. Exchange of experience: Often, sitting in a pair you will learn about a couple of new hot keys, interesting utilities for speeding up work. In any case, watching how others program you are constantly learning yourself.
  2. Knowledge of the system: The constant change of pairs contributes to the dissemination of knowledge about different parts of the system within the team. This makes it possible to understand how the system is developing, to improve the design of the system, not to duplicate the logic.
  3. Collective ownership of code: When everyone is involved in writing all parts of the system, there is no question of personal ownership of the class or assembly.
  4. Mentoring: We all once started programming. As practice has shown, the simplest injection into a project occurs in the process of pair programming.
  5. More communication: Communication within the team helps build trust. Stand-ups and retrospectives are added to the communication in everyday work, but this does not compare with the possibilities of pair programming.
  6. Coding standards: Sitting in pairs, constantly passing the keyboard and changing pairs, programmers spread knowledge about what coding standards are adopted on the project. You no longer need to fasten automatic tools to check the quality of the code.
  7. Improving discipline: Sitting in a pair, I want to show my interest and the level of training for a partner. And it is quite difficult to temporarily switch to social. Network to browse the latest funny pictures.
  8. Thread pairing: One programmer asks another “What are we solving now?” And they both begin to dive into the task. Such an approach can lead to the conjugation of the flow state , which increases productivity by several times.
  9. Less interruptions: In a pair, you have to be less interrupted by external factors, because time of two people is more valuable than one, their work becomes 2 times more expensive.


Anti-patterns


Pair programming can be much more interesting and fun than programming alone if done correctly. Conversely, it can be terrible and boring compared to working alone, if done incorrectly.

According to my observations, people program in a pair correctly very rarely. Most pair programming attempts are ruined by one of the anti-patterns listed below.
  1. Watch the Master: This happens when there is a programmer in a couple who considers (or even is) a guru in his field. Questions from a less experienced developer about the code that is generated by the wizard do not receive an answer. It is possible that it is constantly sent to read to Google . The master is in no hurry to give the keyboard to his partner, and when he gets to it, the master loses all interest in the process.
  2. Dictator: One of the developers in a pair always takes a tough ultimatum position regarding all decisions that concern current tasks. In such a situation, there can be no talk of mutual help or training as a couple.
  3. Get some coffee: A couple sit at the computer. One of the developers takes the keyboard and starts writing code. He says to his partner: "As long as I write the code, you go and pour us coffee." This violates the basic idea of ​​the mutual involvement of programmers in the process.
  4. Silent partners: Partners do not communicate with each other and do not comment on their actions and decisions in the course of work. In the absence of feedback, the meaning of the pair is lost.
  5. Separation of tasks at the same table: Programmers sit in a pair, take two computers at the same table (desktop and laptop) and begin to work in parallel.
  6. It is inconvenient to sit: The most common cause of fatigue when working in pairs is the inconvenient position of the keyboard and monitor for who is now a “driver”. When a keyboard moves from one programmer to another, the one who received it does not move to the center of the table, but bends down to the keyboard, thereby creating difficulties for itself during work.
  7. A partner is busy with his business: One of the partners, while working in a couple, moves away from the place of work, checks his mail, etc.
  8. Own environment settings: Every time management changes from one partner to another, the environment is reconfigured: bookmarks, font, etc.
  9. Own style: Each of the partners adheres to its coding standards, which causes heated discussions and badly formatted code.


How to fix?

If you notice a couple of programmers who work on these anti-patterns, then give them feedback and point out the error. Practice shows that working in pairs can quite easily be established by an outside observer.

Limits of applicability


In actual practice, the use of pair programming is obtained about 20% of the time , and not all the time, as it may seem from the spirit of XP. Of course, this percentage is approximate and depends on the project, but in general it does not reach 100%. Still, sometimes you just want to sit back and meditate on the code, think about the beautiful and give birth to the idea of ​​how to make this code even better.

The fact is that there are tasks that do not make sense in a pair:
  1. Research tasks: When you need to do research, googling up and chatting with experts on the current problem.
  2. Rutina: When the next steps are absolutely obvious, working in pairs can become too boring.
  3. It is necessary to parallelize: If there are two completely different tasks and deadlines are tightened, then it is logical not to sit in a pair, but to do each one's own task.


It is necessary to understand that pair programming gives a gain at a marathon and is almost deadly if we make short projects.

Properly perceive pair programming as a tool, not a panacea for all problems. Try this practice to understand in which situations it is useful, and in which you can do without it.



Links

ExtremeProgramming.org: Pair Programming

Pair Programming vs. Code Reviews

Pair Programming Benefits

Revision code will save your soul

All I Really Kindergarten

Pair Programming Benefits: Two Heads Are Better than One

Pair Programming: The disadvantages of 100% pairing

Source: https://habr.com/ru/post/151563/

More articles:


All Articles