I de to foregående dele af vores serie talte vi om de første skridt i udviklerjobbet og om, hvad der virkelig er værd at lære i begyndelsen af din karriere.
Nu når vi til det øjeblik, som næsten enhver Junior frygter.
Første Code Review. Første kommentarer til koden. Første rettelser.
Og den første tanke: "Har jeg virkelig skrevet koden SÅ dårligt?"
Rolig nu.
Vi har alle været igennem det på et tidspunkt.
Code Review er ikke en eksamen
Det er nok den største misforståelse blandt begyndende udviklere.
Mange Juniors tager kommentarer til deres kode meget personligt. Der kommer stress. Usikkerhed. Nogle gange endda frustration.
Men formålet med Code Review er ikke at bevise over for nogen, at de har begået en fejl. Tværtimod. Det er et af de vigtigste elementer i processen med at skabe god software.
Takket være Code Review:
- reducerer vi risikoen for fejl,
- forbedrer vi læsbarheden af koden,
- lærer vi af hinanden,
- sikrer vi sammenhængen i hele projektet,
- videresender vi viden mellem teammedlemmer.
De bedste teams ser ikke Code Review som kontrol. De ser det som en daglig udveksling af erfaringer.
"Du har 37 kommentarer"
Lyder skræmmende? I starten gør det det.
Et første Pull Request ser ofte netop sådan ud:
- Kommentar.
- Rettelse.
- Endnu en kommentar.
- Endnu en rettelse.
Efter en time får du følelsen af, at hele koden burde smides væk. Det er normalt.
Husk kun én ting. Senioren retter ikke koden for at vise sin overlegenhed. De gør det, fordi om nogle måneder vil du skrive langt bedre kode.
Og det er lige præcis pointen.
En god Senior siger ikke kun "dårligt"
De bedste udviklere, vi har arbejdet med, forklarede altid:
- hvorfor noget bør gøres anderledes,
- hvilke konsekvenser den nuværende løsning kan få,
- hvilke alternative muligheder der findes,
- hvilken løsning der vil være lettere at vedligeholde om et eller to år.
Det er en enorm forskel.
For man kan sige: "Det er dårligt."
Og man kan sige: "Det virker, men hvis vi skal udvikle dette modul om et halvt år, vil det være meget nemmere at vedligeholde i denne struktur."
I det andet tilfælde lærer du noget langt mere værdifuldt end selve rettelsen. Du lærer en tankegang.
Clean Code betyder ikke smuk kode
Det er endnu et begreb, der ofte misforstås.
Clean Code betyder ikke kode, der ser imponerende ud. Det handler ikke om antallet af tomme linjer. Det handler ikke om funktionens længde. Det handler ikke engang nødvendigvis om bestemte mønstre.
Det handler om noget langt enklere - koden skal være læsbar.
Hvis du om et halvt år åbner dit eget projekt og ikke kan huske, hvad du mente...
...så var koden sandsynligvis ikke tilstrækkelig læsbar.
Der er et ordsprog: Vi skriver kode til mennesker. Kompilatoren tjekker kun syntaksen.
Og der er meget sandhed i det.
Bliv ikke forelsket i din egen kode
Det er en af de vigtigste lektioner.
Kode er ikke et kunstværk. Det er ikke et maleri. Det er ikke en skulptur.
Det er et værktøj til at løse et konkret problem.
Hvis nogen foreslår en bedre løsning...
...så er det værd at overveje.
Ikke fordi personen har mere autoritet. Men fordi det måske faktisk er bedre.
De, der lærer mest, er de udviklere, der kan sige: "Du har ret. Lad os gøre det anderledes."
"Det virker hos mig"
Okay. Vi måtte jo nå frem til denne berømte sætning. Hvert softwarehus har sin egen version af denne joke...
Forestil dig situationen.
Testeren rapporterer en fejl.
Udvikleren svarer: "Det virker hos mig."
Testeren tjekker igen. - Det virker ikke.
Project Manager kigger. - Det virker ikke.
Kunden tjekker også. - Det virker ikke.
Men... hos kodeforfatteren virker det stadig.
Lyder det bekendt?
Ofte ligger problemet ikke i selve koden.
Årsagerne kan være meget forskellige:
- en anden datasætversion,
- et andet miljø,
- cache,
- konfiguration,
- rettigheder,
- browser,
- operativsystem,
- et tilfælde som ingen tidligere havde forudset.
Derfor afslutter en professionel udvikler ikke analysen med sætningen: "Det virker hos mig."
De stiller det næste spørgsmål.
Hvorfor virker det hos mig, men ikke andre steder?
Og først dér begynder den rigtige debugging.
"Det er kun en lille ændring"
Endnu en sætning, der fremkalder et lille smil i de fleste softwarehuse.
Kunden siger: "Det er kun en lille rettelse."
Udvikleren ved allerede, at han om et øjeblik åbner en fil, som ingen har rørt i seks år.
Og den "lille rettelse" viser sig at påvirke fem moduler, tre integrationer og to databaser.
Derfor er erfarne udviklere meget forsigtige med ordet "kun".
De mest kendte vendinger i branchen
Ethvert fag har sine vendinger. Udviklere har også.
Nogle af dem kender vel næsten alle:
- "Det virker hos mig."
- "Det tager kun fem minutter."
- "Det er ikke en bug. Det er en feature."
- "Jeg har ikke ændret noget."
- "Det crasher i produktion."
- "Bare en deploy mere."
- "Det er helt sikkert cache."
- "En hurtig rettelse før weekenden."
- "Det burde virke."
Og nok det mest farlige: "Vi smider det i produktion fredag efter kl. 16:00."
Hvis du arbejder i IT...
...så smilede du sandsynligvis lige.
Udvikleren arbejder ikke alene
Det er et emne, der ofte overses. I realiteten er de fleste projekter holdarbejde.
Udvikleren samarbejder med:
- UX-designere,
- UI-designere,
- projektledere,
- testere,
- DevOps,
- administratorer,
- analytikere,
- kunder.
Derfor er lige så vigtige som teknisk viden også:
- kommunikation,
- evnen til at lytte,
- vidensdeling,
- ansvarlighed,
- gensidig respekt.
Den bedste kode redder ikke et projekt, hvis teamet ikke kan samarbejde.
Ordliste
Code Review
Processen hvor kode gennemgås af andre udviklere før udrulning. Formålet er at forbedre kodekvaliteten, opdage fejl og dele viden.
Pull Request (PR)
Forslag om at indføre ændringer i projektet. Det er typisk på dette trin, at Code Review foregår.
Clean Code
En tilgang til at skrive kode med fokus på læsbarhed, enkelhed og vedligeholdelsesvenlighed, ikke antallet af anvendte designmønstre.
Debugging (fejlfinding)
Processen med at finde og fjerne årsager til fejl i en applikation.
Cache
En mekanisme, der midlertidigt gemmer data for at gøre applikationen hurtigere. Det er ofte også kilden til mange mystiske problemer under test.
Opsummering
Jo længere vi arbejder som udviklere, desto mere når vi frem til én konklusion. De bedste udviklere er ikke dem, der begår færrest fejl.
De bedste udviklere kan:
- hurtigere finde årsagen til et problem,
- drage konklusioner,
- lære af andre,
- tage imod konstruktiv kritik,
- stadig udvikle deres håndværk.
Code Review er derfor ikke en hindring. Det er en af de mest værdifulde lektioner, man kan få i starten af sin karriere.
I den sidste del af vores serie vil vi tale om vejen fra Junior til Senior. Vi forklarer, hvorfor en Senior Developer ikke er en person med ti års anciennitet, men en, der kan tage ansvar for et projekt, tænke forretningsorienteret og hjælpe andre teammedlemmer med at udvikle sig.
