Hoe ga je om met de (on)voorspelbaarheid van groot refactor werk?
Stel, je moet een grote refactor doorvoeren van een bepaald aspect van de codebase. Deze refactor raakt heel veel onderdelen van de codebase, maar je kunt er niet omheen. Om erachter te komen wat je allemaal raakt zonder het aan te raken, beland je soms in een waar down-the-rabbit-hole. Het inschatten en voorspelbaar zijn op dit soort werk kan dan heel lastig zijn. Hoe ga je hier goed mee om in een agile context? Doe je voordeel met deze tips van enkele software ontwikkelaars binnen New Nexus.
Opslagformule
Naarmate de codebase meer is verouderd, bijvoorbeeld als gevolg van een matige legacy architectuur, kan je met vrij grote zekerheid zeggen dat er meer werk achterweg komt. Misschien is een bepaalde formule te bedenken die iets zegt over de opslag in uren die je moet incalculeren wanneer je aan de refactoring begint. Maar zelfs als je de codebase zoveel mogelijk modern houdt, heb je soms wat meer ingrijpende refactors. Die moet je toch als geheel ineen doen. Het berekenen van een opslag in uren is dan nog steeds niet eenvoudig.
Kanban
Of je hebt zo’n stapel applicaties die gerefactored moeten worden, dat het werk niet in te schatten is en in elk geval meerdere maanden gaat duren. De refactoring is dan een project op zich. Je weet wel wat je moet doen, maar niet wat je gaat tegenkomen en dat kan bovendien per applicatie weer verschillen. Je kunt er dan als team voor kiezen om via Kanban te werken.
Spikes
Gaat het om een losse (grote) refactor klus binnen een scrum bouwproject, dan kan het helpen om het in stukjes op te delen. Welke ingrepen ga je doen, en hoe lang duren die? Dan heb je al een wat nauwkeuriger beeld van hoe diep de rabbit-hole is.
- In print 1 begin je timeboxed aan de refactor, bijvoorbeeld maximaal 2 dagdelen. Het resultaat is niet de refactor zelf maar meer kennis van de legacy architectuur. De refactor hoeft niet eens succesvol te zijn op dit moment.
- In sprint 2 gebruik je die kennis om de refactor in stukjes op te delen en de complexiteit te kwantificeren middels story points. Nu kun je het inplannen zoals je gewend bent.
Dit wordt ook wel de Spike methode genoemd. Spikes worden wel vaker gebruikt om voor een refactor wat zaken uit te zoeken, maar je kunt het dus ook inzetten om gewoon een deel van de refactor starten en een beter beeld van de rest van de refactor te krijgen.
