In de twee vorige delen van onze serie hebben we het over de eerste stappen in het beroep van programmeur gehad en over wat je in het begin van je carrière het beste kunt leren.
Nu komen we bij het moment waar bijna iedere Junior tegen op ziet.
De eerste Code Review. De eerste opmerkingen bij je code. De eerste aanpassingen.
En de eerste gedachte: "Heb ik die code echt zo slecht geschreven?"
Rustig aan.
Iedereen van ons is hier ooit doorheen gegaan.
Code Review is geen examen
Dat is waarschijnlijk het grootste misverstand onder beginnende programmeurs.
Veel Juniors ervaren opmerkingen over hun code heel persoonlijk. Er ontstaat stress. Onzekerheid. Soms zelfs frustratie.
Terwijl het doel van Code Review niet is om iemand te bewijzen dat hij een fout heeft gemaakt. Integendeel. Het is een van de belangrijkste onderdelen van het proces om goede software te maken.
Dankzij Code Review:
- verminderen we het risico op fouten,
- verbeteren we de leesbaarheid van de code,
- leren we van elkaar,
- zorgen we voor consistentie in het hele project,
- dragen we kennis over tussen teamleden.
De beste teams zien Code Review niet als controle. Ze zien het als dagelijkse kennisuitwisseling.
"Je hebt 37 opmerkingen"
Klinkt angstaanjagend? In het begin wel.
De eerste Pull Request ziet er vaak precies zo uit:
- Opmerking.
- Correctie.
- Nog een opmerking.
- Nog een correctie.
Na een uur heb je het gevoel dat de hele code weggegooid moet worden. Dat is normaal.
Onthoud maar één ding. Een Senior past code niet aan om zijn superioriteit te tonen. Hij doet het omdat jij over een paar maanden veel betere code zult schrijven.
En daar draait het juist om.
Een goede Senior zegt niet alleen "fout"
De beste programmeurs waarmee we hebben gewerkt, legden altijd uit:
- waarom iets beter op een andere manier gedaan kan worden,
- wat de consequenties van de huidige oplossing zullen zijn,
- welke alternatieven er bestaan,
- welke oplossing makkelijker te onderhouden zal zijn over een jaar of twee.
Dat is een wereld van verschil.
Want je kunt zeggen: "Dit is fout."
Of je kunt zeggen: "Dit werkt, maar als we dit module over een half jaar verder gaan ontwikkelen, wordt het veel makkelijker te onderhouden in deze structuur."
In het tweede geval leer je iets veel waardevollers dan alleen de correctie. Je leert een manier van denken.
Clean Code betekent niet mooie code
Dit is opnieuw een begrip dat vaak verkeerd wordt begrepen.
Clean Code betekent niet dat code er indrukwekkend uitziet. Het gaat niet om het aantal lege regels. Het gaat niet om de lengte van functies. Het gaat zelfs niet per se om specifieke patronen.
Het gaat om iets veel eenvoudigers - de code moet leesbaar zijn.
Als je over een half jaar je eigen project opent en je je niet meer herinnert wat je toen bedoelde...
...dan was de code waarschijnlijk niet voldoende leesbaar.
Er is een gezegde: We schrijven code voor mensen. De compiler controleert alleen de syntaxis.
En daar zit veel waarheid in.
Val niet verliefd op je eigen code
Dit is een van de belangrijkste lessen.
Code is geen kunstwerk. Het is geen schilderij. Het is geen beeldhouwwerk.
Het is een hulpmiddel om een specifiek probleem op te lossen.
Als iemand een betere oplossing voorstelt...
...zou je het moeten overwegen.
Niet omdat die persoon meer gezag heeft. Omdat het misschien écht beter is.
De meeste leren het meest die programmeurs die kunnen zeggen: "Je hebt gelijk. Laten we het anders doen."
"Bij mij werkt het"
Oké. We moesten uiteindelijk bij die beroemde zin komen. Elk softwarehuis heeft z’n eigen versie van die grap...
Stel je de situatie voor.
De tester meldt een fout.
De programmeur antwoordt: "Bij mij werkt het."
De tester controleert nogmaals. - Het werkt niet.
De Project Manager kijkt. - Het werkt niet.
De klant controleert ook. - Het werkt niet.
Maar... bij de auteur van de code werkt het nog steeds.
Klinkt dat bekend?
Meestal ligt het probleem niet in de code zelf.
Er kunnen veel oorzaken zijn:
- andere data versie,
- een andere omgeving,
- cache,
- configuratie,
- rechten,
- browser,
- besturingssysteem,
- een geval dat niemand eerder had voorzien.
Daarom stopt een professionele programmeur de analyse niet bij de zin: "Bij mij werkt het."
Hij stelt de volgende vraag.
Waarom werkt het bij mij, maar ergens anders niet?
En dan begint het echte debuggen.
"Het is maar een kleine wijziging"
Dit is weer zo’n zin die in de meeste softwarehuizen een lichte glimlach oproept.
De klant zegt: "Het is maar een kleine aanpassing."
De programmeur weet al dat hij zo meteen een bestand opent dat al zes jaar niet is aangeraakt.
En die "kleine aanpassing" blijkt wijzigingen in vijf modules, drie integraties en twee databases te veroorzaken.
Daarom gaan ervaren programmeurs heel voorzichtig om met het woord "maar".
De bekendste uitspraken uit de branche
Elk beroep heeft z’n eigen gezegden. Programmeurs ook.
Een paar daarvan kent bijna iedereen:
- "Bij mij werkt het."
- "Het duurt maar vijf minuten."
- "Het is geen bug. Het is een feature."
- "Ik heb toch niets veranderd."
- "Op productie stortte het in."
- "Nog één deploy dan."
- "Het is vast de cache."
- "Snel nog een fix voor het weekend."
- "Dit zou moeten werken."
En waarschijnlijk het gevaarlijkste: "We gooien dit vrijdag na 16:00 op productie."
Als je in IT werkt...
...dan heb je waarschijnlijk nét even glimlachend gelezen.
Een programmeur werkt niet alleen
Dit onderwerp wordt vaak over het hoofd gezien. In werkelijkheid is het grootste deel van projecten teamwerk.
Een programmeur werkt samen met:
- UX-designers,
- UI-designers,
- projectmanagers,
- testers,
- DevOps,
- systeembeheerders,
- analisten,
- klanten.
Daarom zijn net zo belangrijk als technische kennis:
- communicatie,
- luistervaardigheid,
- kennisoverdracht,
- verantwoordelijkheid,
- wederzijds respect.
De beste code redt een project niet als het team niet met elkaar kan samenwerken.
Woordenlijst
Code Review
Het proces waarbij andere programmeurs de code controleren voordat deze wordt uitgerold. Het doel is de kwaliteit van de code te verbeteren, fouten te vinden en kennis te delen.
Pull Request (PR)
Een voorstel om wijzigingen in het project door te voeren. Dit is meestal het moment waarop Code Review plaatsvindt.
Clean Code
Een benadering van coderen waarbij leesbaarheid, eenvoud en onderhoudbaarheid centraal staan, niet het aantal toegepaste ontwerppatronen.
Debugging (Debuggen)
Het proces van het opsporen en verhelpen van de oorzaken van fouten in een applicatie.
Cache
Een mechanisme dat gegevens tijdelijk bewaart om de prestaties van de applicatie te versnellen. Het is vaak ook de bron van veel raadselachtige problemen tijdens het testen.
Samenvatting
Hoe langer we als programmeurs werken, hoe meer we tot één conclusie komen. De beste developers zijn niet degenen die de minste fouten maken.
De beste developers kunnen namelijk:
- sneller de oorzaak van een probleem vinden,
- conclusies trekken,
- van anderen leren,
- constructieve kritiek aannemen,
- hun vakmanschap voortdurend verbeteren.
Code Review is dus geen obstakel. Het is een van de meest waardevolle lessen die je aan het begin van je carrière kunt krijgen.
In het laatste deel van onze serie zullen we bespreken hoe de weg van Junior naar Senior eruitziet. We leggen uit waarom een Senior Developer niet iemand is met tien jaar ervaring, maar iemand die verantwoordelijkheid voor een project kan nemen, zakelijk kan denken en anderen in het team kan helpen groeien.
