Tag software ontwikkelen

Grote refactorslagen ondermijnen vertrouwen

Wat een stakeholder betreft is een grote refactorslag een enorme kostenpost zonder aantoonbaar resultaat. Een team dat erop staat niet verder te kunnen werken zonder eerst een hele tijd heel veel geld uit te geven – nota bene zonder daar iets voor terug te geven! –, ondermijnt het vertrouwen dat de stakeholder hen daarmee geeft.

Functioneel denken: een praktijkvoorbeeld

Onlangs hielp ik een collega een moeilijk volgbare berg code te reduceren tot enkele eenvoudig leesbare regels. Door onze oorspronkelijke, imperatieve redeneertrant van ons af te werpen, en deze te vervangen door een declaratieve stijl, reduceerden we het netelige origineel tot een elegante functionele oplossing. – Het was een schoolvoorbeeld van de kracht van functioneel denken.

Technieken vs trucjes

Een goede programmeur is een luie programmeur – dat is een bekende wijsheid in softwareontwikkelland. Want: een luie programmeur automatiseert oninteressante, repetitieve taken, en creëert op die manier de ruimte om zich bezig te houden met interessante, afwisselende taken. – Althans, dat is één opvatting van wat het betekent om een luie programmeur te zijn. Maar er zijn nog veel meer manieren om lui te zijn. Vandaag wil ik het hebben over zo’n andere manier. Vandaag wil ik het hebben over de wens, behoefte of neiging om een techniek te reduceren tot een trucje.

Hoe we onze Controllers dom houden

Onlangs schreef ik over Controllers en de manier waarop mijn team ervoor zorgde dat er zo min mogelijk logica in die dingen terechtkwam. Onze opzet had impact op de manier waarop we onze logica structureerden. Het betekende dat de methods in onze services exceptions op moesten gooien zodra deze van het succespad afwijkten. Je kunt zo je vraagtekens zetten bij deze oplossingsrichting – en dat deden we uiteindelijk ook.

Hoe we onze Controllers dom hielden

Het is zaak je Controller-methods zo compact, zo “dom” mogelijk te houden. Valerio De Sanctis' Building Web APIs with ASP.NET Core deed me denken aan de verschillende manieren waarop mijn team dat de afgelopen jaren voor elkaar heeft proberen te krijgen. Want het dom houden van je Controllers – zonder aan expressiviteit in te boeten – is geen triviale zaak. Vandaag: hoe het niet moet.

Testen: een retrospectief in vijf fasen

Het leek me zinvol om te reflecteren op de ontwikkeling die mijn team en ik door hebben gemaakt op het gebied van testen. Want – en dat is goed nieuws – de manier waarop we het testen van onze software aanvliegen is radicaal veranderd sinds ik begon als ontwikkelaar.

Overerving, compositie en dependency injection

Mijn collega had overerving toegepast om de nieuwe functionaliteit een plek te kunnen geven. De afgelopen maanden had ik gemerkt dat dit voor hem, en veel van mijn andere teamgenoten, een go to-oplossing vormt om code te kunnen hergebruiken. Maar ik was niet helemaal tevreden met het resultaat van die strategie. Ik voelde meer voor een oplossing die gebruik maakt van compositie. Het leek me een mooie gelegenheid om wat ideeën over deze concepten op papier te zetten.

Revert!

Drie dagen hebben we de boel lopen te debuggen. Bij elke nieuwe wijziging leken we verder te zakken in een onverklaarbaar moeras van verborgen afhankelijkheden. Op een gegeven moment was ik het zat. Ik zei: “Ik ga de boel terugdraaien.” (Mijn collega, verslagen, zag al zijn harde werk voor zijn ogen in vlammen opgaan.) “Niet alles, maar wel alles in die ene class. En dan ga ik je wijziging één voor één opnieuw toepassen, net zolang totdat er tests falen.”

Schone interfaces, simpele implementaties

Het dilemma was als volgt: ofwel de deadline missen met een “goede” oplossing (dat wil zeggen: een oplossing die de REST-standaard volgt), ofwel de deadline halen met een slechte (die een uitzondering introduceert in de opzet van onze API). Maar: dat is een vals dilemma.

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.