Tag Refactoren
Moeten refactorings ook gereviewd worden?
Niet elke codewijziging is gelijk. Sommige wijzigingen veranderen het gedrag van een systeem. Andere wijzigingen, refactorings, veranderen alleen de structuur en laten het gedrag gelijk. Zoals de meeste teams hun werk inrichten, met pull requests en formele code reviews, wordt elke wijziging door twee paar ogen bekeken. Maar is dat wel nodig?
Een ontwikkelaar is verantwoordelijk voor drie systemen
Ik weet niet meer waar ik de inval had, onder de douche of op de wc of tijdens het tanden poetsen (duidelijk is in elk geval dat het op de badkamer was): een ontwikkelaar is verantwoordelijk voor (ten minste) drie systemen.
Refactoren is als fitnessen
Laatst zei mijn vrouw tegen me: “Hé, je vetkwab is weg!” Maar toen keek ze iets langer en vervolgde: “Nou ja, bijna.” – Wat ik bedoel te zeggen is: het gaat de goede kant op. Ik doe wat aan lichaamsbeweging de laatste tijd, een beetje fitness. Het deed me, omdat ik een beroepsdeformatie heb, aan refactoren denken.
Wat is refactoring (volgens Hannah Arendt)?
Wat kunnen Hannah Arendts filosofische overpeinzingen ons leren over refactoring? Nou, bijvoorbeeld waarom de metafoor van technische schuld een misleidende is. Maar als refactoring niet het afbetalen van technische schuld is, wat is het dan wel? En wat betekent dat voor de rol die refactoring in onze dagelijkse werkzaamheden in mag (of moet?) nemen?
What is refactoring (according to Hannah Arendt)?
What can Hannah Arendt’s philosophical reflections teach us about refactoring? Well, for one thing, why the metaphor of technical debt is misleading. But if refactoring isn’t about paying off technical debt, what then is it? And what does that mean for the role refactoring can (or should?) play in our daily work?
Wie is er bang voor adapterfuncties?
Adapters zijn een bekend ontwerppatroon in de softwareontwikkeling. Toch kwam deze oplossingsrichting niet onmiddellijk bij me op toen ik een stuk code in onze zoekindex begon te refactoren (om van de oorspronkelijke schrijver nog maar te zwijgen!). In plaats daarvan gaven onze eerste pogingen er blijk van koste wat kost te willen blijven werken met de “standaard”-functies. – Waarom?
Het ontologische argument
Onlangs pairde ik met een nieuwe collega. We hadden een refactortaak opgepakt om wat ondoorgrondelijke code rondom onze zoekindex te versimpelen. Ergens halverwege die refactorslag zei hij iets wat mijn aandacht trok.
Aanpassen of: toevoegen, vervangen en verwijderen
Laatst wilde ik een methodsignatuur op een interface aanpassen. Een naïeve manier om dat aan te pakken, zou zijn: pas de signatuur op de interface aan, kijk naar de compilatiefouten die dat oplevert op de implementerende classes, en werk die weg. – Maar het probleem van die aanpak is dat dit de codebase voor langere tijd in een gebroken staat houdt.
Meer refactoring en Hannah Arendt
Wanneer ontwikkelaars refactortaken apart inplannen of refactoren nalaten omdat ze er geen toestemming voor hebben, dan is dat een teken dat ze de activiteit van het refactoren fundamenteel verkeerd begrijpen. Helaas is dat misbegrip stevig verankerd in de wereld van de softwareontwikkeling dankzij de metafoor van technische schuld.
Ik loste het op met een monad
Een soort van monad. Denk ik.