Tag code reviews
Imperatieve Options?
Ik gebruik Options graag, ze voorkomen een hoop foutmeldingen. Maar, belangrijker nog, ze maken mijn code expressiever en eleganter. Of liever: ze hebben de potentie dat te doen. Laatst kwam ik tijdens een codereview een functie tegen, waarop mijn primaire reactie was: dit moet anders. – Maar waarom?
Immutability en het Single-Responsibility Principe
Het correct – en dus volledig – instantiëren van een object is één verantwoordelijkheid. Het geïnstantieerde object gebruiken is een andere. Wie beide met elkaar vermengt, schrijft onnodig complexe code. Dat is waarom we er naar moeten streven onze objecten nooit aan te willen passen.
De edele kunst van het pull request
Veel ontwikkelaars zien code reviews als een hinderlijke onderbreking van hun werkzaamheden. Maar het goed kunnen beoordelen van een codewijziging is essentieel om de kwaliteit van een codebase op peil te houden. Gelukkig hoeft dit proces niet pijnlijk te zijn. Aan het eind van deze sessie weet je welke vragen je moet stellen voor een geslaagde code review – en hoe je deze informatie zo effectief mogelijk overbrengt in je PR.
Blog #250!
Jeetje, ik blog alweer een tijdje! Er zijn 767 dagen voorbij gegaan sinds ik mijn honderdste blog schreef. Dus: feest! Vandaag blik ik terug op de laatste 150 blogs.
Waarom testers code moeten reviewen
Het klinkt als een natuurwet: programmeurs programmeren en testers testen. Maar die taakverdeling leidt tot inefficiënte werkprocessen met lange feedbackcycli. Om kwaliteit én snelheid te kunnen borgen, moet geautomatiseerd testen een tweede natuur worden voor het hele ontwikkelteam. Testers spelen hier een essentiële rol in.
Drie feedbackloops die verbeteren met unit tests
Ik ben geneigd te zeggen: alles in het leven wordt beter met unit tests – en dat toont hoe ver ik inmiddels van het padje ben geraakt. – Maar op het gebied van softwareontwikkeling gaat die vlieger wel degelijk op. Toen ik voor het Najaarsevenement van TestNet begon uit te werken waarom testers code zouden moeten reviewen, stuitte ik op drie feedbackloops die geautomatiseerde tests kunnen versnellen.
Erfenissen van waterval
Op het Najaarsevenement van TestNet betoogde ik dat testers een belangrijke rol hebben te spelen in het reviewen van code. Tijdens de voorbereiding van mijn presentatie realiseerde ik me dat mijn team, alle Agile ambities ten spijt, in zijn denken nog diep verankerd zit in het gedachtegoed van de watervalopvatting van softwareontwikkeling.
Nog enkele reflecties op pull requests
Onlangs hield ik een praatje op het werk over de edele kunst van het pull request. Het gesprek dat naar aanleiding daarvan ontstond, vond ik erg waardevol. Het geven van een goede presentatie werkt in bepaalde zin net als software ontwikkelen: je maakt een eerste versie, legt die voor aan een groep mensen, en gebruikt hun feedback om een betere tweede versie te ontwikkelen.
Drie vragen die elk pull request moet beantwoorden
Schrijvers van pull requests zijn over het algemeen helemaal niet zo goed in het overbrengen van alle informatie die een lezer nodig heeft om deze goed te kunnen beoordelen. Want de meeste schrijvers weten überhaupt nauwelijks welke informatie er nodig is om dat te kunnen doen. In mijn beleving moet een PR antwoord geven op drie vragen.
Mijn eerste code review
De tijd maakt alles kapot – maar nu ben ik nog jong genoeg om me mijn eerste code review te herinneren. Althans, ik herinner me een gevoel – want de inhoud van het pull request ben ik natuurlijk allang kwijt. Het gevoel laat zich denk ik het best omschrijven als een vorm van hulpeloosheid – gevolgd door ongemak.