📄 programminginpairs.html
字号:
<head><title>Programming In Pairs</title></head><body><h1><img src="logo.gif"> Programming In Pairs</h1>This page could use a <a href="http://c2.com/cgi/wiki?ReFactoring">ReFactoring</a>
<hr>
<em>(See also <a href="http://c2.com/cgi/wiki?PairProgrammingMisconceptions">PairProgrammingMisconceptions</a> and the <a href="PairProgramming.html">PairProgramming</a> mail list.)</em>
<p>This was called "Programming In Pairs" in its first published description (by <a href="http://c2.com/cgi/wiki?JimCoplien">JimCoplien</a>; see <strong>Historical Note</strong> below). It's more commonly called <a href="PairProgramming.html">PairProgramming</a> these days, notably by the <a href="ExtremeProgramming.html">ExtremeProgramming</a> community.
<p><strong>Context:</strong> You have several people working on a project. Everyone's received the basic training necessary to do the job. Some are (inevitably) more or less experienced than others. You have <a href="http://c2.com/cgi/wiki?PairProgrammingFacilities">PairProgrammingFacilities</a>.
<p><strong>Forces:</strong> You want to get more done than your most productive person can do. You want your less experienced people to learn from your more experienced people. You want to structure your organization to avoid needing "n squared" communications channels.
<p><strong>Therefore:</strong> Pair up your people. When applicable, each pair should have a relatively experienced and a relatively inexperienced person. For work being done at a computer, put the relatively inexperienced person at the keyboard, so everything the experienced person says has to flow through the novice to the computer. The point is not for the guru to dictate to the greenhorn; on the contrary, putting the novice at the keyboard is meant to keep him or her more in the loop. When (as happens occasionally) that doesn't provide enough bandwidth, the experienced person will say, "Let me drive" (that's not a prescription, that's what's frequently said), and will show something instead of teaching it at a more leisurely pace. When one member of the pair is not following what's going on, he or she can ask to drive.
<p><strong>Resulting context:</strong> The real power of this pattern comes from the variety of results it supports.
<p>This is a very effective way for a more experienced person to teach a less experienced person. Everything that's being done, and (if Programming In Pairs works) the reasons for doing it that way, are all passed through the less experienced person. The training is extremely relevant, and adapts to the needs of the "student" (and the needs of the project).
<p>Put a less experienced person together with a more experienced person, and the former will be more likely to stretch. Instead of sticking to familiar, comfortable tools and techniques, he or she will try things he or she only knows a little about, ask dumb questions ... grow. If the less experienced person doesn't volunteer to stretch, the more experienced person is likely to suggest better ways to do something, which the less experienced person wouldn't normally have been exposed to.
<p>Put two people together, and you'll get more than twice as many ways to solve a problem. Each person will have his or her own ideas (there'll be some overlap), plus some half-baked ideas he or she wouldn't normally think hard about, plus the completed ideas of the other person, plus ideas sparked by their other person's, plus ... it adds up fast.
<p>One of the tricks of people working with each other is giving them an opportunity to learn how to work with each other. Programming In Pairs supports that better than trust falls or high ropes (which still have their uses, too).
<p>Two people working together in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don't check e-mail messages or favorite Web pages; they don't waste each others time.
<p>Two people working together will have their shared time treated by others as more valuable. If I'm sitting at my computer, or just staring into space (thinking hard!), no one will think twice about interrupting me. On the other hand, if I'm busily working with someone, anyone who needs me will interrupt me briefly if at all.
<p><strong>In summary:</strong> Get two people Programming In Pairs, and they'll work more than twice as fast as one could have.
<p>(Note that none of this is peculiar to software development, though it won't apply to all fields of human endeavor.)
<p><strong>Known uses:</strong> Medical schools have a philosophy of, "See one, do one, teach one." <a href="http://c2.com/cgi/wiki?WardAndKent">WardAndKent</a> found Programming In Pairs with each other to be one of the highlights of their careers (so far). <a href="http://c2.com/cgi/wiki?PaulChisholm">PaulChisholm</a> found Programming In Pairs with <a href="http://c2.com/cgi/wiki?MichaelLindner">MichaelLindner</a> and LoAnnLindner<a href="http://c2.com/cgi/wiki?edit=LoAnnLindner">?</a> (nee Reiling) to be one of the highlights of his career (so far). (The three of them traded off Programming In Pairs, and sometimes managed to work the same pattern with three people. Result: 15K non-commentary source lines of C++ in a few months, and Paul was an usher at Mike and LoAnn<a href="http://c2.com/cgi/wiki?edit=LoAnn">?</a>'s wedding. Your mileage will likely vary!) (See also <a href="http://c2.com/cgi/wiki?ProgrammingInPairsTestimonials">ProgrammingInPairsTestimonials</a>)
<p><strong>Other patterns:</strong> When Programming In Pairs, <a href="http://c2.com/cgi/wiki?CodeOwnership">CodeOwnership</a> belongs to the pair, not to an individual, which overcomes some of that pattern's downside.
<p><strong>Historical note:</strong> <a href="http://c2.com/cgi/wiki?WardCunningham">WardCunningham</a> and <a href="http://c2.com/cgi/wiki?PaulChisholm">PaulChisholm</a> found we both "had this pattern" at Steve Fraser's 1994 OOPSLA workshop on teams and objects. During a break, we cornered <a href="http://c2.com/cgi/wiki?JimCoplien">JimCoplien</a> and effused at him that this belonged in his "organizational patterns" language.
<p>I feel bad about re-writing a pattern from scratch -- that's not hardly in keeping with the best traditions of the pattern community! -- but I've since thought a lot about it, and wanted to share my experiences with it. --<a href="http://c2.com/cgi/wiki?PaulChisholm">PaulChisholm</a>
<p><hr>
<p><a href="http://c2.com/cgi/wiki?WardAndKent">WardAndKent</a> are outspoken proponents of this style of development. The most often asked question: "Won't my management think we are wasting resources?" can be answered by explaining the many productivity improvement opportunities pair programming creates.
A better answer might be to suggest more faith in management's ability to recognize productivity when they see it. --<a href="http://c2.com/cgi/wiki?WardCunningham">WardCunningham</a>
<p><hr>
<p>Those of us who spent time training others know that this is virtually the only way to really teach someone something that involves hands-on work, which programming definitely is. -- <a href="http://c2.com/cgi/wiki?JamesClover">JamesClover</a>
<p><hr>
<p>One of the rules of the <a href="http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation">ChryslerComprehensiveCompensation</a> team is that all production code be written with a partner. As a testimonial, in the last six months before launching, the only code that caused problems was code written solo.
-- <a href="KentBeck.html">KentBeck</a>
<p><em>{<a href="RonJeffries.html">RonJeffries</a> writes this about part of <a href="http://c2.com/cgi/wiki?ExtremeSoftware">ExtremeSoftware</a> as practiced at Chrysler ... <a href="http://www.xprogramming.com/Practices/PracPairs.html">http://www.xprogramming.com/Practices/PracPairs.html</a>)</em>
<p><hr>
<p><a href="http://c2.com/cgi/wiki?JoeDavison">JoeDavison</a> kindly added to and incited me to improve my model for <a href="http://c2.com/cgi/wiki?DayCare">DayCare</a> to pick up additional factors. One is the <a href="http://c2.com/cgi/wiki?CornFieldEffect">CornFieldEffect</a>, which says experts work better together than separately (just as corn gives greater yield when grown in proximity rather than isolation). Another two are the mentoring effects - better design and faster training, which apply when the people have different amounts of expertise. To me, the additional factors for <a href="http://c2.com/cgi/wiki?DayCare">DayCare</a> provide a bit of a model to explain some of the added productivity in <a href="ProgrammingInPairs.html">ProgrammingInPairs</a>. -- <a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<hr>
<p>One of the other benefits of <a href="PairProgramming.html">PairProgramming</a> is its effect on code/design/produced object quality. It is amazing how many obvious but unnoticed defects become noticed by another person watching over your shoulder. In addition, the intimacy of this method makes it possible for defects to be exposed in a non-judgemental manner.
<p>The first time I heard of this paradigm being used in a formal, organizational sense was in <a href="http://c2.com/cgi/wiki?DeMarco">DeMarco</a> & Lister's <a href="http://c2.com/cgi/wiki?PeopleWare">PeopleWare</a>, where they mention it as a benefit and give the example of Whitesmith's (an old compiler company founded by P.J.Plaugher) as a place where it was practiced. <em>[I believe this is actually in <a href="http://c2.com/cgi/wiki?ConstantineOnPeopleware">ConstantineOnPeopleware</a>; see <a href="http://www.cs.utah.edu/~lwilliam/proposal.htm">http://www.cs.utah.edu/~lwilliam/proposal.htm</a> for a reference. --<a href="http://c2.com/cgi/wiki?PaulChisholm">PaulChisholm</a>]</em> Anything earlier? -- <a href="http://c2.com/cgi/wiki?FrankAdrian">FrankAdrian</a> [hounds are coupled together for hunting (and a pack of N hounds will be referred to as "N/2 couple"), so if you're willing to accept non-humans, the practice is at least centuries, and probably millenia, old. A fox or hare that's backtracked and crossed a stream is probably just as annoying as a bug that doesn't manifest until the stack's unwound and execution is deep in some other module...]
<p>Noel Morris and I used this approach in 1965, writing
programs for CTSS. It is mentioned in my note,
"The Evolution of My Thinking," <a href="http://www.best.com/~thvv/evolution.html">http://www.best.com/~thvv/evolution.html</a>.
-- <a href="http://c2.com/cgi/wiki?TomVanVleck">TomVanVleck</a>
<p>When people say that <a href="PairProgramming.html">PairProgramming</a> reduces productivity, I answer "that would be true if the most time consuming part of programming was typing" -- <a href="http://c2.com/cgi/wiki?MartinFowler">MartinFowler</a>
<hr>
<p>Regarding the benefits of <a href="PairProgramming.html">PairProgramming</a>, when i have the opportuntity to promote XP practices (usually to mgmt during a presentation on process), i have been presenting the following supporting argument (among others), linked to some research:
<p>1. Projects with high quality (attention to quality) have lower schedule pressure:
<UL><li> Products with the lowest defect counts have the shortest schedules (Jones 1991, Applied Software Measurement).
<li> Poor quality is the most common reasons for schedule overruns (Jones 1994, 4000 projects, Assessment and Control of Software Risks).
<p></UL>2. Higher quality comes through culture/values/process, inspection, testing, early feedback, refactoring, and so forth.
<p>3. Regarding inspection and quality and schedule, inspection is a powerful tool:
<UL><li> Inspections have been found to produce net schedule savings of 10 to 30 percent (Gilb and Graham 1993, Software Inspection).
<li> Each hour spent on inspections avoided an average of 33 hours of maintenance (Russell 1991, IEEE Software).
<li> Inspections were up to 20 times more efficient than testing (Russell 1991, IEEE Software).
<p></UL>4. <a href="PairProgramming.html">PairProgramming</a>, in part, is a way to do effective, real-time, responsive inspection, which supports higher quality, which supports reduced schedule pressure.
<p>-- <a href="http://c2.com/cgi/wiki?CraigLarman">CraigLarman</a>
<p><hr>
<p>It is sometimes useful to have <a href="http://c2.com/cgi/wiki?DivergentPair">DivergentPair</a>-s work together, to spark "creative abrasion".
-- <a href="http://c2.com/cgi/wiki?YonatSharon">YonatSharon</a>
<p><hr>
<p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -