Parprogrammering

Parprogrammering er en softwareudviklingsteknik, hvor to programmører arbejder sammen ved et tastatur. Den ene skriver koden ind, og den anden reviewer hver kodelinje mens den bliver skrevet. Den person der skriver kaldes Driver. Den person der reviewer koden kaldes observer eller navigator. De to programmører skifter rolle jævnligt.

Mens observeren reviewer, overvejer observeren også den strategiske retning af arbejdet, og kommer med ideer til forbedringer og overvejer hvilke sandsynlige problemer der måtte opstå. Dette frigør driveren til at fokusere al sin opmærksomhed på de "taktiske" aspekter ved at færdiggøre den aktuelle opgave, idet observeren fungerer som en slags sikkerhedsnet og guide.

Kom i gang

Generelt

  • Sørg for at der er en veldefineret opgave før i sætter jer til at par-programmere noget der forventes at tage en time eller to at færdiggøre.[1]
  • Arbejd således at der tages en lille opgave/mål ad gangen, – noget I kan færdiggøre indenfor nogle få minutter. Bare det at formulere et problem i ord, overfor et andet menneske, hjælper med til at fokusere både dig selv og din partner på opgaven. Det sikrer også at begge ved hvad I arbejder på lige nu. Man kan trygt færdiggøre denne opgave inden man begynder på noget nyt, og er mindre fristet til at forlade opgaven for at håndtere kompleksitet der lige er dukket op. Det kan man gøre senere.
  • Som driver, stol på at observeren er dit sikkerhedsnet. Færdiggør det aktuelle lille mål så hurtigt du kan, og ignorer større og afledte problemer.
  • Som Observer, læs koden, idet driveren skriver den. Tænk på mulige bugs, større problemer og måder at forenkle eller forbedre designet. Hvis der er fejl eller ulæselig kode, skal det straks tages op. Vent til det lille delmål er opnået med at tage større aspekter op; designforbedringer, f.eks. Skriv disse større ting ned, så driveren kan holde sig fokuseret på den aktuelle opgave. Hvis du for eksempel kan se at koden ikke tager højde for et null-input, skriv en note: "Lav en unit test for null-input".
  • Skift roller hver halve time. 15 minutter er mere almindeligt.
  • Skriv en unit test først, før I implementerer kode. Dette hjælper med til at definere det næste lille mål i arbejder på. På denne måde bliver det næste lille mål: "bestå Unit-testen".

Begynder – Ekspert par sammensætning

  • Den person der ved mindst om systemet eller sproget bør være driver det meste af tiden, for at sikre at begynderen forbliver aktivt engageret.

Etikette

  • Som observer, lad driveren skrive kodelinjen færdig før du påpeger en fejl.
  • Vær høflig: For eksempel, hvis du bliver rettet, sig tak. Når du påpeger en fejl, så gør det nænsomt, og lad være med at træde på egoer.
  • Når I har færdiggjort opgaver eller løst problemer, husk at fejre det.[2]
  • Når din partner spørger om man er enig i noget som f.eks. "Skal vi skrive den der unit test nu?" eller "Jeg tror vi kan slette den her metode nu. Er du enig?", svar klart og tydeligt "Ja" eller "Nej". Klar kommunikation reducerer usikkerheden.

Praktiske forhold

  • Sid ved bord, hvor det er nemt at flytte tastaturet mellem jer for at skifte roller.
  • sørg for at være enige om basal kodestandard, så I ikke kommer til at skændes om trivialiteter.

Fordele

Nogle fordele ved Parprogrammering:

  • design kvalitet: Kortere programmer, bedre designs, færre bugs.[3] Programkoden skal være forståelig for begge parter, ikke kun Driveren, for at blive tjekket ind. Par overvejer typisk flere designalternativer end programmører der arbejder alene, og kommer frem til enklere, mere vedligeholdelsesvenlig design, og finder designfejl meget tidligt.[4]
  • Reducerede udviklingsomkostninger: Bugs er en specielt omkostningstung del af softwareudvikling, især hvis de først findes sent i udviklingsprocessen. Idet parprogrammering kraftigt reducerer fejlraten, medfører dette en dramatisk reduktion i omkostningerne ved softwareudvikling.[3]
  • Træning og videndeling: Viden deles nemt mellem parprogrammører: De deler viden om det specifikke system og de lærer programmeringsteknikker og små tricks og fif's af hinanden.[3][5] Nyansatte lærer hurtigt holdets arbejdsformer at kende gennem pararbejde.[6]
  • Løsning af svære problemer: Par oplever ofte at tilsyneladende "umulige" problemer bliver lette (eller i det mindste mulige) at løse når man arbejder sammen.[3][5]
  • forbedret moral: Programmører fortæller om større glæde ved arbejdet[7] og større tillid til at deres arbejde er korrekt.[3]
  • Reduceret risiko: Eftersom kendskabet til systemet er delt mellem mange programmører er der mindre risiko for virksomheden, hvis en enkelt programmør falder fra.[3]
  • Forbedret disciplin og bedre tidsudnyttelse: Programmører er mindre tilbøjelige til at springe over unit-tests, bruge tid på personlig email eller surfe på webbet;[8] – eller andre brud på disciplinen når de arbejde med deres partner. Partneren "Keeps them honest".[9][10]
  • Robust "Flow": Det virker som om det "Flow" der er i arbejdet bliver mere robust, og kommer hurtigere: Den ene spørger den anden: "Hvad arbejder vi på?" Flowet er også mere robust overfor afbrydelser: Den ene tager sig af afbrydelsen mens den anden arbejder videre.
  • Færre afbrydelser: Folk er mere tilbageholdende med at afbryde et par end en der arbejder alene.[11]

' Færre arbejdsstationer: Eftersom to personer bruger én arbejdsstation, spares der én.

Ulemper

  • Udviklernes egoer: Erfarne udviklere finder det måske kedeligt at skulle oplære en mindre erfaren kollega i et parsamarbejde.
  • Følelse af afsløring: En mindre erfaren udvikler kan måske føle sig afsløret eller skræmt ved udsigten til at en erfaren skal opdage ens svage sider. Dette kan resultere i svigtende engagement.
  • Personlig præference: Nogle udviklere foretrækker måske at arbejde alene, og finder det svært at håndtere pararbejde.
  • Oplærings-omkostning: Erfarne udviklere der arbejder alene kan sagtens være i stand til at producere kode der er ren og fejlfri fra starten, og den ekstra teoretiske gevinst ved pararbejde er måske ikke omkostningen ved en ekstra programmør værd.
  • Potentielle konflikter: Forskelle i kodestil kan resultere i konflikt, og personlige konflikter kan resultere i at begge udviklere føler sig akavede og utilpasse.
  • SnikSnak: Ind imellem snakker ansatte for meget om irrelevante emner, og kommer for meget ud af en tangent, f.eks. nyhederne, fælles venner, personlige problemer, etc. Andre ansatte kan føle sig foranlediget til at prøve at være charmerende eller underholdende sammen, mens de hver for sig måske ville fokusere mere på ugens milepæl... Imidlertid ved projektledere typisk hvornår gode venner risikerer at falde i fyraftensplanlægning i stedet for seriøst arbejde. Selv om det måske vil hjælpe at blive mindet om at holde fokus, så er det måske unfair at bede nære venner arbejde sammen og undgå lange snakker om deres fælles interesse.

Videnskabelige studier

Studier har vist at efter tilvænning og optræning af de personlige kompetencer der kræves, er to programmører mere end dobbelt så produktive som én, for en given opgave. Ifølge The Economist:

"Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs (N.B.: The original study showed that 'error-free' code went from 70 % to 85 %; it may be more intuitive to call this a 50 % decrease of errors, from 30 % to 15 %). Since testing and debugging are often many times more costly than initial programming, this is an impressive result." [12]

Et studie af Williams et al. 2000 viste en forbedring i korrekthed på omkring 15 %, – og 20 til 40 % besparelse på tid, men mellem 15 og 60% forøgelse i indsats. Williams et al. 2000 citerer også et tidligere studie (Nosek 1998) som også havde 40% lavere tidsforbrug for en 60 % forøgelse af arbejdsindsats.

Et studie præsenterer et streng videnskabeligt eksperiment, hvor begynder-begynder par imod begynder-soloer oplever betydelig større produktivitetsstigninger end ekspert-ekspert-par imod ekspert-soloer.[13]

Et større nyligt arbejde (Arisholm et al. 2007) viste 48% større korrekthed for komplekse systemer, uden nogen signifikant forskel i tidsforbrug, mens simple systemer havde 20 % mindre tidsforbrug, men ingen signifikant forskel i korrekthed. Der var ingen generel reduktion i tidsforbrug, eller øget kvalitet, men en generel 84 % stigning i arbejdsindsats.

Referencer

  1. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 25. ISBN 0-201-74576-3."When pairing is working at its best, … both share the same goal for completing the task."
  2. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 25. ISBN 0-201-74576-3."When pairing is working at its best, … they 'high five' each other for being so smart and kicking butt on the task. (We must admit that we found nothing in the distributed cognition literature about this last step, but we know it to be true."
  3. ^ a b c d e f Cockburn, Alistair; Williams, Laurie (2000), "The Costs and Benefits of Pair Programming" (PDF), Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)
  4. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 27-28. ISBN 0-201-74576-3."With pair programming, 'four eyeballs are better than two,' and a momentous number of defects are prevented, removed right from the start. These continual reviews outperform traditional, formal reviews in their defect-removal speed."
  5. ^ a b Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 29. ISBN 0-201-74576-3."Knowledge is constantly being passed between partners, from tool usage tips to design and programming idioms. The partners take turns being the teacher and the student. Even unspoken skills and habits cross partners."
  6. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 112. ISBN 0-201-74576-3."[Expert-novice pairing] can even be valuable for novices who are novices only in the sense that they haven't beenwith their team for very long. … Watching and then doing with an expert by your side can greatly reduce the time it would require to learn 'the right way' of working with the team. It really helps when the newbie works with many of the experts (or with any team member) so he or she can learn about many different aspects of the system."
  7. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 21. ISBN 0-201-74576-3."In our recent Web survey, we asked, 'What have you found beneficial about pair programming?' The single most common response was, 'It's a lot more fun!'"
  8. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 23. ISBN 0-201-74576-3."Two people working 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 other's time." (Ward's Wiki 1999, contributed by Paul Chisholm).
  9. ^ Beck, Kent (2000). Extreme Programming Explained. Addison-Wesley. s. 102. ISBN 201-61641-6. {{cite book}}: Tjek |isbn=: length (hjælp)"Under stress, people revert. They will skip writing tests. They will put off refactoring. They will avoid integrating. With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won't."
  10. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 24. ISBN 0-201-74576-3."With any software development process there is a constant struggle to get the software engineers to follow the prescribed process. A benefit of pair programming is improved adherence to procedures and standards."
  11. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. s. 24. ISBN 0-201-74576-3."Others see us already working with someone else, and they leave us alone. The net effect is that we have bigger blocks of uninterrupted time, which is good for our mental state and our progress. It also reduces task-switching, which for some people generates a huge overhead."
  12. ^ "Agility counts". The Economist. 20. september 2001..
  13. ^ According to "Int J. of Human Computer Studies Vol (64) 2006

Eksterne links