Tag intentie van code
Hoe droog wil je je test hebben?
Ik heb in het verleden over droger tests geschreven, want ik ben een softwareontwikkelaar en wij herhalen onszelf niet graag. En precies daarom ga ik het nóg een keer over droger tests hebben - of liever: minder droge tests. Want, anders dan je als naïeve ontwikkelaar zou verwachten, gelden er voor productiecode en testcode andere regels wat betreft de mate waarin herhaling tolerabel of zelfs wenselijk is.
Code reviews als leermiddel
Toen ik begon als softwareontwikkelaar, was ik eerlijk gezegd een beetje bang voor code reviews. Inmiddels zijn de rollen omgedraaid, en zijn mijn collega’s banger voor mijn code reviews dan ik voor die van hen. Feit is dat ik een stuk scheutiger ben met mijn opmerkingen dan mijn collega’s. Toch denk ik dat er in mijn commentaar maar weinig is om bang voor te zijn. Ik zie code reviews namelijk niet als middel en moment om kritiek te geven op andermans code. Of liever: niet alleen als middel en moment om kritiek te geven.
Dertig seconden winst in twee commits
Eén enkele commit was voldoende om de latency van een cruciale call naar onze back-end te verlengen van minder dan één seconde naar twintig tot dertig (!) seconden. Wat was er in hemelsnaam gebeurd?
Goede code documenteert zichzelf (niet)
Uit de code valt niet af te leiden wat de specificaties zouden moeten zijn. Om met David Hume (1711-1776) te spreken: een ought valt niet af te leiden uit een is. Wie zegt dat goede code zichzelf documenteert, maakt zich schuldig aan de naturalistische dwaling. En toch zit er een kern van waarheid in het idee dat goede code zichzelf documenteert.
Check op permissies, niet op rollen
Op een gegeven moment begon onze autorisatiecode uit de hand te lopen. De code in onze front-end was haast onleesbaar geworden van alle rollenchecks die de logica vervuilde. Erop terugkijkend, hadden we twee fouten gemaakt in onze oorspronkelijke implementatie. Ten eerste hadden we gebruikers de mogelijkheid gegeven meerdere rollen te hebben, en ten tweede bevonden onze checks zich op een te grof niveau.
Eenvoudige SQL versus performante SQL
Als ik zeg dat je al mijn kennis van SQL op de achterkant van een bierviltje kunt schrijven, dan overdrijf ik schromelijk. Maar twee bierviltjes, dat zou best kunnen. Toen ik onlangs de taak had een prachtig performante SQL-query uit te breiden, had dat nogal wat voeten in de aarde.
Bevat deze code een bug?
Is een meerkeuzevraag waarbij je nul antwoorden in mag vullen van het type Multiple Choice of Multiple Response - of geen van beide?