Tag refactoren
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.
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.
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.
Callback hell
In mijn werk als C#-ontwikkelaar maak ik veelvuldig gebruik van functionele programmeerconcepten. Als een functie me een object T teruggeeft of niet, dan codeer ik dat netjes in de signatuur van die functie door een Option<T> terug te geven. Dat dwingt de aanroepende partij om beide scenario’s expliciet af te handelen. Hartstikke handig! – Maar: niet zonder zijn eigen set problemen. Want wat gebeurt er als je meerdere functies achter elkaar aanroept die allemaal een Option<T> teruggeven? Dan komen we terecht in wat men callback hell noemt.
Meer over refactoren
Waarom wil je refactoren? – dat is de eigenlijke vraag, natuurlijk. Je wil refactoren omdat de code iets moet kunnen wat het nu nog niet kan, en omdat de structuur van de code moet worden voorbereid op dat wat straks moet kunnen. Je wil refactoren omdat je met je code wil werken, of in – maar in elk geval niet tegen.
Een herwaardering van Fowlers Refactoring
Martin Fowlers Refactoring is een klassieker in het genre – en baanbrekend voor zijn tijd. Boeken over het ontwerp van nieuwe software bestaan al zo lang als dat software bestaat. Maar het idee dat je bestaande code aan kon passen – niet als noodzakelijk kwaad, maar als essentiële vaardigheid van elke programmeur –, dat was ongekend. – En toch was ik teleurgesteld toen ik het boek uitlas, drie jaar geleden.
De verplichte ChatGPT-blog
Met hulp van ChatGPT wist ik in een uurtje het functionele equivalent te leveren van code waar ik eerder dagen op heb zitten zwoegen. De tijdwinst is onomstotelijk. En op het vlak van informatieoverdracht is ChatGPT een ons “echte” ontwikkelaars mijlenver vooruit.
Waarom ik die method dupliceer
Een collega keek over mijn schouder mee. Ik was zojuist bezig met een bugfix, dus ik schreef een test, zag ’m falen en navigeerde naar de plek waar ik mijn aanpassing meende te moeten doen. Ik hernoemde de method, plakte er de suffix _old achteraan. Daarna dupliceerde ik het geval, en bracht mijn wijziging aan in het duplicaat. Mijn collega vroeg me: “Wacht, waarom doe je dat?” Nou…
Refactoren als context switch
Context switching heeft een slechte naam in softwareontwikkelland en dat is niet helemaal onterecht. Het is enorm vervelend als je nét lekker aan het programmeren bent – om vervolgens weggeroepen te worden voor een snelle vraag of ellenlange vergadering (die ook een e-mail had kunnen zijn). Op dat moment raak je alle informatie kwijt die je in je hoofd hebt opgebouwd om een probleem te kunnen tackelen, en mag je opnieuw beginnen. Maar dat is maar de helft van het verhaal.