De 10 redenen voor refactoring

De beslissing om software te refactoren wordt vaak op een laag pitje gezet. Waarom zou je tijd en middelen investeren om (delen van) de backend te verbeteren die toch onzichtbaar zijn voor de eindgebruiker? En waarom iets vervangen wat al jaren (misschien wel decennia) goed voldoet? In dit blog geef ik je 10 redenen voor refactoring van legacy en waarom je dit niet langer moet uitstellen.

Wat is legacy en refactoring?

‘Legacy software’ is volgens Wikipedia “een versie van software die gebaseerd is op inmiddels achterhaalde technologie, maar die voor de gebruiker nog steeds voldoet en daarom minimaal wordt onderhouden met kleine updates, waaronder beveiligingsupdates en bugfixes.”

‘Refactoring’ is “de herstructurering van software met behoud van de oorspronkelijke functionaliteit, met als doel de prestaties van de software te verbeteren en verdere ontwikkeling te vergemakkelijken.”

Vanuit pragmatisch oogpunt is refactoring de productieve tijd van jouw ontwikkelteam die je moet investeren in het verbeteren van de kwaliteit van (legacy) software in plaats van het uitbreiden van de functionaliteit.

Openstaande schuld aflossen

Ik zie en hoor vaak dat bedrijven zich liever concentreren op essentiële functionele uitbreidingen of op maatwerk voor belangrijke klanten. Dat levert tenminste winst op korte termijn op. De praktijk leert echter dat de beslissing voor of tegen refactoring niet alleen wordt bepaald door ondernemerssucces of hoe een product en van de buitenkant uit ziet. De belangrijkste argumenten voor een principiële beslissing om een stuk software verder te renoveren, komen meestal van de productmanager of de IT-manager, want die lopen vaak aan tegen gebrekkige kwaliteit, efficiëntie en onderhoudbaarheid van de applicaties. Als organisatie ben je je ervan bewust van geweest dat je in het verleden bij de ontwikkeling van een softwareproduct bepaalde compromissen hebt gesloten. Bijvoorbeeld om op dat moment belangrijke deadlines te halen of om de wensen van de klant voorop te stellen. Vroeg of laat moet je aan je verplichtingen voldoen en de openstaande “technische schuld” afbetalen. Voordat het je echt op achterstand gaat zetten. Maar wat zijn dan die dringende redenen voor refactoring?

De top 10 goede redenen voor refactoring

Legacy software vormt in veel markten nog de basis van de omgevingen waarmee gewerkt wordt. In andere situaties is het te vinden in de uithoeken van het landschap die niet zozeer in het zicht van de klanten zijn. Wat de status ook is, de refactoring wordt vaak (te) lang uitgesteld. Ik geef je 10 duidelijke redenen om er wél direct mee te beginnen.

1.    Houd of vind de juiste mensen – softwareontwikkelaars voor legacy systemen zijn op den duur niet meer te vinden.

2.    Broncode vereenvoudigen – het hoeft geen rocket science te zijn.

3.    Meer inzicht in de code – goed gestructureerd en gedocumenteerd. Voor iedereen leesbaar

4.    Robuuster – object georiënteerde code i.p.v. aan elkaar geknoopte delen. Geen kaartenhuis meer.

5.    Flexibiliteit – legacy code is vaak moeilijk aan te passen of te voorzien van nieuwe functionaliteit.

6.    Snelheid en performance – prestatie van de code moet omhoog om de ontwikkelingen bij te kunnen houden.

7.    Testbaarheid verbeteren – gestructureerd testen is vaak niet mogelijk en fouten zijn moeilijk op te sporen.

8.    Verbeteren van deployment – nieuwe tools en service om dit te optimaliseren en automatiseren werken vaak niet.

9.    Veiligheid verbeteren – legacy software is vaker gevoelig voor veiligheid issues.

10. Lagere kosten – een nieuwere omgeving is vaak efficiënter in beheer en onderhoud.

Wat houdt refactoring tegen?

Het bovenstaande 10-puntenlijstje lijkt voldoende te zijn om er direct mee aan de gang te gaan. De praktijk is vaak echter anders en niet zelden om begrijpelijke redenen. Uiteraard zijn financiële overwegingen vaak de drempel waar niet overheen gegaan wordt. Investeren in het verbeteren van de achterkant van je software is lastiger dan het ontwikkelen van nieuwe functionaliteit. En het uitbreiden van het team om de ombouw uit te voeren is vaak ook een niet te nemen horde. Eigenlijk net zo vaak hoor ik de twijfel vanwege de technische risico’s. Krijgen we deze klus wel geklaard en binnen een redelijke termijn? De business moet wel doorgaan tijdens en na de verbouwing. En soms is er gewoon een weerstand tegen verandering. Waarom zouden we veranderen wat nu toch gewoon werkt?

Zou je graag meer willen weten over hoe wij je kunnen helpen met de stap naar een innovatieve, maar ook (financieel) haalbare ICT-omgeving? Neem dan contact met mij op via haico.sterk@addcode.nl

Literatuurlijst