Enums, switch statemens en SOLID - deel 6

Conclusie

De afgelopen weken heb ik een stuk code gerefactord om meer in lijn te zijn met SOLID-principes. Door gebruik te maken van Single-Responsiblity, Dependency inversion en het Open-closed principe, hebben we de code makkelijker onderhoudbaar gemaakt, zonder de performance van die code te hoeven offeren. De conclusie is dus duidelijk: verwerk de SOLID-principes in je code!

Zeker als het op nieuwe code aankomt, heb je geen excuus om SOLID niet mee te nemen in je ontwerpproces. Maar hoe zit het met bestaande code? Moet je alles laten vallen waar je mee bezig bent, en je bestaande code base onder handen nemen om alle enum-gebaseerde switch statements eruit te refactoren?

Wat je je af moet vragen vóórdat je gaat refactoren

Die vraag is moeilijk met een “ja” of “nee” te beantwoorden. Eigenlijk is het antwoord hier hetzelfde als altijd in softwareontwikkelland: it depends. Ga voor jezelf de volgende punten eens na.

Is de code geunittest?

Zo ja, mooi! De aanwezigheid van unittests is een voorwaarde voor elke refactorslag.

Zo nee, doe het dan alsjeblieft niet. Het aantal applicaties dat om zeep geholpen is door goedbedoelde “verbeteringen” aan de code base is ontelbaar, en een gebrek aan unittests is eigenlijk altijd debet daaraan. Als je niet snel en makkelijk kunt controleren of je code hetzelfde blijft functioneren na een wijziging, is deze onderneming eenvoudigweg te risicovol.

Verandert de code vaak?

Zo ja, doen! Als je veel in de code moet werken, dan is het de moeite waard om ervoor te zorgen dat deze zo onderhoudbaar mogelijk is. Bovendien hoef je voor deze refactorslag niet apart tijd voor vrij te maken, je kunt deze meenemen tijdens het implementeren van een nieuwe feature.

Let er wel op dat je dan altijd in twee stappen werkt: eerst refactoren en dan pas de nieuwe feature implementeren. Door beide tegelijkertijd te doen, maak je het jezelf - en je teamgenoten die je code zullen reviewen! - alleen maar moeilijker. (Je ziet: ook in het proces van software ontwikkelen bestaat er een Single-Responsibility principe!)

Verandert de code echter niet of nauwelijks, laat het dan voor wat het is. Lelijke werkende code is aan het eind van de dag misschien lelijk, maar hij werkt wel. Zo lang de code geen ontwikkelaar in de weg zit, is het eenvoudigweg niet de moeite waard eraan te komen.

Is de impact van de refactorslag groot?

Heb je niet één plek met een enum-gebaseerd switch statement, maar wel tien? (Belangrijk is dat het daarbij ook tien keer om dezelfde enum gaat.) Dan kan een refactorslag de moeite waard zijn.

Maar let op: hoe groter de impact van je codewijzigingen, hoe beter beslagen je ten ijs moet komen. De toegevoegde waarde van je refactorslag neemt toe met de hoeveelheid code die je opschoont, maar hetzelfde geldt voor de risico’s. Wie één switch statement breekt, mag één switch statement repareren. Wie er tien tegelijkertijd breekt…

Zorg ervoor dat je haalbare doelen stelt. Het enige dat erger is dan een brok lelijke code, is een half opgepoetst brok lelijke code. Halve refactorslagen houden de slechte kanten van de oorspronkelijke code in stand én voegen extra onderhoudslast toe in de vorm van een tweede oplossing.

Past het opschonen van de code binnen de prioriteiten je stakeholders op dit moment hebben?

Zo ja, ruim dan absoluut tijd in om je code base continu op te schonen. Jijzelf, je collega’s en uiteindelijk je stakeholders zullen je er dankbaar voor zijn.

Nadert er echter een deadline, en kun je je Product Owner er met geen mogelijkheid van overtuigen dat refactoring zich op dit moment loont? Laat het voor nu dan wat het is. Focus je op dit moment op de belangrijkste zaken.

Je hoeft het daar echter niet bij te laten zitten. Breng ondertussen de impact en waarde van je voorgestelde refactorslag in kaart, zodat je je PO op een later moment kunt overtuigen om dit alsnog te prioriteren. Hoe je dat aanpakt? Refactoring at Scale van Maude Lemaire is een uitstekend boek over alles wat bij grootschalige refactoring komt kijken.

Nog één dingetje…

Daarmee komen we aan het eind van deze reeks blogs. Zoals altijd: wie de code in al haar iteraties nog eens na wil kijken, kan terecht op GitHub.

Er zit me alleen nog één dingetje dwars aan de uiteindelijke implementatie. En dat is die verdomde naam, ClaimsHelper, die ik (in aangepaste vorm) heb overgenomen uit onze eigen code base. Het valt misschien buiten het domein van de SOLID-principes, maar in hemelsnaam… noem je classes geen ...Helper!

Heb jij een betere suggestie voor de naam van deze class?

Meer in deze reeks

1. De casus
2. Het Single-Responsibility principe
3. Het Dependency inversion principe
4. Het Open-closed principe
5. SOLID en performance
6. Conclusie
7. Addendum: Slimmere Enums

clean code · enums · refactoren · solid · switch statements