I de två tidigare delarna av vår serie pratade vi om de första stegen i utvecklaryrket och om vad som verkligen är värt att lära sig i början av karriären.
Nu når vi det ögonblick som nästan varje junior oroar sig för.
Första Code Review. Första kommentarerna till koden. Första ändringarna.
Och den första tanken: "Har jag verkligen skrivit koden så dåligt?"
Lugnt.
Vi har alla gått igenom det någon gång.
Code Review är inte ett prov
Det är nog det största missförståndet bland nybörjarprogrammerare.
Många juniorer tar kommentarer till sin kod väldigt personligt. Stress uppstår. Osäkerhet. Ibland även frustration.
Men målet med Code Review är inte att bevisa för någon att den gjort fel. Tvärtom. Det är en av de viktigaste delarna i processen att skapa bra programvara.
Tack vare Code Review:
- minskar vi risken för buggar,
- vi förbättrar kodens läsbarhet,
- vi lär oss av varandra,
- vi tar hand om projektets konsistens,
- vi sprider kunskap mellan teammedlemmar.
De bästa teamen ser inte Code Review som kontroll. De ser det som daglig erfarenhetsutbyte.
"Du har 37 kommentarer"
Låter skrämmande? I början gör det det.
En första Pull Request ser ofta ut just så här:
- Kommentar.
- Ändring.
- Ytterligare en kommentar.
- Ytterligare en ändring.
Efter en timme känns det som om hela koden borde kastas bort. Det är normalt.
Kom bara ihåg en sak. En senior ändrar inte din kod för att visa sin överlägsenhet. Hen gör det för att om några månader kommer du att skriva mycket bättre kod.
Och det är precis vad det handlar om.
En bra senior säger inte bara "fel"
De bästa utvecklarna vi har jobbat med förklarade alltid:
- varför något bör göras annorlunda,
- vilka konsekvenser den nuvarande lösningen får,
- vilka alternativ som finns,
- vilken lösning som blir lättare att underhålla om ett år eller två.
Det är en enorm skillnad.
Man kan säga: "Det här är fel."
Eller så kan man säga: "Det fungerar, men om vi ska vidareutveckla den här modulen om ett halvår kommer det bli mycket lättare att underhålla i den här strukturen."
I det andra fallet lär du dig något mycket värdefullare än själva ändringen. Du lär dig ett sätt att tänka. Du lär dig tänkesättet.
Clean Code betyder inte vacker kod
Det är ännu ett begrepp som ofta missförstås.
Clean Code betyder inte kod som ser imponerande ut. Det handlar inte om antalet tomma rader. Inte om funktionslängd. Inte ens om specifika mönster.
Det handlar om något mycket enklare - koden ska vara läsbar.
Om du om ett halvår öppnar ditt eget projekt och inte kommer ihåg vad du tänkte...
...så var koden troligen inte tillräckligt läsbar.
Det finns ett talesätt: Vi skriver kod för människor. Kompilatorn kontrollerar bara syntaxen.
Det ligger mycket sanning i det.
Bli inte förälskad i din egen kod
Det är en av de viktigaste lärdomarna.
Kod är inte konstverk. Det är inte en tavla. Det är inte en skulptur.
Det är ett verktyg för att lösa ett konkret problem.
Om någon föreslår en bättre lösning...
...så är det värt att överväga.
Inte för att personen har större auktoritet. Utan för att det kanske faktiskt är bättre.
De som lär sig mest är ofta de utvecklare som kan säga: "Du har rätt. Låt oss göra det annorlunda."
"Det funkar hos mig"
Okej. Vi måste till slut ta upp den berömda meningen. Varje software house har sin version av det skämtet...
Föreställ dig följande situation.
Testaren rapporterar ett fel.
Utvecklaren svarar: "Det funkar hos mig."
Testaren kollar igen. - Det fungerar inte.
Projektledaren kikar. - Det fungerar inte.
Kunden kollar också. - Det fungerar inte.
Men... hos kodens författare fungerar det fortfarande.
Låter det bekant?
Vanligast är att problemet inte ligger i själva koden.
Det kan finnas många orsaker:
- annorlunda data,
- annorlunda miljö,
- cache,
- konfiguration,
- behörigheter,
- webbläsare,
- operativsystem,
- ett fall som ingen tidigare förutsett.
Därför slutar en professionell utvecklare inte analysen vid meningen: "Det funkar hos mig."
Hen ställer nästa fråga.
Varför funkar det hos mig men inte någon annanstans?
Och det är då den verkliga felsökningen börjar.
"Det är bara en liten ändring"
Det är ytterligare en fras som väcker ett svagt leende i de flesta software houses.
Kunden säger: "Det är bara en liten fix."
Utvecklaren vet redan att hen kommer öppna en fil som ingen rört på sex år.
Och den där "lilla fixen" visar sig vara en förändring i fem moduler, tre integrationer och två databaser.
Därför är erfarna utvecklare mycket försiktiga med ordet "bara".
De mest kända fraserna i branschen
Varje yrke har sina uttryck. Utvecklare också.
Några av dem känner nog alla igen:
- "Det funkar hos mig."
- "Det tar bara fem minuter."
- "Det är inte en bugg. Det är en feature."
- "Jag ändrade ju inget."
- "Det kraschade i produktion."
- "Bara en deployment till."
- "Det är säkert cache."
- "En snabb fix innan helgen."
- "Det borde funka."
Och kanske det farligaste: "Vi lägger ut det i produktion på fredagen efter kl. 16:00."
Om du jobbar i IT...
...så log du nog precis.
En utvecklare arbetar inte ensam
Det här ämnet förbises ofta. I verkligheten är de flesta projekt ett lagarbete.
En utvecklare samarbetar med:
- UX-designers,
- UI-designers,
- projektledare,
- testare,
- DevOps,
- administratörer,
- analytiker,
- kunder.
Därför är lika viktiga som teknisk kunskap också:
- kommunikation,
- förmågan att lyssna,
- att dela kunskap,
- ansvarstagande,
- ömsesidig respekt.
Den bästa koden räddar inte ett projekt om teamet inte kan samarbeta.
Ordlista
Code Review
Processen där andra utvecklare granskar kod innan den deployas. Syftar till att förbättra kodkvaliteten, hitta fel och dela kunskap.
Pull Request (PR)
Ett förslag att införa ändringar i projektet. Det är oftast här Code Review sker.
Clean Code
En syn på kodskrivande där huvudmålet är läsbarhet, enkelhet och underhållbarhet, inte antalet använda designmönster.
Debugging (felsökning)
Processen att hitta och åtgärda orsaker till fel i en applikation.
Cache
En mekanism som tillfälligt lagrar data för att snabba upp applikationen. Kan också vara källan till många förbryllande testproblem.
Sammanfattning
Ju längre vi arbetar som utvecklare, desto mer kommer vi till samma slutsats. De bästa utvecklarna är inte de som gör minst misstag.
De bästa utvecklarna kan:
- snabbare hitta orsaken till ett problem,
- dra slutsatser,
- lära sig av andra,
- ta emot konstruktiv kritik,
- ständigt utveckla sitt hantverk.
Code Review är alltså inte ett hinder. Det är en av de mest värdefulla lektionerna man kan få i början av sin karriär.
I den sista delen av vår serie kommer vi att prata om vägen från junior till senior. Vi kommer att förklara varför en senior utvecklare inte är någon med tio års erfarenhet, utan någon som kan ta ansvar för ett projekt, tänka affärsmässigt och hjälpa andra teammedlemmar att växa.
