Parprogrammering: Forskelle mellem versioner
Content deleted Content added
No edit summary |
No edit summary |
||
Linje 19:
* 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 [[high five|fejre det]].<ref>{{cite book
|last=Williams
|first=Laurie
|title=Pair Programming Illuminated
|publisher=Addison-Wesley
|date=2003
|pages=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."</ref>
* 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.<ref name="costs-benefits">{{citation|last=Cockburn|first=Alistair|last2=Williams|first2=Laurie|title=The Costs and Benefits of Pair Programming|journal=Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)|author-link=Alistair Cockburn|year=2000|url=http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF}}</ref>
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<ref>{{cite book
|last=Williams
|first=Laurie
|title=Pair Programming Illuminated
|publisher=Addison-Wesley
|date=2003
|pages=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."</ref>
* ''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.<ref name="costs-benefits"/>
* ''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.<ref name="costs-benefits"/><ref>{{cite book
|last=Williams
|first=Laurie
|title=Pair Programming Illuminated
|publisher=Addison-Wesley
|date=2003
|pages=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."</ref>
Nyansatte lærer hurtigt holdets arbejdsformer at kende gennem pararbejde.<ref>{{cite book
|last=Williams
|first=Laurie
|title=Pair Programming Illuminated
|publisher=Addison-Wesley
|date=2003
|pages=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."</ref>
* ''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.<ref name="costs-benefits"/><ref>{{cite book
|last=Williams
|first=Laurie
|title=Pair Programming Illuminated
|publisher=Addison-Wesley
|date=2003
|pages=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."</ref>
* ''forbedret moral:'' Programmører fortæller om større glæde ved arbejdet<ref>{{cite book|last=Williams|first=Laurie|title=Pair Programming Illuminated|publisher=Addison-Wesley|date=2003|pages=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!'"</ref> og større tillid til at deres arbejde er korrekt.<ref name="costs-benefits"/>
* ''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.<ref name="costs-benefits"/>
*''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.<ref>{{cite book
|last=Williams
|first=Laurie
|title=Pair Programming Illuminated
|publisher=Addison-Wesley
|date=2003
|pages=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).</ref> eller andre brud på disciplinen når de arbejde med deres partner. Partneren "Keeps them honest".<ref>{{cite book|last=Beck|first=Kent|title=Extreme Programming Explained|publisher=Addison-Wesley|date=2000|pages=102|isbn=201-61641-6|authorlink=Kent Beck}}"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."</ref><ref>{{cite book|last=Williams|first=Laurie|title=Pair Programming Illuminated|publisher=Addison-Wesley|date=2003|pages=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."</ref>
*
== Referencer ==
{{reflist}}
| |||