Bij refactoring wordt de broncode van een applicatie opnieuw gestructureerd, om op deze manier de leesbaarheid van de code te verbeteren en het onderhoud daarvan te vereenvoudigen. De basisfunctionaliteiten van een applicatie worden hierbij niet veranderd.

In sommige gevallen is refactoring voor een organisatie de enige optie. Bijvoorbeeld wanneer een applicatie binnen de organisatie een cruciale rol speelt, of wanneer de database enorm is. In deze situaties is een migratie naar een ander systeem niet aan te raden of zelfs onmogelijk.

Waarom refactoring?

Een van de redenen voor refactoring is dat de code van een project te oud en/of fragiel is. Vaak is het een grote brei aan code die niet meer te ontrafelen is. In dit soort code is er geen eenduidige visie in de applicatiestructuur en ontbreekt een opsplitsing in functionaliteit en verantwoordelijkheid.

Op deze manier is het bijna onmogelijk om op een werkbare manier aanpassingen door te voeren of nieuwe onderdelen toe te voegen. Simpelweg omdat je niet weet welke gevolgen dit heeft voor andere toepassingen. Een aanpassing op plek A kan bijvoorbeeld mogelijk leiden tot het omvallen van een functie op plek B.

Refactoring praktijkvoorbeeld

Een goed voorbeeld van refactoring is een project dat wij onlangs hebben gedaan voor een van onze klanten. Hierin kwam al snel naar voren dat er de afgelopen jaren weinig aandacht was besteed aan een constructieve opzet en het onderhouden van de applicatie. Voor hen zijn wij aan de slag gegaan met een volledige vervanging van de onderliggende infrastructuur.

De eerste stap in dit soort projecten is altijd een inventarisatie van de huidige stand van zaken. Al snel kwamen we erachter dat het vooral onduidelijk was waar stukjes code voor dienden en hoe deze aan elkaar waren gekoppeld.

Onderstaande afbeelding uit PhpMetrics laat zien hoe de beginsituatie was. Er waren de nodige ‘violations’ en codelijnen.

Een belangrijke conclusie die uit dit onderzoek voortvloeide was dat de code teveel aan elkaar gekoppeld en verbonden was, waardoor er geen scheiding van verantwoordelijkheid was. Oftewel, een aanpassing in A leidde bijna altijd tot een impliciete en ongewilde aanpassing in B, Q, X, etc. Dit wordt goed geïllustreerd in onderstaande afbeelding.

Om dit inzichtelijk te maken zijn we samen gaan zitten met de product owner van de klant en hebben we deze mee laten draaien in ons ontwikkelproces. Dit is zeer belangrijk, omdat hierdoor de noodzaak om zaken te veranderen duidelijk kan worden uitgelegd en onderbouwd.

Vervolgens zijn we aan de slag gegaan met het vervangen van alle ‘externe dependencies’ door composer en bestaande onderdelen. Om dit te laten slagen was er ook refactoring nodig in de huidige code van de applicatie. Daarin werd namelijk composer nog niet ondersteund. Dit bood ons ook direct de mogelijkheid om in nieuwe naamvelden een aantal onderdelen parallel opnieuw op te zetten of te vervangen, zonder dat de huidige structuur werd aangetast.

Resultaten

Het resultaat van dit refactoring project is dat de klant nu beschikt over een logische code voor zijn applicatie, waarin onderdelen eenvoudig aangepast kunnen worden zonder dat dit direct negatieve gevolgen heeft voor andere onderdelen.

De klant heeft voor het overgrote deel een gestandaardiseerd framework dat volledig is gedocumenteerd, waardoor iedere ontwikkelaar er direct mee aan de slag kan. Het is volledig transparant waar de verantwoordelijkheid van ieder stuk code ligt.

Om de wijzigingen middels refactoring te onderbouwen meten we alle resultaten die volgen uit de aanpassingen. Dankzij deze statistieken kunnen we goed een vinger aan de pols houden over de kwaliteit van de code.

Een van de conclusies die we mogen trekken op basis van de statistieken is dat als gevolg van de doorgevoerde wijzigingen de kwaliteit van de code structureel is verbeterd. Onderstaand screenshot laat de situatie na de doorgevoerde wijzigingen zien. Ten opzichte van de beginsituatie is het aantal ‘violations’ met meer dan 50% teruggebracht en het aantal codelijnen met bijna 65%. Verder toont de sterk ingekrompen ‘draaikolk’ aan dat de onderhoudbaarheid en complexiteit van de website fors is verbeterd.

Wil jij weten of jouw Drupal website ook structureel verbeterd kan worden? Vraag dan onze Drupal Scan aan of neem via onderstaand formulier contact met ons op.