Application refactoring: wat is het en waarom zou je het doen?

‍

Een probleem waar menig bedrijf mee kampt is dat applicaties nog gebruikmaken van oude (legacy) code. Dit brengt niet alleen extra uitdagingen voor ontwikkelaars (oude bugs, een mindere performance en een groter risico op datalekken) met zich mee, maar gaat uiteindelijk ook gewoon ten koste van uw concurrentiekracht in de vorm van negatieve feedback, ontevreden gebruikers en mensen die hun heil zoeken bij concurrenten die hun digitale zaakjes beter op orde hebben. Application refactoring is vaak een goede oplossing voor de bovengenoemde problemen. Maar wat is refactoring? En wanneer is het verstandig om voor deze aanpak te kiezen?

Wat is refactoring?

Organisaties zijn anno 2020 steeds afhankelijker van een modern, soepel functionerend en geïntegreerd applicatielandschap. Applicaties zijn niet langer handige extraatjes, maar gewoon bedrijfskritische tools die bedrijfsprocessen sturen en vormgeven. Doormiddel van DevOp-werkwijzen en Continuous Delivery verloopt ontwikkeling van nieuwe applicaties steeds sneller, waardoor de levensduur langer is en ROI, oftewel Return on Investment, van de gemiddelde applicatie sneller behaald kunnen worden. In veel gevallen is er al een (opmaat gemaakte) applicatie aanwezig en kan het opnieuw bouwen een behoorlijke investering zijn. Refactoring van je oude (legacy-)applicaties is daarom zeker het overwegen waard.

Refactoring is namelijk het ombouwen van reeds bestaande applicaties zodat deze beter zijn toegerust op de behoeften en uitdagingen van de moderne tijd. Hierdoor wordt het bijvoorbeeld eenvoudiger om een bestaande app om te zetten naar een mobiele variant of onder te brengen in de cloud. Om dit te bereiken zal de interne structuur van de broncode aangepast moeten worden, terwijl de software op functioneel vlak hetzelfde blijft doen als voorheen.

Je kunt het vergelijken met de renovatie van een woning: het geraamte en fundament blijven staan, maar van binnen wordt kamer voor kamer de inrichting vervangen en gemoderniseerd. De applicatie wordt dus gewijzigd om de performance te verbeteren (bugs eruit halen, performanceproblemen oplossen), maar niet alle code wordt herschreven. Vanzelfsprekend vereist dit proces een uitstekende kennis van de reeds aanwezige systeemstructuur, datamodellen en afhankelijkheden van het bestaande softwaresysteem.

Waarom en wanneer?

Bij “slecht” ontworpen bedrijfskritische applicaties is er een aanzienlijk risico om ze – middels een lift & shift methode – één op één naar de cloud te verplaatsen. Zonder refactoring zullen deze applicaties cloudresources inefficiënt verbruiken, waardoor ze een veel hogere rekening genereren en zelfs prestatie- en stabiliteitsproblemen kunnen veroorzaken. Door eerst slechts een deel van de applicatie te wijzigen is dit een snellere manier om een app naar de cloud te migreren en kun je profiteren van de beschikbare cloudfuncties.

Maar wanneer pas je refactoring dan toe? De beste tijd om application refactoring te overwegen is de fase die voorafgaat aan het toevoegen van updates en nieuwe functionaliteiten aan een applicatie. Stel dat je een applicatie die nu nog on-premises staat in de cloud wilt zetten. Wellicht moet er hier en daar nog wat aan de software worden gesleuteld om zo’n applicatie echt ‘cloudproof’ te maken. Refactoring is dan een goede stap om de applicatie tot in de perfectie toe te snijden op een cloudomgeving. Hierna voeg je pas nieuwe features toe, want meer features vooraf zorgt ook voor meer afhankelijkheden ten tijde van overzetten.

Of refactoring de juiste methode is, hangt ook af van de aard, functie en complexiteit van de applicatie die je onder handen wilt nemen. Vormt een applicatie de ruggengraat van belangrijke bedrijfsprocessen? Of levert ze een belangrijke bijdrage aan de totale omzet van je bedrijf? Dan is rebuilding (het vanaf scratch opnieuw bouwen van een applicatie) best riskant en wellicht geen haalbare kaart. Refactoring is in zo’n geval vaak een betere en veiligere optie.

De voordelen van refactoring

Refactoring heeft een aantal voordelen die van de werkwijze een aantrekkelijke optie maken als je bestaande applicaties wilt optimaliseren. We zetten de belangrijkste benefits op een rij.

• Het doen van kleine en geleidelijke aanpassingen brengt minder risico’s met zich mee dan het wiel opnieuw uitvinden. Als er iets misgaat, ligt niet gelijk de hele applicatie eruit. Aan de goed werkende functionaliteiten van de applicatie wordt bovendien niet getornd.
• Bugs blijven beperkt tot duidelijk afgebakende gebieden. Het resultaat: ze zijn gemakkelijk te vinden, controleren en verhelpen.
• Agile werken wordt een stuk gemakkelijker. Refactoring gaat namelijk uit van kleine aanpassingen die in korte, snel op elkaar volgende cycli worden doorgevoerd.
• Het design en de leesbaarheid van codes verbetert, terwijl het modificatieproces sneller en eenvoudiger verloopt.
• Het proces van refactoring is zo ingericht dat je alleen betaalt voor wat jenodig heeft. De prijsstructuur is namelijk afhankelijk van de scope en looptijd van het project.
• Je krijgt een slimme, eenvoudig te managen code zonder middleware te hoeven inzetten.

De nadelen van refactoring

Natuurlijk zijn er ook nadelen.

• Er zijn momenten waarop een applicatie vanaf het begin volledig moet worden vernieuwd. In deze gevallen is refactoring niet nodig, omdat het veel efficiënter zou zijn om gewoon helemaal opnieuw te beginnen.
• Als je eenmaal begint, kan het behoorlijk tijdrovend zijn. Het wijzigen, toevoegen van code en het testen binnen een krappe tijdlijn kan leiden tot frustratie en mogelijk zelfs extra kosten.
• Uitstekende kennis van de aanwezige (legacy-) software nodig, welke soms sterk veroudert is en hierdoor inhoudelijke kennis niet altijd vanzelfsprekend is.

Conclusie: hoe pak je het aan?

Het probleem dat moet worden aangepakt of de omgeving waarbinnen refactoring wordt uitgevoerd verschilt per organisatie en toepassing. Daarnaast is vaak een applicatie ook nog eens uniek. Stel je daarbij vragen als:

• Hoe gaan we om met lopende zaken? Zeker bedrijfskritische applicaties moeten natuurlijk wel bereikbaar en bruikbaar blijven.
• Wat is de beste fasering in termen van tijd, middelen, geld en techniek?
• Is er een ROI (Return On Investment) te behalen?
• Voeren we de refactoring helemaal intern uit of zoeken we de hulp van een gespecialiseerde partner? En wie heeft welke verantwoordelijkheden?

Er is dus geen universele blauwdruk voor refactoring; elk project heeft zijn eigen bijzonderheden en uitdagingen. Refactoring vergt daarom elke keer een apart traject dat rekening houdt met de scope, werkverdeling, planning en techniek. Als een je geen ROI kan halen uit refactoring, dan moet je er niet aan willen beginnen. Je zou dan wel kunnen overwegen om een containerisatie uit te voeren, waarbij applicaties met minimale wijzigingen in containers worden verschoven.