Advarer mot KI-felle: Ber deg sette av mer tid til pull requests

Lærte du noe nytt under PR-gjennomgangene dine forrige uke?

Det retoriske spørsmålet er egentlig ment som et spørsmål man bør stille seg selv for å evaluere egen praksis. Alle utviklere bør stille seg dette spørsmålet med jevne mellomrom.

Hvis svaret begynner å bli et «nei» uke etter uke, bør det være en påminnelse om forholdet man har til kodebasen og kollegene sine.

Vi må gjøre en innsats

En av de sentrale diskusjonene rundt bruk av KI i programmering handler om å miste kontrollen over kodebasen.

Det sier seg selv at entusiaster innen vibe coding, som ikke har noen tidligere erfaring med eller kunnskap om programmering, aksepterer dette premisset allerede før de begir seg inn i denne verdenen.

Men vi som er profesjonelle utviklere, må vite hva koden gjør, og nøyaktig hvordan den fungerer. Uansett om den er skrevet av KI eller et menneske. For når alt kommer til alt, er det vi som har det fulle ansvaret for hva koden faktisk gjør.

Derfor må vi gjøre en innsats for å beholde kontrollen over kodebasene våre.

Den falske tryggheten til KI

Den falske tryggheten KI-generert kode gir, er en felle de fleste kjenner til.

Utvikleren som sender inn koden, stoler på det KI-en har generert og tenker: «Dette fungerer sikkert fint.» Den som gjennomgår koden, stoler både på kollegaen og KI-en og tenker: «Han vet sikkert hva han driver med.»

Til slutt havner feil eller dårlige implementasjoner i produksjon uten at noen har oppdaget dem.

En måte å unngå denne fellen på er å gjennomføre gode pull request-gjennomganger (PR-gjennomganger). Etter min mening kjennetegnes en god PR-gjennomgang av tre egenskaper:

Nysgjerrighet, sosiale ferdigheter og vilje til å diskutere bedre alternativer.

Enhver PR er et potensielt åsted for fremtidige lovbrudd. Når vi godkjenner den, blir vi medskyldige. Derfor bør de som gjennomgår koden, være like nysgjerrige som detektiver. Hvis du ikke forstår en bestemt kodelinje, så pek på den og spør hvorfor den er skrevet slik.

– Når jeg vibbekoder, har jeg ikke peiling

– KI er mest verdifull når den gjør ting jeg ikke kan selv. Men da har jeg også dårligst forutsetninger for å vite om den gjør feil, skriver Kjell-Vidar Åhman Teig.

Lærte, takket være nysgjerrighet

Samtidig er PR-gjennomganger en flott anledning til å utvide sin egen programmeringskompetanse.

Jeg visste for eksempel ikke hva lazy initialization i useState var, før jeg oppdaget det i en kollegas feature-branch. Se linjen nedenfor:

const [initialValue] = useState(() => questionValues.value ?? '');

Jeg hadde aldri sett en funksjon bli sendt inn ved initialisering av en hook. Jeg var vant til den tradisjonelle måten å initialisere hooken på, uten en arrow-funksjon:

const [initialValue] = useState(questionValues.value ?? '');

Så hva er forskjellen når man bruker lazy initialization i useState? I det første tilfellet kjører React funksjonen bare én gang, under komponentens aller første render. Ved senere re-renders ignorerer React funksjonen fullstendig, slik at unødvendig prosessering unngås.

Takket være nysgjerrigheten min under denne PR-gjennomgangen lærte jeg noe nytt. Erfaringen bidrar både til å utvide den tekniske kompetansen min og til å gjøre meg bedre rustet til å vurdere fremtidige kodeendringer.

Derfor mener jeg at alle utviklere bør finne minst én kodelinje hver uke som de kan lære noe nytt av.

«FermAI-paradokset»: Hvor blir det av alle appene?

Hele verden vibbekoder, men vi ser ingen eksplosjon av nye tjenester. Grunnene er mange, tror Kent Inge Fagerland Simonsen og Peter N. M. Hansteen, og mener løsningen heter Solid.

Par-PR-gjennomgang

Nysgjerrigheten vil naturlig føre oss videre til neste steg: å bruke de sosiale ferdighetene våre. Hvis du nøler med å stille et spørsmål eller kommentere noen kodelinjer, er det sannsynligvis nettopp det du bør gjøre.

Vi har mange måter å kommunisere med utvikleren som har sendt inn koden på, for eksempel kommentarer på GitHub, Teams og Slack. Men hvis en diskusjon fortsatt ikke har ført til en avklaring etter noen kommentarer, er det ofte enklere og mer effektivt å snakke sammen direkte.

I teamet mitt praktiserer vi Pair PR-gjennomganger når en PR er større enn vanlig, eller når kodeendringene berører kritisk funksjonalitet. I en typisk Pair PR-gjennomgang presenterer utvikleren som har sendt inn koden, implementasjonen sin for den som gjennomgår den, og forklarer tankegangen bak den. Dermed blir det enklere for den som gjennomgår koden, å forstå hva den faktisk gjør.

En Pair PR-gjennomgang er svært interaktiv. Utvikleren kan kjøre feature-branchen sin mens gjennomgangen pågår, og de andre kan teste hypotesene sine lokalt eller på en feature-server. Når den felles gjennomgangen er ferdig, fortsetter den tradisjonelle, individuelle PR-gjennomgangen.

Alt i alt spiller sosiale ferdigheter en viktig rolle, fordi en PR-gjennomgang er en sosioteknisk prosess.

Innså feil forståelse

Her er et annet eksempel på hvordan både en kollega og jeg nylig lærte noe nytt om TypeScript. Jeg oppdaget følgende kodelinje i en PR fra en kollega:

export const useClickView = (
  page: string | undefined,
  sectionNumber?: number,
  sectionName?: string
) => {
...

useClickView er en custom hook med tre parametere, der alle kan ha verdien undefined. For å gjøre beskrivelsen av parameterne mer konsistent anbefalte jeg kollegaen min å definere hooken slik:

export const useClickView = (
  page?: string,
  sectionNumber?: number,
  sectionName?: string
) => {
...

Forskjellen mellom de to kodeeksemplene ligger i den første parameteren. Den første kodeblokken sørger for at parameteren page må oppgis når man bruker den custom hooken. Den andre kodeblokken åpner derimot for å bruke useClickView uten å sende inn noen parametere.

Jeg var usikker på om dette faktisk stemte under gjennomgangen. Derfor testet vi hypotesene våre sammen og oppdaget at TypeScript ga følgende feilmelding når vi ikke oppga noen parametere i det hele tatt:

TS2554: Expected 1-3 arguments, but got 0.

Jeg innså at jeg hadde en feilaktig forståelse av valgfrie parametere i TypeScript. Jeg hadde heller ikke vært klar over at parameteren page faktisk måtte oppgis hver gang vi brukte denne hooken.

Denne erfaringen er derfor et perfekt eksempel på hva jeg mener med nysgjerrighet, bruk av sosiale ferdigheter og vilje til å diskutere bedre alternativer.

Stadig viktigere

Alt i alt mener jeg at alle utviklere bør stille seg spørsmålet ganske ofte, særlig i en verden der stadig mer blir automatisert.

PR-gjennomganger blir stadig viktigere etter hvert som bruken av KI-assistert kode øker.

Så, lærte du noe nytt under PR-gjennomgangene dine forrige uke?

– Ledere: Slutt å spørre om utviklerne deres bruker KI!

– Spør heller om dere har testene, spesifikasjonene og tilliten som gjør at de kan bruke den på alvor, skriver Truong Van Thanh Le, etter å ha bytta en diger plattform på et par måneder.