Parprogrammering - ett par som är större än summan av dess delar. Du kanske har hört talas om parprogrammering och undrade om det var värt att prova på din arbetsplats. På ytan låter det enkelt, men två utvecklare som sitter tillsammans är inte allt som krävs för att uppnå produktiv parning.

Logistiska och personliga hinder som schemaläggning, verktygsval och distraktioner kan hindra dig från att få ut så mycket som möjligt av parning. Men de potentiella fördelarna kan göra det värt besväret att erkänna och övervinna dessa utmaningar.

Varför para ihop?

Hur kan det vara mer produktivt att ta två programmerare som tidigare arbetade på separata projekt och få dem att arbeta tillsammans på ett enda projekt? Tar inte allt dubbelt så lång tid? För en utomstående kan idéen om parning låta kontraproduktivt i början, men fördelarna blir uppenbara när du börjar tänka på varför vi kodar och vad vi försöker åstadkomma.

Programmering handlar inte om att kasta bort de flesta kodraderna på kortast tid, eller till och med leverera de flesta funktioner inom allt hårdare tidsfrister. Du kan ha ingenjörer som arbetar dygnet runt som driver nya funktioner i produktionen, men hur produktiva är de egentligen om dessa funktioner släpps ut av individer som arbetar isolerat enligt deras egen unika förståelse för den övergripande arkitekturen? Den resulterande koden kommer troligen att vara full av tekniska skulder som dolda buggar, prestandaproblem, idiosynkratisk syntax och ineffektiva konstruktioner som kanske inte använder resurser effektivt och kan göra det mycket svårare och tidskrävande att ändra koden när en av dessa brister ytor.

Du behöver din kod för att vara meningsfull och välskrivet så att den fungerar sömlöst och lätt kan ändras. Du behöver den för att kapsla in önskad funktionalitet så att din slutprodukt fungerar korrekt och fungerar som förväntat. Du behöver att den ska vara fjädrande så att den kan motstå organisatoriska förändringar som är en naturlig del av att arbeta tillsammans, liksom miljöförändringar och nya kundförväntningar som kan göra dagens genomförbara lösning föråldrad utan mycket varning.

För att göra det möjligt måste utvecklare kunna komma överens om grundläggande krav tydligt, snabbt komma igång med vad ny eller etablerad teknik kan behöva och fokusera utan avbrott för att testa kreativa lösningar och utveckla en produkt som är värt att sätta framför kunden.

Dessa är de verkliga utmaningarna som parprogrammering hjälper till att hantera. När två utvecklare arbetar tillsammans i ett par förbättras kvaliteten på koden de producerar tillsammans med deras gemensamma förståelse för hur den fungerar. Detta gör det lättare för nästa person som läser koden att plocka upp den och ändra den vid behov, och det minskar risken att den enda personen i laget som vet hur en del av koden fungerar kan vinna lotteriet och lämna laget , tar den värdefulla kunskap med sig

Tiden kostar in mytiska arbetstimmar är ingenstans nära de 50% som kan verka intuitivt om du försökte jämföra den komplicerade kodningen med repetitiva monteringslinjer. Några empiriska studier har kommit fram till att parprogrammering kan resultera i cirka 15% ökning under tiden det tar två programmerare att utföra samma uppgifter om de hade arbetat ensamma, men den resulterande koden kommer också att vara av mycket högre kvalitet, med cirka 15% färre observerbara defekter att fixa. Kombinera detta med det delade ägandet, djupare engagemang och snabbare problemlösning som kommer från att ha mer än ett sinne engagerat i att lösa ett problem, och det är tydligt varför parprogrammering är en populär metod.

Vad exakt är parning?

Så vad krävs för två utvecklare som arbetar tillsammans för att uppnå produktivitet och kvalitetsförbättringar som kommer från parning? Det handlar mest om att lära sig att arbeta i samarbete, vilket inte nödvändigtvis är det som de flesta av oss har lärt oss att koda.

Per definition startar parprogrammering inte förrän du har två personer som arbetar tillsammans på en dator. Men hur fungerar det i praktiken?

Två personer …

Det grundläggande elementet i parprogrammering är att arbeta tillsammans med ditt par. När en uppgift accepteras måste den delas mellan båda personerna som arbetar med den, och de måste båda vara helt engagerade i uppgiften medan de kopplar ihop den. Det betyder att de båda måste förstå kraven på samma sätt och arbeta tillsammans för att komma till en gemensam förståelse för hur de vill möta dem.

Parning hjälper människor att bli bättre på att verbalisera sina idéer och förväntningar. Den implicita förståelsen du har i huvudet när du arbetar ensam måste kommuniceras så att både du och ditt par vet att du är på samma sida. Att bli så tydlig som möjligt om arbetet och tillvägagångssättet framåt kommer att göra parningsupplevelsen mycket mer behaglig. Parning innebär mycket samtal, eftersom det är det bästa sättet att hålla två sinnen aktivt engagerade i problemet på samma gång.

Av denna anledning är ofta koppling kopplad till smidig berättelse, där krav för en funktion definieras på ett konsekvent, vanligt språk som kan förstås lika bra av produkt- och ingenjörspersoner med lite utrymme för tvetydighet. Ofta kommer par att begära att berättelser ska skrivas ut i Gurka, vilket är ett sätt att använda vanliga, icke-tekniska fraser som är lätta att översätta till automatiserade tester, så att paret kan verifiera och visa att varje funktion fungerar som förväntat.

Att skriva i Gherkin betyder att ta en funktion och dela upp den till en enkel Historien om en kund som vill ha något som den här funktionen kommer att leverera:

As <a customer of the product>
I want <something desirable>
So that <I can achieve a specific goal>

Då alla godkännande kriterier skrivs ut i en konsekvent syntax och definierar förväntade permutationer och scenarier associerade med den berättelsen:

Given <a customer in a particular state>
When <something specific happens>
Then <there is a specific outcome> Given <a customer in a particular state>
When <something different happens>
Then <there is a different specific outcome> etc.

Naturligtvis är det inte obligatoriskt att använda denna exakta formulering, men om kraven för en funktion inte kan uttryckas på detta minimalistiska sätt, är det möjligt att förväntningarna är tvetydiga. Det är en potentiell röd flagga som är lättare för ett par programmerare att upptäcka när de börjar diskutera vad som behövs.

Så snart ett par accepterar en historia att arbeta med, borde de kunna definiera hur de vet att de är klara och hur de ska bevisa det. Därifrån kan de börja ta reda på hur de bäst kan komma till jobbet.

I själva verket borde paret som arbetar med en funktion veta tillräckligt med att de kan börja med att skriva ett automatiserat test baserat på det första godkännandekriteriet innan du skriver någon kod, se till att det nya testet misslyckas, och sedan skriva tillräckligt med kod för att göra det testet godkänt innan refactoring och sedan börjar med nästa acceptans kriterium. Denna metod är känd som beteendestyrd utveckling, och även om det inte är en del av definitionen av parprogrammering, harmoniserar den vackert, tillsammans med testdriven utveckling.

Arbetar tillsammans …

När du har två eller flera personer som försöker arbeta tillsammans är det första de behöver göra att enas om ett arbetsschema. Det är inte riktigt parning om två utvecklare inte arbetar tillsammans på samma gång. På grund av detta är det viktigt att utvecklarna som planerar att samarbeta samordna sina scheman och se till att de båda håller med om en tid och plats där de kommer att arbeta.

Ett misstag jag har sett par göra är att försöka maximera tiden de arbetar tillsammans som ett par genom att schemalägga hela åtta timmar tillsammans och ibland försöka arbeta tillsammans utöver det. Parning är intensivt arbete som kräver en ökad nivå av fokus och deltagande. Det är mycket beskattande att försöka koppla ihop sig i mer än fem eller sex timmar på en dag, och till och med det kan sträcka det för även de mest motståndskraftiga av oss. När du ställer in ett parningsschema kan du försöka komma överens om en fast och begränsad tid som passar inom en typisk åtta timmars arbetsdag och lämna tid till lunch, e-post, personliga uppgifter etc. Dessa personliga uppgifter är viktiga för vår arbetsdag, men de är också distraktioner som inte bör försökas under en parningssession.

Det kan också vara socialt besvärligt att påminna ditt par när den överenskomna parningstiden är slut. Av den anledningen kan det vara en bra idé att ställa in ett larm som bryter nyheterna för er båda utan att lägga bördan på det ena eller det andra.

Färdighetsnivå är ett annat område där par kan ha problem. Det är ett rättvist antagande att oavsett vad du arbetar med, personen du arbetar med har en annan bakgrund, erfarenhet och komfort med ämnet. Att erkänna att framifrån är viktigt, så ingen av er kommer att känna behovet av att försöka dölja det faktum. En av fördelarna med parning är att genom att arbeta tillsammans naturligt skapas färdigheterna hos alla som lär sig något nytt, vare sig det är ett programmeringsspråk eller en kommunikationsstil.

Var nådig om du känner att du är mer skicklig än ditt par. Behandla dem på det sätt som du vill behandlas när du lär dig något nytt. Och kom ihåg att poängen inte bara är att få arbetet gjort, utan att se till att ni båda har tillräcklig kunskap och äganderätt till slutresultatet.

För det ändamålet är det viktigt att varje programmerare har möjlighet att sitta vid tangentbordet och köra medan den andra observerar och navigerar genom koden. Konceptet att ta tur kan vara nytt för alla vars exklusiva upplevelse som programmerare har varit soloarbete, så det kommer att finnas en lärande kurva när du anpassar dig till att verbalisera dina avsikter när du navigerar eller utför någon annans idéer när du kör.

En programmerare som är ny i parning men bekväm med den aktuella uppgiften kan lätt komma in i ett mönster att hålla fast i förarrollen så länge som möjligt. På samma sätt, om du inte kör vid tangentbordet och du inte är så bekant med koden, är det lätt att hitta ditt sinne vandra tillbaka till din telefon, din e-post och dina andra uppgifter. När det händer slutar du med att en person som kodar ensam och den andra personen som sitter i samma rum rullar genom sociala medier.

En av ledtrådarna att ett par kan ha problem med att vända är tystnad. Parning är en bullrig process som involverar många frågor, feedback, diskussion och samarbete. När ett par befinner sig gå mer än en minut eller två utan att säga ett ord, är det troligt att parningen har slutat.

En användbar teknik som kan hindra par från att falla in i denna antipattern är att använda a Pomodoro-timer. Dessa tidtagare kommer att hålla en nedräkning av sekunderna när du arbetar i steg om 25 minuter och ber dig sedan ta en paus i fem minuter. Genom att växla roller mellan föraren och navigatorn under dessa pauser kan ett par undvika att övergå till utökade sessioner med bara en förare.

På en dator ...

Parning fungerar bara när två personer ägnar sin fulla uppmärksamhet åt en enda dator. Det är bättre att undvika distraktionen med att två (eller fler) aktiva skärmar går under en parningssession. Även om en person bara vill leta upp några relevanta kodexempel eller kontrollera statusen för en bakgrundsprocess, är det bättre att göra det på den delade datorn. Om det är en sökning kan båda utvecklarna se hur sökningen är konstruerad och vilka potentiella resultat som kommer upp. Om det är en statusuppdatering behöver ingen av utvecklarna lämnas kvar.

Så i vilket par som helst måste båda utvecklarna kunna se skärmen de arbetar tillsammans tydligt. Ett av de väsentliga verktygen för parning är en monitor tillräckligt stor för att båda utvecklarna kan se vad som skrivs tydligt. Beroende på omständigheterna kan detta utföras med en delad bärbar dator om du inte bryr dig om att krama ihop och du använder ett tillräckligt stort teckensnitt med tillräcklig kontrast. En bättre lösning är en större stationär eller väggmonterad bildskärm där koden kan visas och ses tillsammans mer bekvämt.

Fjärrkoppling är ett mycket livskraftigt alternativ i dag. Det finns ett antal fantastiska lösningar från Slak or Zoom verktyg för fullblåsthet integrerade utvecklingsmiljöer och textprocessorer som stöder skärmdelning, konferenssamtal eller båda, så att två personer på motsatta sidor av skrivbordet eller motsatta sidor av världen kan arbeta tillsammans. Även om du är vid nästa plats på ett öppet kontor kan skärmdelning göra det enklare för er båda att se och interagera med koden på skärmen mer bekvämt. (Jag uppmuntrar bara dig att hålla fokus och motstå lusten att ta fram din e-post i ett separat fönster medan du parar ihop fjärrkontrollen. Det är respektlöst, det kommer att vara uppenbart för den person du parar ihop med, och din distraktion kommer att göra dig missa möjligheterna att lära tillsammans och producera kvalitetsresultat.)

Om ett samlokaliserat par delar en enda maskin, kommer de att behöva komma överens om konfigurationen av deras delade datorer, tangentbord, mus, etc. Det ergonomiska tangentbordet med alla anpassade hårdvarumakroer kanske inte är det bästa valet för delning . Men om du inte har något emot att använda samma bärbara dator eller tangentbord och mus kan byta roller från navigator till drivrutin i ett par vara lika enkelt som att byta plats.

En populär och mycket robust lösning är att aktivt använda ett versionskontrollsystem som Git. Sänd din kod ofta till ett delat arkiv så att varje utvecklare kan dra den senaste versionen och arbeta på sin egen enhet när de byter roll. Att använda versionskontroll för att hantera byte i par har den extra fördelen att skapa en mer detaljerad historik över kodändringar för framtida loggning och potentiella återuppspelningar. Om Git-loggarna blir för röriga, är det alltid möjligt att gå tillbaka och krossa de extra åtagandena till en enda, mer meningsfull en innan du gör en dragförfrågan.

På en högre nivå, när du börjar para ihop med en annan utvecklare, kommer du att märka vissa skillnader i de sätt du vänder dig till dina uppgifter. En av er kanske känner till några snygga kortkommandon, har några speciella alias för vanliga skalkommandon eller föredrar att använda en specifik IDE på grund av dess unika funktioner. När det gäller själva koden kan du också ha en annan implicit förståelse för hur variabler namnges, hur man strukturerar ett meddelande om engagemang, när man ska använda kommentarer etc.

Parning är en möjlighet att synliga medvetna variationer i teknik synliga så att alla kan dra nytta av den dolda mängden erfarenhet och kunskap om hur vi kodar mer effektivt.

Hur man börjar para ihop

Det finns ofta en period av anpassning när du bygger muskelminnet och lär dig att uttrycka idéer högt som en gång bara var tankar i bakhuvudet. Det är också nödvändigt att upprätta fungerande logistik för att låta två personer arbeta tillsammans, vilket kan innebära justeringar när det gäller scheman, platser och utrustning. Och när du har fungerat kan du försöka utöka processen till hela teamet med förbättringar som t.ex. mob programmering för grupper, eller promiskuös parning att ge alla på laget en chans att koppla ihop alla lagets berättelser.

Att anstränga sig för att komma igenom lärandefasen lönar sig vanligtvis i betydande förbättringar, både för kvaliteten på koden och för lyckan och hållbarheten hos de människor som skapar den. Och om hela teamet eller organisationen antar parning, kommer inlärningskurvan att bli ännu enklare för nya människor, förbättra onboardingprocessen och hjälpa alla att bli mer produktiva.

Källa: https://www.sitepoint.com/pair-programming-guide/?utm_source=rss