Onderhoudbaarheid tip 3: refactor met korte termijn doelen

Door Victor van der Hulst In Smart@Vantage

De afgelopen weken heb ik stilgestaan bij het belang van onderhoudbaarheid van maatwerk applicaties, hoe een Agile ontwikkelaanpak hieraan bijdraagt en hoe de mate van onderhoudbaarheid kan worden gemeten. In dit deel ga ik in op refactoring, het verminderen van de opgebouwde technical debt.

…is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
http://refactoring.com/

Nu de hoeveelheid technical debt objectief in beeld is (en blijft worden) gebracht, is het zaak de business verantwoordelijke (de product owner in Agile termen) hierover te informeren. Product Owners sturen vooral op functionaliteit door de druk uit de business/markt. Het is aan het ontwikkelteam om continu het effect van technical debt onder de aandacht te brengen. Door hier geen aandacht aan te schenken gaat gaandeweg steeds meer tijd zitten in het opsporen en oplossen van issues (en het creëren van nieuwe) waardoor er steeds minder nieuwe functionaliteit kan worden opgeleverd.

Application Lifecycle Management

Vanuit Application Lifecycle Management dient de mate van onderhoudbaarheid te worden bepaald. Een applicatie in het primaire proces met een langere levensduur moet
‘meebewegen’ met de business/markt om de businessdoelstellingen te blijven halen. Voor applicaties met een tijdelijk of eenmalig karakter ligt het belang van onderhoudbaarheid anders, al zijn er legio voorbeelden van ‘tijdelijke’ applicaties die gaandeweg een cruciaal onderdeel van de bedrijfsvoering werden.

“The act of leaving a mess in the code should be as socially unacceptable as littering.”
Robert C. “Uncle Bob” Martin

Refactor met korte termijn doelen

Met de gewenste mate van onderhoudbaarheid in het achterhoofd, wegen we vanaf nu bij elke wijziging of toevoeging aan de source code refactoring mee. Refactoring om het refactoren is af te raden. Er wordt dan alleen aan onderhoudbaarheid gewerkt zonder dat deze hogere onderhoudbaarheid ook direct loont in de aanpassing. Beter is het om te refactoren wanneer een deel van de code toch aangepast dient te worden vanwege een functionele wijziging.

Wanneer bijvoorbeeld een nieuw stuk functionaliteit een week kost om toe te voegen, en het eerst refactoren ook een week plus één dag voor het toevoegen van de functionaliteit, kies dan voor het laatste opdat ook toekomstige functionaliteit makkelijk is toe te voegen.

Enkele principes die zeer van nut zijn tijdens refactoring:

  • YAGNI
    Waak voor ‘premature optimizations’, en dan bedoelen we optimalisaties waarvan nog niet vaststaat dat deze daadwerkelijk nodig zijn. Veelal zorgt dit op voorhand voor complexere, slecht leesbare code die uiteindelijk niet nodig blijkt te zijn. Ook wel bekend als het YAGNI principe: You aren’t gonna need it.
  • Boy Scout Rule
    Simpel gezegd ‘Leave your code better than you found it.’ Padvinders kennen de simpele regel het kampeerterrein netter achter te laten dan ze het hebben aangetroffen. Een goed principe om te hanteren tijdens refactoring. Door elke keer dat code wordt gewijzigd deze netter achter te laten, neemt de onderhoudbaarheid toe en is de impact te overzien. Stapje voor stapje wordt het ‘schoner’. Waak ervoor niet in één keer voor perfectie te gaan, dat doen de padvinders ook niet.
  • No Museum
    Beschouw source code als de actuele beschrijving van de gemaakte functionaliteit. Dat betekent dat alle niet gebruikte, uit-gecommentarieerde code en commentaar verwijderd dient te worden. Dit zorgt alleen maar voor verwarring bij de ontwikkelaar die dit tegenkomt. Historie vind je in je code repository, niet in de source code.
  • DRY
    Het Don’t Repeat Yourself (DRY) principe voorkomt het dupliceren van source code wat er toe leidt dat de onderhoudbaarheid toeneemt. Immers, wijzigingen in dit stuk code dienen op twee plaatsen te worden doorgevoerd. In Object Oriented Programming is het paradigma: duplication in logic should be eliminated via abstraction; duplication in process should be eliminated via automation.

Waak voor herbouw

Naast deze tip sta ik graag nog stil bij de herbouwgedachte. Deze gedachte komt vaak bovendrijven wanneer de technical debt in de jaren flink is opgelopen (door weinig tot niet refactoren). De praktijk leert dat herbouw (greenfield) vaak niet tot kostenbesparing leidt en veel producten zien nooit het levenslicht. Tegelijkertijd impliceert het de volgende problemen: nieuwe code heeft zich nog niet in productie bewezen (risico), risico’s bij datamigratie van oud naar nieuw, fouten worden overgenomen of (extra) gemaakt, onduidelijkheid over impliciete functionaliteit (documentatie en code zijn niet gelijk) en veel tijdverlies door alle herbouw. Start dus niet opnieuw maar verbeter wat er is, zolang het technische platform dit mogelijk maakt. Bijvoorbeeld wanneer het gehele technische platform onhoudbaar is geworden zoals classic Visual Basic applicaties.

Meer weten over refactoring? Kijk eens op Pluralsight.

Volgende week sta ik stil bij de rol van testen. Ook de mate en wijze van testen heeft invloed op de onderhoudbaarheid van applicaties.

onderhoudbaarheid-tip-3-refactor-met-korte-termijn-doelen-blog-victor

Meer informatie

victor-van-der-hulst

Victor van der Hulst

Managing Consultant

+31 6 22 98 68 76 Stuur Victor een e-mail

Reacties

Er zijn nog geen reacties op dit bericht.

Plaats een reactie

Dit veld is verplicht.

Vul een geldig e-mailadres in.

Dit veld is verplicht.