Refactoring en ROI

Sommige programmeurs denken dat je mag refactoren als je denkt dat een “oude” source pagina niet volgens de standaard is, zoeken en vervangen door de hele source page met variabelen en nog wat standaard tabjes en spaties verzetten, daarna lekker in Git zetten met “tig” wijzigingen en we gaan weer verder! Zo wat zijn we toch goed aan het refactoren…

Maar wat is refactoring nou echt? Refactoring is het ombouwen van reeds bestaande applicaties, zodat deze beter zijn toegerust op de behoeften en uitdagingen van de moderne tijd. De applicatie wordt gewijzigd om de performance te verbeteren of bijv. te moderniseren, 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. Een net nieuwe werknemer of een junior programmeur die zegt dat ie aan het refactoren is, dan mag je je dus wel even achter de oren krabben als eindverantwoordelijke.

Naar mijn mening dient een programmeur niet in zijn uppie te kunnen bepalen dat hij er wel even een refactor doorheen gooit, dit dient weloverwogen en structureel te gebeuren en is niet een kwartiervulling van je tijd. 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 en fouten.

Refactoring vergt daarom elke keer een apart traject dat rekening houdt met de scope, werkverdeling, planning en techniek. Als je geen ROI kan halen uit refactoring, dan moet je er niet aan willen beginnen.