Rebuild of refactor software?

Home / Blog / Achtergronden / Rebuild of refactor software?

Wat is beter: software herbouwen of refactoren? De meningen verschillen en het is ook afhankelijk van het project. En wat de klant verstaat onder herbouw en wat de engineer verstaat onder herbouw wil ook nog wel eens wezenlijk verschillen. Het is dus zaak om de verwachtingen vooraf goed duidelijk te krijgen. Voordat we deze discussie aangaan is het daarom ook goed een definitie te stellen voor rebuilding en refactoring:

Wat is rebuilding? Bij rebuilding herschrijf je de gehele applicatie. In vergelijking met een woningrenovatie: je sloopt het hele huis en bouwt een nieuw huis vanaf het eerste begin.

Wat is refactoring? Bij refactoring maak je belangrijke wijzigingen aan de applicatie maar je herschrijft niet alle code. In vergelijking met een woningrenovatie: je stript wat en knapt het huis op maar het geraamte blijft sowieso staan.

Naast een duidelijke definitie voor beide begrippen, is er ook een aantal andere factoren om rekening mee te houden:

Het aantal afhankelijke gebruikers

Een persoonlijke website die je gebruikt als portfolio versus een applicatie waar duizenden mensen van afhankelijk zijn, zorgt voor de nodige verschillen in de keus voor rebuilding of refactoring. In het eerste geval van een verouderde website met een puinhoop aan code, een gruwelijk design en met zeer weinig gebruikers, kun je die herbouwen. Dat maakt hem weer lekker fris en geeft een nieuwe start. In het tweede geval staat er meer op het spel. Zeker als je applicatie essentieel is voor de bedrijfsvoering en misschien wel verantwoordelijk voor een groot deel van de omzet. Voorzichtigheid is dan geboden en refactoring kan in dat geval een betere, minder risicovolle optie zijn.

Migreren naar een nieuwe technologie

Bij het migreren van een applicatie naar een nieuwe technologie kan er gekozen worden voor rebuilding waar from scratch vanuit een nieuwe technologie wordt gebouwd. Soms zijn er in bedrijven nog applicaties draaiende waarvan niemand meer diepgaande kennis heeft. Het komt zelfs voor dat er überhaupt geen kennis meer is over de programmeertaal waarin de applicatie ooit geschreven is. Afhankelijk van het doel van de applicatie kan dat een probleem vormen voor de veiligheid en continuïteit. Die klanten spreken vaak de wens uit om te moderniseren en de gehele applicatie in een actuele taal te programmeren. Dan komt rebuilding om de hoek kijken.

Voordelen van rebuilding software

• De applicatie krijgt een frisse start
• De applicatie is helemaal up-to-date vanuit de kern tot aan de details
• Als een bedrijf niet goed loopt kan het herschrijven van de applicatie(s) een boost geven

Nadelen van rebuilding software

• De release cycle is langer waardoor er een risico is dat het bedrijf tijdelijk niet optimaal functioneert of zelfs stil komt te liggen
• Rebuilding heeft grote gevolgen voor de implementatie bij de gebruikers. Die zullen niet meer het gevoel hebben met dezelfde applicatie te werken en verandering roept weerstand op. Dat kan weer leiden tot veel support tickets. Die ergernis van de gebruikers kan, afhankelijk van intern of extern gebruik van de applicatie, klanten kosten. Iets wat je als software engineer zeker mee moet nemen in je advies naar de klant
• From scratch beginnen brengt de verleiding met zich mee om uit te breiden met nieuwe features en technologieën. Dit kan weer zorgen voor meer vertraging en bugs. Rebuilding vraagt zeer veel discipline om op het geplande pad te blijven

Voordelen van refactoring software

• Het doen van geleidelijke aanpassingen en verbeteringen geeft minder risico’s
• Bugs worden steeds beperkt tot kleine afgebakende gebieden en zijn beter controleerbaar
• Het is efficiënter
• Je kunt meer agile te werk gaan door de kleine aanpassingen die je steeds oplevert en dat maakt je cycli korter en sneller.
• De klant ziet regelmatig opleveringen en heeft het gevoel dat er voortgang is

Nadelen van refactoring software

• Het grootste nadeel is misschien toch wel voor de uitdaging van de engineer: refactoring is minder spannend en vernieuwend dan rebuilding. Laten we daar geen geheim van maken
• Ondanks de regelmatige opleveringen zijn de echt grote resultaten later zichtbaar dan bij herbouw. Je ziet steeds maar kleine verbeteringen en zult moeten vertrouwen dat de grote veranderingen pas op lange termijn zichtbaar worden en dit vooral ook aan je klant moeten kunnen overbrengen zodat ook die vertrouwen blijft houden in het proces
• Refactoring kan je verleiden om maar alles te refactoren dat je tegen komt en je niet aanstaat. Zo kan je gemakkelijk afdwalen, tijd verliezen en dingen doen die de klant niet nodig heeft of die niet facturabel zijn.

De keuze tussen refactoring en rebuilding is dus niet zo evident. Het prettigste zou zijn als je beide kunt vermijden. Er zijn tools beschikbaar om je daarbij te helpen, zoals Code Climate. Wat adviseer jij in welk geval en waarom? En wat heeft je persoonlijke voorkeur?