Spring til indhold

Parprogrammering

Fra Wikipedia, den frie encyklopædi

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

Mens observeren reviewer, overvejer observeren også den strategiske retning af arbejdet, og kommer med ideer for forbedringer og hvilke sandsynlige fremtidige 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 kodelinien 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 checket 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][7]
  • forbedret moral: Programmører fortæller om større glæde ved arbejdet[8] 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.[9] eller andre brud på disciplinen når de arbejde med deres partner. Partneren "Keeps them honest".[10][11]

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. ^ 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. 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."
  8. ^ 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!'"
  9. ^ 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).
  10. ^ 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."
  11. ^ 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."
Hentet fra "https://da.wikipedia.org/w/index.php?title=Parprogrammering&oldid=1938601"