Sådan programmeres i par (Parprogrammering)

Peer Programmering er en programmeringsmetode, hvor to personer arbejder sammen på en arbejdsstation. En person, "pilot" -typerne på tastaturet. Den anden person, observatøren (eller "browser") gennemgår hver enkelt kode som den skrives, kontrollerer fejl og tænker på det overordnede projekt. Peer programmering er mere sjov og produktiv end programmering alene.

trin

  1. 1
    Start med en veldefineret opgave, før du sætter dig ned. Opgaven skal være noget, du er sikker på at fuldføre om en time eller to. F.eks. Tilføj vedligeholdelseskode og historik kommentarer i databaseadgangskoden.
  2. 2
    Enig at gøre et lille mål ad gangen, noget de kan afslutte om få minutter. Verbalizing problemet til den anden person kan hjælpe med at koncentrere begge dele. Det sikrer også, at både ved, hvad de enkelte gør i øjeblikket.
  3. 3
    Skriv enhedstesten først, inden du skriver implementeringen, da det hjælper med at definere det næste mikroobjektiv, så begge forstår, da begge kan se koden. Det næste mikroobjektiv bliver "Gør denne test lykkes."
  4. 4
    Stol på og støtte din partner.

    • Når du piloterer, skal du færdiggøre mikroobjektivet så hurtigt som muligt og ignorere større problemer. Stol på observatøren at være dit sikkerhedsnet.
    • Når du er observatør, læs hvad piloten skriver mens skriver han. Dit mål er kodeoversigt, og du skal have total opmærksomhed og forsøge at lade intet passere dig. Tænk på problemer og fejl, større punkter og måder at forenkle eller forbedre projektet på. Opsæt fejl og uddrag af svær læsning med det samme. Vent, indtil den nuværende mikroobjektiv er færdig med at bringe større problemer og ideer til forbedring. Opbevar disse små opgaver til senere, så piloten kan fokusere på den nuværende opgave. Hvis du f.eks. Ser at den nuværende kode ikke tester for en null imput, skal du notere ned på et stykke papir "sæt null imput test i enhedsprøven.
    • Når du er en observatør, må du ikke sige kode. Piloten bør tænke på, hvordan man fuldfører den aktuelle opgave, ikke blot at skrive passivt. Som observatør bør du undersøge, at du ikke behøver at gennemføre små detaljer, du kan og burde tænke på et højt niveau. Sig "Denne del virker rigtigt, hvad med at håndtere sagen, hvor vi nu får en nullpeger?" er bedre end at sige, "Ok, skriv nu `hvis (s == NULL) {return ...`"
  5. 5


    Fortsæt synkronisering. Når parret virker, vil du gradvis gå ud af synkronisering, blive nebulous, hvad partneren laver, eller hvad den aktuelle opgave er, men det er normalt. Når det gør det, skal du bare genoptage synkroniseringen, da nøglen til et godt par er en hyppig synkronisering, da i løbet af få minutter eller sekunder vil du være ude af synkronisering. Hvis du bruger fem eller flere minutter uden synkronisering, ville begge være bedre at kode alene, fordi det er den hyppige synkronisering, der skaber parrets synergi.

    • Når du kan, fortæl hvad du vil gøre, før du gør det. Bedre endnu, spørg din partner, for eksempel, "Kan vi skrive testen for nul nu?" Nogle gange skal du skrive et kodestykke for at forstå din begrundelse, og du kan sige, "Jeg skal skrive dette her for at se, om det er en god ide." Hold denne type spørgsmålstegn mindre end et minut.
    • Når din partner spørger om du er enig med noget, som "skal vi skrive testen for null nu?" eller "Jeg tror, ​​at denne metode kan fjernes nu, er du ikke enig?" Sig ja eller nej med det samme.
    • Det er normalt at flytte tastaturet frem og tilbage ofte. For eksempel er det undertiden meget lettere at sige noget ved at skrive end mundtligt. Lad observatøren afhente tastaturet og skrive, og du kan straks tage den op igen, eller lad observatørdrevet, hvad der er mest fornuftigt i øjeblikket.
  6. 6
    Vær særlig høflig, såsom at takke din partner for en fejl. Når du påpeger fejltagelser, gør det så venligt at undgå at krænke den anden person. Fejl og deres efterfølgende korrektion er normale i programmeringen, ikke et bevis på, at nogen ikke ved, hvordan man programmerer. Som observatør, lad piloten afslutte en linje, før du påpeger en fejl, da de fleste finder det irriterende at blive rettet, når de skriver.
  7. 7
    Fejre. Når du f.eks. Gennemfører en opgave eller overvinder problemer, giver den anden en kompliment, når en test afleveres. Hvis du er hilsen hver gang en test fejler, går du faktisk ind i klimaet af samarbejdsprogrammering og testdrevet design.
  8. 8
    Skift roller ofte, mindst en gang hver halve time. Dette holder både involveret, i overensstemmelse med de lave niveauer og høje detaljer også. Og at skrive hele tiden kan trætte, da det er svært at opretholde den nødvendige årvågenhed for observatøren i mere end en halv time. Roterende papir hviler på dine fingre og oplader batterierne.

tips

  • Sid dig ned, før du begynder og diskuter de punkter, hvor parret kan handle. Et rektangulært bord fungerer bedst, fordi skærmen kan vendes og tastaturet ved siden af ​​det (i modsætning til buede og ergonomiske møbler).
  • Det foretrækker desktops, der bærbare computere, fordi deres reducerede størrelse og vanskeligheden med at se skærmen på siden er vanskelige, men de gør ikke opgaven umulig. Et trick er at få observatøren til at sidde bag piloten frem for siden.
  • Ikke argumenterer for arkitektoniske problemer eller trivielle ting, som festeindrykning. Disse ting bør afgøres, før de danner parret.
  • Den mindre kyndige skal forblive på tastaturet for at sikre, at nybegynderen bliver forlovet og inde i alt. Du lærer mere ved at bruge dine fingre og skrive koden end ved at se et mere erfaren kollegearbejde.

advarsler

  • Hvis parret ikke har samme erfaring, skal de mere erfarne tage rollen som mentor og observatør, eller parret vil ikke være harmonisk.
Del på sociale netværk:

Relaterede
© 2024 HodTari.com