De introductie van agile werken heeft een grote impact gehad op de manier waarop men software ontwikkelt. Bij de watervalmethode werd op basis van vergaarde requirements een product opgeleverd, welke na verloop van tijd als geheel vervangen werd voor een nieuw product. Tegenwoordig wordt de levenscyclus van software voortdurend opnieuw doorlopen: het vergaren en analyseren van requirements, het verwerken van deze requirements tot een ontwerp, het implementeren van de wijzigingen, een testfase en vervolgens het evolueren van de huidige versie. In deze levenscyclus speelt code refactoring een cruciale rol. Wat is het en hoe pas je dit toe?
Code refactoring is het continu optimaliseren van de structuur van de broncode
Het toevoegen van nieuwe functionaliteit aan bestaande software maakt dat de broncode hiervan al snel erg complex kan worden. Dit maakt het steeds lastiger om de levenscyclus van software ontwikkeling opnieuw te doorlopen. Een aanpassing aan de bestaande broncode kan onverwachte effecten hebben op bestaande functies, als men onvoldoende grip heeft op de broncode. Het is om deze reden essentieel, dat in iedere cyclus geprobeerd wordt de broncode van software opnieuw te structureren en daarmee te optimaliseren. Dit is exact de definitie van code refactoring.
Uitgebreide documentatie over een applicatie
Code refactoring gaat logischerwijs hand in hand met een uitgebreide documentatie van een applicatie. In iedere cyclus moet worden bijgehouden welke aanpassingen er zijn doorgevoerd, welke bugs er uit de bestaande broncode zijn gehaald, enzovoorts. Het houdt de broncode leesbaar en maakt het op een later moment makkelijker om nieuwe functies toe te voegen of bestaande functionaliteit aan te passen.
Tegengaan van legacy code in de broncode door code refactoring
Een term die vaak terugkeert als organisaties de documentatie en periodieke code refactoring van een applicatie niet op orde hebben is legacy code. Onder legacy code verstaat men stukjes code in de broncode die geërfd zijn uit een oudere versie van het programma of uit andere applicaties. Vaak zijn juist dit de stukjes code waarover de documentatie ontbreekt, of waar men bij code refactoring niet aan durft te komen. Het ontbreken van de documentatie maakt het in dit geval immers lastig om vooraf te bepalen welk effect een aanpassing zal hebben op het functioneren van de applicatie. De kans op bugs in de software is groot!
Repeated code soortgelijk probleem bij niet het refactoren van code
Niet alleen legacy code ligt op de loer, wanneer men code refactoring niet periodiek toepast en de documentatie niet op orde heeft. Ook repeated code is een probleem wat regelmatig voorkomt. Onder repeated code verstaat men stukjes code die door twee verschillende ontwikkelaars zijn toegevoegd aan de broncode. Net als legacy code vergroten ook deze “gekopieerde” stukjes code de kans op bugs in de software. Immers, een aanpassing in een van beide stukjes code kan een heel ander resultaat hebben dan men op voorhand verwacht. Het stukje code zit gekoppeld aan andere functionaliteit, dan de functionaliteit die men hoopte aan te passen met een wijziging van de code.
Aan de slag met code refactoring
Wanneer je het gevoel hebt onvoldoende grip te hebben op de broncode van een applicatie, is het belangrijk zo snel mogelijk te starten met code refactoring. Bij de ontwikkeling van nieuwe maatwerk software is het raadzaam om vaste momenten in te plannen voor code refactoring en de documentatie vanaf het begin bij te houden.
