Low-code en Mendix zijn al een behoorlijke tijd aanwezig. Dit betekent dat er applicaties bestaan die meer dan 10 jaar geleden zijn gemaakt. Destijds bood het Mendix-platform veel minder mogelijkheden dan wat er vandaag de dag beschikbaar is. Hierdoor werden er andere ontwikkelroutes gekozen dan we nu zouden doen.
Applicaties bouwen altijd technical debt op en als dit niet goed wordt beheerd, zal dit zich opstapelen. Het zou kunnen dat hierdoor de snelheid van de ontwikkeling afneemt of zelfs dat applicaties performance problemen vertonen. Uiteindelijk zal de volgende vraag zich voordoen: moeten we een applicatie opnieuw bouwen of de oude refactoren?
In dit blog wil ik je inzicht geven in waar je op moet letten bij het nemen van deze beslissing. Uit ervaring weet ik dat elke situatie anders is, onderstaande punten geven echter een goede start bij het afwegen van de opties en het maken van een beslissing.
Begin met het maken van een procesflow van de processen die de applicatie ondersteunt, of zou moeten ondersteunen. Vervolgens kun je controleren of je applicatie deze processen nog steeds op de juiste manier digitaliseert. Als dit niet het geval is en je veel ‘technical debt’ hebt, is opnieuw bouwen misschien geen slecht idee. Echter, als de huidige applicatie wel voldoet aan de gewenste functionaliteit, kan de refactor optie beter zijn.
Een vervolgstap kan zijn om een ruwe schatting te maken van de tijd die nodig is om een nieuwe applicatie te bouwen versus de tijd die nodig is om de applicatie te refactoren. In veel gevallen zal de tijd voor refactoring in eerste instantie lager (kunnen) zijn. Voornamelijk omdat we bij refactoring geneigd zijn specifieke delen van de applicatie te refactoren en niet de volledige code. Houd er echter rekening mee dat het creëren van een nieuwe applicatie de ontwikkelingssnelheid in de toekomst kan verhogen. Als het juist wordt opgezet, zul je geen last hebben van oude, niet-onderhoudbare code en kun je dus weer volop profiteren van de snelheid van het Mendix platform.
Het is misschien moeilijk om dit te kwantificeren, maar een open discussie met je development team hierover kan nuttig zijn. Probeer bijvoorbeeld te overleggen of de ontwikkelsnelheid met 5% zal toenemen of dat het eerder 50% zou zijn. Door hierover te discussiëren krijg je een goede indicatie van wat het daadwerkelijk zou kunnen zijn en daarmee ook een beter beeld of het een goede optie is.
Om een goede beslissing te nemen, kan het verstandig zijn om in te schatten wat het percentage aan functionaliteit is dat moet worden gewijzigd bij refactoring. Als het uiteindelijk slechts 10% is, is er waarschijnlijk geen goede reden om voor een nieuwe applicatie te kiezen.
Naast dit percentage, is het goed om te kijken naar de huidige modules binnen de applicatie. Specifiek naar hoe deze modules zijn opgesplitst. Als je merkt dat je applicatie een paar afgebakende modules heeft die in aanmerking komen voor refactoring, maar de andere modules in orde zijn, is het verstandig om te kiezen voor refactoren in plaats van opnieuw bouwen.
Bij het herbouwen van een applicatie moet je nadenken over gegevensmigratie. Met Mendix kan dit eenvoudig worden bereikt door middel van een Excel, JSON-export en -import of database-synchronisatie tools, maar dit kost flink wat tijd. Opnieuw rijst de vraag: om hoeveel data gaat dit? En wat is het risico op gegevensverlies? Als er veel gegevens zijn om te migreren met een hoog risico op verlies, is herbouwen wellicht geen goed idee.
Je applicatie wordt al jaren binnen je organisatie gebruikt. Wat zijn de plannen voor de toekomst van de applicatie? Als je weet dat de applicatie nog een jaar zal worden gebruikt, heeft het (waarschijnlijk) geen zin om een nieuwe applicatie te ontwikkelen. Als je van plan bent de applicatie nog minstens vijf jaar te gebruiken, heb je wellicht een goede businesscase voor herbouw. Ook al kun je de toekomst niet voorspellen, het opstellen van een langetermijnplan zal je helpen in het nemen van de beslissing.
Zoals eerder vermeld, stelt Mendix je in staat om functionaliteit op te splitsen in afzonderlijke modules. Dit geeft je de mogelijkheid om volledig nieuwe functionaliteit binnen je oude applicatie te creëren zonder de hele applicatie opnieuw te hoeven bouwen. Dit is een meer pragmatische aanpak die je flexibiliteit geeft terwijl je de goede dingen van je huidige applicatie behoudt. Gegevensmigratie zal ook makkelijker zijn omdat het binnen dezelfde database plaatsvindt. Vergeet niet om de oude code op te schonen en houd in gedachten dat er nog steeds een kans bestaat dat je ontwikkeling vertraagt vanwege die oude code.
Bij het kiezen tussen het herbouwen van een applicatie of het behouden van de oude applicatie en refactoren, moet toekomstige ontwikkeling zich in beide scenario's richten op onderhoudbaarheid. Dit zorgt ervoor dat dit dilemma niet snel nog een keer voorkomt en het houdt je code schoon
De 'Refactor vs Opnieuw bouwen' case is er één die ik vele malen ben tegengekomen en het is geen gemakkelijke kwestie. Houd in gedachten dat elke nieuwe ontwikkelaar op een project zal denken dat ze een andere of betere manier hadden toegepast. De ‘technical debt’ die meestal wordt gecreëerd, bestaat uit bugfixes en veranderde functionaliteit. Het zijn inzichten die gaandeweg verkregen zijn en hebben daarmee ook een zekere waarde.
Bovendien, als je een commerciële applicatie hebt zoals wanneer je een partner bent in het Mendix ISV programma kan het creëren van een geheel nieuwe applicatie je concurrentievoordeel beïnvloeden. Je moet opnieuw door een proces van testen, bugfixes oplossen en verifiëren in de markt.
Als je jezelf geconfronteerd ziet worden met vergelijkbare problemen, probeer dan de bovenstaande punten te analyseren en te bespreken. Als je behoefte hebt om te sparren over jouw specifieke geval onder het genot van een kop koffie, voel je dan vrij om contact met me op te nemen.
