Tag refactoren

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.

Bind, Map en Match

Ik schrijf al twee jaar op dit blog over functioneel programmeren in C#, dus je zou denken dat ik de basis inmiddels wel een beetje zou moeten beheersen – en toch overkomt het me nog regelmatig dat ik uitroep: och, zit het zo! Zo had ik onlangs – na een hoop gepiel (en een beetje hulp van Scott Wlaschin) – een openbaring met betrekking tot de Map- en Bind-functies.

Refactoring en Hannah Arendt

Yvonne Lam stelt dat er een betere metafoor voorhanden is voor dat wat we gewoonlijk “technische schuld” noemen: huishouding (housework). Het deed me aan Hannah Arendt denken. – Beroepsdeformatie, denk ik!

Gedrag versus structuur

Een systeem dat niet precies doet wat het moet doen, maar wel eenvoudig aan te passen is, is meer waard dan een systeem dat precies doet wat het moet doen maar slechts met grote moeite gewijzigd kan worden. Want het gedrag van een systeem zal veranderen, hoe dan ook. De wereld verandert, en daarmee de wensen van onze gebruikers en stakeholders. Het is onze taak als softwareontwikkelaars om daarop voorbereid te zijn, en een systeem te ontwikkelen dat daarop voorbereid is.

Refactoring als communicatiemiddel

We refactoren niet alleen om het makkelijker te maken de code te wijzigen, we refactoren ook om de code zo helder mogelijk te laten communiceren. En code die helder communiceert is op zijn beurt weer makkelijker om te wijzigen.

Wat zegt deze test?

“Wat zegt deze test?” – Het meest voor de hand liggende antwoord is natuurlijk: wat de code doet. Maar dat is slechts wat een test expliciet zegt, de informatie die een test inhoudelijk overbrengt. Dat is niet het enige wat het zegt – verre van.

Wat zegt deze code?

De namen in onze code – van variabelen, velden, methoden, parameters – beschrijven wat de code doet. De naam van een class beschrijft haar wezen: integer, Url, ResourceHelper. Anders dan bij mensen gaat de existentie van code niet vooraf aan haar essentie. Code is bepaald, bepaald door haar functie. Wat die functie is, weet een goede programmeur in een naam te vangen.

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.