insight
Onderhoudbaarheid tip 3: Refactor met korte termijn doelen
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. 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
Nu de hoeveelheid technical debt objectief in beeld is (en blijft worden) gebracht, is het zaak de business verantwoordelijke (de u003cemu003eproductu003cstrongu003e u003c/strongu003eowneru003c/emu003e 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.rnu003ch2 class=u0022fs-xxlu0022u003eu003c/h2u003e
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.
u0022The act of leaving a mess in the code should be as socially unacceptable as littering.’
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:rnu003culu003ern tu003cliu003eu003cstrongu003eYAGNIu003c/strongu003e 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.u003c/liu003ern tu003cliu003eu003cstrongu003eBoy Scout Ruleu003c/strongu003e 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.u003c/liu003ern tu003cliu003eu003cstrongu003eNo Museumu003c/strongu003e 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.u003c/liu003ern tu003cliu003eu003cstrongu003eDRYu003c/strongu003e 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.u003c/liu003ernu003c/ulu003e
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 (rnrnu003cemu003egreenfieldu003c/emu003e) 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 u003ca class=u0022clru002du002dprimu0022 href=u0022https://www.pluralsight.com/courses/refactoring-fundamentalsu0022 target=u0022_blanku0022 rel=u0022noopener noreferreru0022u003ePluralsightu003c/au003e. Volgende week sta ik stil bij de rol van testen. Ook de mate en wijze van testen heeft invloed op de onderhoudbaarheid van applicaties.rnu003cfigure class=u0022clearfixu0022u003eu003cimg class=u0022aligncenteru0022 src=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-3-refactor-met-korte-termijn-doelen-blog-Victor.jpgu0022 srcset=u0022u0022 alt=u0022onderhoudbaarheid-tip-3-refactor-met-korte-termijn-doelen-blog-victoru0022 width=u0022724u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-3-refactor-met-korte-termijn-doelen-blog-Victor.jpg 181w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-3-refactor-met-korte-termijn-doelen-blog-Victor@2x.jpg 362w, https://vxcompany.com/wp-content/uploads/Onderhoudbaarheid-tip-3-refactor-met-korte-termijn-doelen-blog-Victor@4x.jpg 724wu0022 /u003eu003c/figureu003e