Invoering
Refactoring van het increment

Nadat alle functionaliteit is toegevoegd en uitgebreid in de fasen ontwerp en bouw, wordt de fase invoering in een iteratie gebruikt om de gerealiseerde code te stabiliseren. Enerzijds wordt hierbij gekeken naar mogelijk hergebruik van de ontwikkelde code. Hiervoor wordt de technische applicatiearchitectuur bijgewerkt. Anderzijds is het vaak nodig om de structuur van de code, die wellicht onder tijdsdruk is ontwikkeld, te verbeteren. Hiermee wordt de onderhoudbaarheid van de code aanzienlijk vergroot.

Doel

In veel projecten wordt de functionaliteit onder lichte tijdsdruk ontwikkeld. Hierdoor worden nogal eens shortcuts in de referentiearchitectuur gekozen. Functionaliteit kan nu bijvoorbeeld in klassen terecht zijn gekomen, die hier niet verantwoordelijk voor zijn. Refactoring van de code wordt nu gedaan om de onderhoudbaarheid van deze code te vergroten en om de functionaliteit weer op de goed plek in de applicatiearchitectuur te plaatsen. Eventueel levert refactoring nieuwe herbruikbare classes op.

Stappen

1. Refactoring van tasks
   Doorloop alle ontwikkelde tasks in het increment. Geen van deze classes mag bedrijfslogica bevatten. In de praktijk wordt bijvoorbeeld nog wel eens een shortcut gekozen, waarbij de task direct de database benadert. Verplaats ieder blok code dat bedrijfslogica bevat vanuit de task naar de verantwoordelijke business- of factory class. Mogelijk ontstaat een nieuwe business- of factory class die de functionaliteit dient te bevatten.
   Onderzoek bij ieder van deze refactorings of er nog andere tasks zijn die dezelfde - of sterk daar op lijkende - bedrijfslogica bevatten. Vervang deze logica door het aanroepen van de zojuiste gerealiseerde functionaliteit op de business- of factory class.
   
   
2. Refactoring van business- en factory classes
   Ga samen met de specialist langs alle methoden op de business- en de factory classes die zijn geïmplementeerd tijdens de iteratie. In principe bevatten deze methoden alleen applicatiespecifieke bedrijfslogica. In sommige gevallen kan echter organisatiegenerieke bedrijfslogica door de methode worden beschreven. De specialist dient dit verschil aan te kunnen geven. Onderzoek welke component, en welke interface van deze component, verantwoordelijk is voor deze organisatiegenerieke logica. Creëer een methode op deze interface, en verplaats de code naar de interface class die de nieuwe methode moet implementeren op de component. Vervang de functionaliteit van de betrokken business- of factory class door een aanroep van de nieuwe methode op de component.
   
   
3. Identificeren van eventuele utility classes
   Doorloop opnieuw de tasks, en de methoden van business- en factory classes die zijn geïmplementeerd tijdens de iteratie. Kijk of stukjes code herhaald voor komen over alle classes heen. In verreweg de meeste gevallen betreft dit technische functionaliteit, die steeds gekopieerd is. Dergelijke functionaliteit is een gevaar voor de onderhoudbaarheid van de code. Ga na op welke utility class deze functionaliteit thuis hoort, of creëer een nieuwe utility class. Maak een nieuwe methode aan op deze class. Verplaats nu de herhaald voorkomende code naar de utility class. Vervang vervolgens alle voorkomens van de herhalende code door een aanroep van de utility class.
   
   
4. Evalueren van de refactorings
   Indien refactoring van de code heeft plaatsgevonden, ga na waarom deze noodzakelijk was. Dit kan te maken hebben met tijdsdruk, maar ook met gebrekkige kennis van de applicatiearchitectuur bij ontwerpers en ontwikkelaars. Evalueer de refactorings met de betrokken ontwerpers en ontwikkelaars, opdat in een volgende iteratie minder refactoring nodig is.
   
   
5. Testen van de refactorings
   Na iedere refactoring moeten de tests in alle test classes nog steeds werken. Immers, refactoring voegt geen nieuwe functionaliteit toe, maar verbetert slechts de kwaliteit en onderhoudbaarheid van de code. Draai alle tests. Indien test cases geen positief resultaat geven, ga naar waarom dit het geval is en verbeter de code. Herhaal deze activiteit totdat alle test cases wederom een positief resultaat geven.
   
   

Richtlijnen

Let bij refactoring van technische functionaliteit goed op de genericiteit van de nieuwe methoden. Vaak kan door een extra parameter aan de signature van de methode toe te voegen, een groot aantal voorkomens in de code eenvoudig ook worden vervangen.