Parprogrammering: Forskelle mellem versioner
Content deleted Content added
JGC (diskussion | bidrag) m smårettelser |
|||
Linje 1:
'''Parprogrammering '''er en
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.<ref>{{cite book
Line 16 ⟶ 15:
* 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
* 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".
Line 22 ⟶ 21:
* 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
* 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
Line 97 ⟶ 96:
|url=http://www.economist.com/displayStory.cfm?Story_ID=779429}}.</ref>
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.<ref name='ijhcs'>According to "Int J. of Human Computer Studies Vol (64) 2006</ref>
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 ==
{{reflist|2}}
==Eksterne links==
* [http://citeseer.ist.psu.edu/williams00all.html All I Really Need to Know about Pair Programming I Learned in Kindergarten] af Laurie Williams & Robert Kessler (2000),
| |||