Min første respons etter å ha lest innlegget til Kent Inge Fagerland Simonsen, der han etterlyser mer kritiske pull request (PR) reviews, var å riste på hodet.
Etterlyser mer kritiske PR reviews
Har vi virkelig ikke kommet lenger enn det?
Han skriver:
«En mulig måte å oppnå balanse mellom behovet for å beholde hyggelig arbeidsmiljø og kvalitet, kan være å eksperimentere med metoder for å øke avstanden mellom den som foreslår en endring og reviewer.»
Vi trenger ikke mer avstand. Det vi trenger er trygge team, der alt av endringsforslag er lov å komme med og der alle tørr å si sin mening.
«Og løsningen på dette? Å snakke sammen, vel!»
Snakke, så kode
PR review er OK til sitt bruk det. Du får en sjekk på syntaks og kommentarer på detaljer som kunne blitt skrevet bedre. Småting, rett og slett.
Men se for deg at du får tilsendt en omfattende pull request, og vet at den andre utvikleren har brukt et par dager på å løse oppgaven. Det føles for brutalt å skulle be henne om å løse det på en helt annen måte.
Da sier du jo rett ut at hun har kastet bort arbeidsdagene. Det blir fort dyrt for en arbeidsgiver, og det føles gjerne ikke som rett prioritering av tid. Da ender du opp med å kommentere på syntaks og detaljer, og en halvgod løsning blir sjekket inn.
Og løsningen på dette? Å snakke sammen, vel! Før en eneste kodelinje blir skrevet.
- Vanskelig å føle at man strekker til
Par- og mobprogrammering
De beste reviewene får vi etter min mening med par- eller mob-programmering.
Når flere skriver kode sammen blir resultatet som regel mer lesbart, syntaktiske rettelser og detaljer blir tatt fortløpende og bedre løsninger blir valgt.
Men selv når du skal kode solo, er det etter min erfaring alltid en fordel å snakke med en annen utvikler på teamet først. Lufte ideene og finne den rette måten å gå fram på.
Det finnes alltid flere måter å kode noe på. Det er ikke nok at det virker i test. Koden skal være vedlikeholdbar, leselig for andre og skrevet med et fornuftig abstraksjonsnivå.
«Jobber du i et team, så bør all kode være felles ansvar.»
Felles ansvar
En smarting jeg ikke husker navnet på, sa noe sånt som: «Om du ikke klarer å komme opp med tre måter å løse et problem på, så har du egentlig ikke forstått problemet»
Det tenker jeg passer veldig bra for vår bransje. Og for å lande på det beste løsningsforslaget, må man rett og slett snakke sammen.
Jobber du i et team, så bør all kode være felles ansvar. Aldri min kode og din kode. Det kan derfor ikke sammenlignes med å skulle publisere en vitenskapelig artikkel og få tilbakemeldinger fra andre forskere.
Å snakke kode er nyttig for både seniorer og juniorer. Har man som vane å alltid diskutere løsningen først, så ender man opp med felles eierskap, og det er flere som senere husker og forstår hvorfor noe ble løst som det ble.
