Pair programming
Материал из AgileWiki
Содержание |
Статьи
How to Pair Program
Pair programming is a method of programming in which two people work together at one keyboard. One person, "the driver", types at the keyboard. The other person, "the observer" (or "navigator") reviews each line of code as it is typed, checking for errors and thinking about the overall design.
Some benefits you can expect: better code (simpler design, fewer bugs, more maintainable), higher morale (more fun!), shared knowledge throughout your team (both specific knowledge of your codebase and general programming knowledge), better time management, higher productivity.
1. Start with a reasonably well-defined task before you sit down. The task should be something you are confident that you can complete in an hour or two. For example, "Add 'maintenance history' to the moving-van database code."
2. Agree on one tiny goal at a time: something you can complete within a few minutes. Stating the problem in words to another person helps focus your mind and helps engage your partner's mind. It also ensures that you both know what you are working on right now.
3. Rely on your partner, support your partner.
- When you're the driver, complete the current tiny goal as quickly as you can, ignoring larger issues. Trust the observer to be your safety net.
- When you're the observer, read the code that the driver is writing as he or she writes it. Your job is code review. You should pay total attention, aiming to let nothing get by you. Think about possible bugs, larger issues, and ways to simplify or improve the design. Bring up errors and code that you find unreadable right away. Wait until the current tiny goal is done to bring up larger issues and ideas for design improvement. Jot these later tasks down so the driver can stay focused on the present tiny task. For example, if you see that the current code fails to account for a null input, write down on a piece of paper, "Add unit test for null input."
- When you're the observer, don't dictate the code. The driver should be actively thinking about how to achieve the current task, not just typing passively. And as the observer, you should exploit the fact that you don't need to invent the small details; you can and should think at a higher level. Saying "That looks right. How about handling the case where we're past a null pointer now?" is better than "OK, now type 'if (s == NULL) { return ...'"
4. Talk a lot! Say what you are about to do, ask for an implementation idea, ask for a better way to solve the problem at hand, bring up alternative ideas, point out possible inputs that the code doesn't cover, suggest clearer names for variables and subroutines, suggest ways to implement the code in smaller steps, tell the driver that little bit of API knowledge that they need right at the moment they need it, etc. Listen a lot, too, of course. When people are pairing well, they are talking back and forth almost non-stop. Here are some common things to say while pairing:
- "Do you think this is a valid test?"
- "Does that look correct to you?"
- "What's next?"
- "Trust me" (when it's easier to write a little code to make your point than to say it out loud)
5. Sync up frequently. As you are working together, you will find yourself getting out of sync: becoming unsure what your partner is doing, or becoming unclear about the current task. This is normal. When it happens, sync up again. The key to good pairing is to sync up very frequently—within seconds or a minute of noticing that you're out of sync. If you are spending five minutes (or more) out of sync, you might as well be coding solo, because it's the frequent re-sync'ing that creates the synergy of pairing.
- When you can, say what you are about to do before you do it. Better yet, ask your partner; for example, "Shall we write the test for the null case now?" Sometimes, though, you have to write code in order to understand your thought, and that's okay. Then you can say you are doing that: "I need to type this to see if it's a good idea." Best to keep that kind of exploration to less than a minute, though.
- When your partner asks if you agree with something, like "Shall we write the test for the null case now?" or "I think this method can be deleted now. Do you agree?", say "Yes" or "No" clearly and immediately.
- It's okay to pass the keyboard back and forth very frequently. For example, sometimes it's much easier to "say" something by typing it in code than by trying to explain it out loud. So let the observer grab the keyboard and type. Then you can switch back, or let the observer keep driving, whichever makes more sense right then.
6. Take a moment to celebrate as you complete tasks and overcome problems. For example, each time you get a test to pass, give each other a little high five. If you also high-five each time you get a new test to fail, you'll really get into the groove of collaborative programming and test-driven design.
7. Switch roles often—at least every half hour. This keeps you both fully engaged, both of you in tune with the low-level details and the big picture. Also, driving full-blast can tire you out, and it's hard to maintain the vigilance required of the observer role for longer than half an hour. Switching roles recharges you.
Tips
- Be especially courteous. For example, when your partner points out an error, say, "Thank you." When pointing out an error, do so gently, to avoid offending egos. Errors and correcting them are a normal part of programming, not evidence that someone lacks ability. As the observer, let the driver finish writing a complete line of code before pointing out an error. Most people find it annoying to be corrected as they type, but helpful to be corrected when they're finished typing.
- Write a unit test first, before you write the implementation (if the code is unit-testable). The unit test helps define the next tiny goal in a way that you both understand, since you can both see the code. The next tiny goal becomes, "Make this test pass." Test-driven development can be tough to learn at first, but pairing with someone who's already accustomed to it can teach the skill pretty quickly.
- The difference between okay/poor pairing and wonderful pairing is simply this: Pay attention. Look at the screen as the driver types. When your partner speaks, listen. Don't eat cereal. Don't check your email. Don't check digg. Let no detail get past you. When you pay attention, talk, and listen, you effortlessly become engrossed in the work, and you enter the joyful "flow" of pairing. This is when your productivity skyrockets. If one or both of you is mentally checking out, then the pairing basically sucks and you might as well work solo.
- If you have a lifelong habit of mentally checking out when other people are talking to you, or always multitasking between 5 different things, try putting 100% of your attention on the task at hand as a one-day experiment. See for yourself if you enjoy it and like the results you get. You might mentally check out repeatedly, just out of habit. If that happens, your pair can gently remind you of the current task each time. Getting focused can be much easier with a pair than alone.
- Sit at a table where you can easily pass the keyboard between you to switch roles. A plain ol' rectangular table works best (as opposed to weird, curvy, "ergonomic" furniture).
- If you're technologically übersavvy, try using two keyboards and two mice. "Switching" between drivers becomes much easier. This is accomplished with a device called a KVM Switch, which you plug the keyboards and mice into, and run the wires to the computer. The switch is as easy as turning a knob. A second monitor can be added just as easily, and some may not support a monitor (although the "V" stands for video) and may be ideal if your needs are less.
- Laptop computers are less than ideal due to the small size and difficulty seeing the screen from an angle, but you can still pair at a laptop. One trick is to have the observer sit somewhat behind the driver rather than to the side.
- Don't argue about either architectural matters or trivial matters like how far to indent the braces. These things should be decided on before you pair.
- The person who knows less about the system or language should do most of the driving, to ensure that the novice stays engaged. You learn more through your fingers than through your eyes.
Warning
If pairing an expert with a novice, the expert should be prepared to play the role of mentor, otherwise the pairing will not be harmonious.
Related links
- How to Write Readable Code Without Comments
- How to Practice Nonviolent Communication
- How to Improve your Skills as a Programmer
- How to Program Using Gnu Emacs
- How to Toggle Html Display With Javascript
Sources and Citations
- Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. ISBN 0-201-74576-3.
- Williams, Laurie (2001). "Integrating Pair Programming into a Software Development Process", 14th Conference on Software Engineering Education and Training.
Источник: http://www.wikihow.com/Pair-Program
For Writing Software, a Buddy System
Hashrocket tries to catch mistakes as they are made by pairing two workers, like Desi McAdam and Jim Remsik: one to code and one to critique.
By PATRICIA R. OLSEN Published: September 19, 2009
I’M a programmer at Hashrocket, a Web development firm in Florida. Our style of working is called pair programming, which has been popular for years in some software design companies. Two of us sit side by side at a computer workstation to develop a program that is the backbone of an interactive Web site.
One person does the actual writing, or coding, and the other person checks it, corrects it and offers suggestions as it’s being written. Programmers, or software developers, refer to these roles as driver and navigator.
It might sound as if the person writing the programming code would find it distracting to work this way, but it’s not. It’s a collaborative effort, and that’s the beauty of it. Proponents believe it saves a company time and money. Bugs can be found more quickly, and the code is written more efficiently when two people create it simultaneously. In this case, two heads are definitely better than one.
Consider the game “Where’s Waldo,” in which a cartoon character is hidden in an intricate design. Most people can eventually find Waldo after poring over the drawing. Similarly, when programmers check code for errors, it takes time to examine the logic and find mistakes.
Now imagine if someone sat next to the artist from the very beginning. Obviously, the onlooker should be able to find Waldo more easily. The character would stand out. In the same way, one programmer looking for errors in code as another writes it can follow the logic in real time. Ideally, the navigator immediately catches anything that is incorrect. My colleagues agree with this analogy.
Part of our job is to attend design meetings with new clients so we understand what they want, but when we’re developing software programs we work in pairs 100 percent of the time. Teams are assigned at our daily 9 a.m. meeting.
We try to work together at least one full day and we often spend several days together. We switch roles, too, and we constantly change partners, which is called promiscuous pairing. People have different talents, and this way the expertise is spread around.
To me, pair programming is the only way to work. Writing code is not only scientific, it’s also a creative process. I get writer’s block sometimes. To be able to collaborate with someone is great.
When senior and junior developers are paired, junior programmers might feel intimidated. If this happens, the junior programmer might be asked to start as the driver, which may encourage the senior person to become a better teacher. It’s also a way to bring junior programmers up to speed quickly, because they benefit from the more senior employee’s knowledge.
When programmers interview for a job here, we ask that they spend a week with us, and we pair them with as many people as possible. Besides checking their skill level, we want to see if we could all work side by side with them for weeks at a time and if they’re a fit with the company. It gives them a chance to check us out, too.
Our programmers exhibit idiosyncrasies that might be found in any workplace, such as one person leaving a work area messy, and the germaphobe who disinfects everything. On certain days, people may not be the best partners, like the day I was preoccupied because my dog was at the vet. If that occurs, the other person can usually snap their partner back to center line.
People working so close have occasional personal conflicts, too. Hashrocket provides our workspace, office furniture, mouse pads and anything else we need, but we use our own laptops.
Once two of our programmers had a falling out over a keyboard function. The navigator wanted to remap the caps lock key as a control key for when they switched roles. But it was the driver’s laptop, and he didn’t like that idea. When the driver went to the restroom, the navigator changed the key anyway, and the two had a disagreement. They came to terms when the navigator agreed that the person who owns the laptop gets to decide the computer key function.
The ability to pair program all the time was a selling point for my taking this job. Previously, I worked for an I.T. group at a government agency in another state. I tried to get buy-in for pair programming there, but we were allowed to do it only occasionally because of the perceived drawbacks. State governments have tight budgets, so it was a hard sell. Some people can’t believe it saves money for two people to do a job one person can do.
THIS style of programming all day every day is exhausting, but it makes me more disciplined. It’s easy for a programmer working alone to give in to distractions — to check e-mail, Twitter or Facebook, for example — when confronted with a problem. We’re on social media a lot anyway, because we need to stay current, but many people take five-minute breaks every half hour, and that’s the recommended time for accessing Twitter or the Internet.
That schedule of working 25 minutes and then taking a 5-minute break is a time management technique called Pomodoro, which means “tomato” in Italian. Every once in a while a programmer won’t stop after 25 minutes and we’ll hear someone say, “Respect the tomato.”
As told to Patricia R. Olsen.
Original: http://www.nytimes.com/2009/09/20/jobs/20pre.html?_r=2
