pair programming
/ˈpeə ˌprəʊ.ɡræm.ɪŋ/zelfstandig naamwoord
Pair programming is een werkwijze waarbij twee ontwikkelaars tegelijk aan dezelfde programmeertaak werken. De een schrijft de code, terwijl de ander meedenkt en het werk direct beoordeelt.
Voor de ingewikkelde migratie kozen de ontwikkelaars voor pair programming, zodat ze ontwerpkeuzes meteen konden bespreken.
Bij pair programming werken twee ontwikkelaars samen aan één taak en dezelfde code. Vaak zitten ze achter één computer, maar de samenwerking kan ook op afstand met schermdeling of een gedeelde ontwikkelomgeving. Beiden denken mee en werken actief aan de oplossing.
Bestuurder en navigator
De ontwikkelaar die de code schrijft, wordt meestal de driver genoemd. De navigator kijkt mee, denkt vooruit en stelt vragen over bijvoorbeeld de gekozen aanpak, randgevallen en leesbaarheid. Deze rollen liggen niet vast: de ontwikkelaars wisselen geregeld, zodat beiden de oplossing begrijpen en invloed houden op de uitwerking.
Samenwerken in een paar kan handig zijn bij complexe logica, onbekende delen van een Woordenboek · In het kortcodebaseEen codebase is de verzameling broncode waaruit een softwareproduct of onderdeel wordt gebouwd en onderhouden.Lees meer of werk waarbij kennisoverdracht belangrijk is. Twee ontwikkelaars besteden op hetzelfde moment aandacht aan één taak. Daarom weegt een team per taak af of directe samenwerking die gezamenlijke tijd waard is.
Verschil met een code review
Bij een Woordenboek · In het kortcode reviewEen code review is de beoordeling van een codewijziging door een andere ontwikkelaar. Die controleert onder meer de werking, leesbaarheid en onderhoudbaarheid voordat de wijziging wordt samengevoegd.Lees meer beoordeelt een collega meestal een wijziging nadat de auteur deze heeft geschreven. Bij pair programming vindt die beoordeling tijdens het programmeren plaats. Vragen en mogelijke fouten komen daardoor meteen ter sprake, terwijl de oplossing nog wordt gevormd.
De twee werkwijzen kunnen elkaar aanvullen. Een pair kan samen code schrijven en de wijziging daarna alsnog laten beoordelen door iemand die niet bij het programmeerwerk betrokken was. Zo krijgt de code ook een frisse blik en blijft de gekozen oplossing begrijpelijk voor de rest van het team.