Groter is niet altijd beter, en dat is in ieder geval zo in het geval van software. Meer software betekent altijd meer problemen, zeker gedurende de onderhoudsfase. De benodigde inspanning voor onderhoud wordt vaak gebaseerd op de grootte van de software, evenals de voorspelde kwaliteit.
Vraag een software manager of hij de grootte van de software wilt terugbrengen en je hebt direct zijn belangstelling. Dit onderwerp roept echter veel vragen op. Is het mogelijk de grootte van de software te verminderen zonder functionaliteit te verliezen? Wat zijn de kosten van zo'n operatie en betaalt het zichzelf terug?
Een voor de hand liggende manier om de grootte van software te verminderen is het verwijderen van programmacode die niet gebruikt wordt (ook wel 'dead code' genoemd) en het verwijderen van zogenaamde 'gold-plating code'. Dit is code die wel gebruikt wordt, maar in feite niet nodig is voor het implementeren van de software requirements. Voor een simpel tekenprogramma is bijvoorbeeld code die het getal pi benadert op honderd decimalen nauwkeurig niet nodig). Het grote probleem bij het verwijderen van dead- en gold-plating code is dat deze code moeilijk te identificeren kan zijn. Men loopt altijd het gevaar dat code verwijderd wordt die in speciale gevallen noodzakelijk blijkt, met alle gevolgen van dien. Een veiligere manier om de grootte van software te verminderen is het verwijderen van gedupliceerde code.
Code dupliceren
Gedupliceerde code is code die geproduceerd is door het kopiëren en aanpassen van bestaande code, ook wel bekend als 'cut & paste' ontwikkeling. Deze strategie wordt vaak toegepast als een manier om hergebruik van code te bevorderen. Onder tijdsdruk proberen veel ontwikkelaars gebruik te maken van reeds ontwikkelde en geteste software door code te dupliceren en daarna aan te passen naar de benodigde functionaliteit. In de meeste gevallen beperken de aanpassingen zich tot het hernoemen van variabelen, het wijzigingen van constanten, en het toevoegen of verwijderen van enkele regels code. Wat deze wijzigingen gemeen hebben is dat ze het gedetailleerde ontwerp van de software niet veranderen. 'Cut & paste' ontwikkeling vraagt daarom minder intellectuele inspanning van de ontwikkelaar en kan zo de ontwikkeling versnellen.
Op het eerste gezicht lijkt code duplicatie aantrekkelijk omdat het leidt tot hergebruik van code, een snellere implementatie, en minder inspanning van de ontwikkelaars. Op de lange termijn kunnen de gevolgen echter ernstig zijn. Naast het vergroten van de software heeft code duplicatie een negatieve invloed op de onderhoudbaarheid van reeds ontwikkelde code. Een klassiek voorbeeld in dit geval is het aanbrengen van wijzigingen in een stuk gedupliceerde code, ook wel een 'code clone' genoemd. Zo'n wijziging, laten we zeggen een bux fix, is in de meeste gevallen relevant voor alle locaties waar de clone voorkomt. Vaak wordt zo'n wijziging echter slechts op één locatie doorgevoerd, omdat de ontwikkelaar niet weet dat de code is gedupliceerd over meerdere locaties.
Als gevolg hiervan zal de bug-fix pas volledig doorgevoerd zijn na een aantal kostbare implementatie- en testiteraties. Als de software in de tussentijd vrijgegeven wordt, kunnen de kosten van de bug-fix zelfs honderden malen groter zijn. Daarnaast kan code duplicatie een teken zijn van een slecht ontwerp, waarin generieke functionaliteit niet voldoende is geabstraheerd. Deze anti-agile aanpak leidt op de lange termijn tot een langere ontwikkeltijd en doet daarmee de aanvankelijke versnelling teniet. We kunnen concluderen dat code duplicatie op de lange termijn vermeden moet worden, zeker in de onderhoudsfase.
Voordeel
Het grote voordeel van het elimineren van gedupliceerde code ten opzichte van het verwijderen van dead en gold-plated code is het bestaan van betrouwbare tools. Recente verbeteringen op het gebied van statische code analyse en hardware prestaties maakt het mogelijk duplicatie te lokaliseren in een industriële context.
Alhoewel veel bestaande tools betrouwbare en accurate resultaten geven, zijn er grote verschillen in de bruikbaarheid. De effectiviteit van een tool hangt sterk af van de context waarin hij gebruikt wordt, maar er is een aantal aspecten dat zeker overwogen moet worden bij het kiezen van een tool:
– Hoe gaat de tool om met spaties en commentaar?
– Kan de tool zogenaamde identifier renamings herkennen (bijvoorbeeld het hernoemen van een variabele)?
– Kan de tool omgaan met toevoegingen, verwijderingen, en wijzigingen binnen clones?
– Kan de tool omgaan met statements die verdeeld zijn ver meerdere regels?
– Worden de resultaten op een gebruiksvriendelijke manier gepresenteerd?
– Is de tool schaalbaar genoeg?
Acceptabele oplossing
In de meeste gevallen kan een acceptabele oplossing gevonden worden voor het identificeren van code clones. De vraag die overblijft is: 'Wat is het feitelijk voordeel van het verwijderen van deze clones?' Om deze vraag te kunnen beantwoorden moet men een afweging maken tussen de hoeveelheid gedupliceerde code, en daarmee de potentiële afname in software grootte, en de inspanning die nodig is om de code te refactoren. Het volledig elimineren van alle duplicatie zal in de meeste gevallen niet haalbaar zijn.
Gelukkig gedraagt code duplicatie, zoals met veel andere dingen in software, zich volgens het Pareto principe (ook wel bekend als de '80-20' regel). Met een kleine investering kunnen grote verbeteringen behaald worden. Een simpel recept voor het verwijderen van duplicatie met een minimale hoeveelheid inspanning en maximaal resultaat is het volhen van de volgende zeven stappen:
1. Kies een duplicatie detectie tool die schaalbaar genoeg is en om kan gaan met veranderingen binnen gedupliceerde code.
2. Gebruik de tool om alle code clones te vinden.
3. Als er minder dan 5 procent duplicatie is gevonden, ga naar stap 7.
4. Schat de potentiële verbetering bij refactoring van de top 5procent van de grootste clones.
5. Als minder dan 20 procent reductie behaald kan worden ga naar stap 7.
6. Re-factor de top 5 procent en ga naar stap 2.
7. Stop.
Door gebruik te maken van zo'n iteratieve strategie kan men zeker zijn van de hoogste return on investment.
Geen lust maar last
Als we terug gaan naar onze oorspronkelijke vraag, dan zien we dat code duplicatie een last is. Door duplicatie te verwijderen kunnen softwarebedrijven eenvoudig de grootte van hun code terugbrengen, en daarmee de onderhoudbaarheid verbeteren. Wat dit aantrekkelijk maakt is dat, door de juiste tools en strategie te kiezen, grote verbeteringen kunnen worden behaald met een relatief kleine investering.
Dr. Lucian Voinea, directeur SolidSource
Dr. Ir. Dennie Reniers, software designer SolidSource
Lucian Voinea en Dennie Reniers stellen dat code duplicatie schadelijk is voor de onderhoudbaarheid van software en dat dus het verwijderen van code duplicatie goed is. Waar de auteurs echter bij hun oplossing aan voorbij lijken te gaan is dat code duplicatie pas schadelijk is op het moment dat er gedupliceerde broncode gewijzigd moet worden. Tot die tijd kan de duplicatie weinig kwaad. Het verwijderen van duplicatie integraal onderdeel maken van het wijzigingsproces lijkt mij dan ook een betere, en meer agile, oplossing. Bij iedere wijziging krijgt het zoeken, verwijderen en voorkomen van duplicatie aandacht. Het zorgt ervoor dat de programmeur duplicatie verwijdert op de plekken waar het ook daadwerkelijk een probleem is. En het zorgt ervoor dat de investering in het verwijderen en voorkomen van duplicatie verspreid wordt over alle wijzigingen. Scheelt weer een lastige discussie met het management die het grootschalig refactoren juist als gold-plating ziet…
Frank Niessink stelt dat duplicatie pas schadelijk is op het moment dat er gedupliceerde broncode gewijzigd moet worden. Dit is niet altijd waar. In embedded systemen is het zuinig gebruik maken van resources vaak erg belangrijk: een grotere code stack vraagt meer geheugen en dat kan met name voor high-volume consumer producten nadelig zijn. Hiernaast zijn er grote systemen, waarin de (daily) build time in de hand gehouden dient te worden. Code duplicatie heeft in het algemeen een negatieve invloed op build time, hiernaast op de grootte van het software archief.
Op zich een leuk artikel, maar ik twijfel aan de haalbaarheid van de praktische uitvoering.
Zoals de auteurs al stellen, ontstaat duplicatie vaak doordat er onder tijdsdruk iets nieuws gemaakt moet worden, en er geen tijd is om herontwerp te doen.
Wanneer is er dan wel tijd voor het elimineren van de duplicaten? Het volgende project staat immers al weer voor de deur, en ook dat project staat weer onder tijdsdruk.
En in maintenance projecten doen we liever geen re-design of de-duplicatie meer. Immers, het product werkt nu,en we lossen alleen nog maar problemen op.
Gevolg, de duplicatiegraad zal in tijd alleen maar toenemen……….
@Frank Niessink: Ben het niet met je eens dat duplicatie pas slecht is als je het moet wijzigen; als ik die redenering (een beetje extreem) doortrek is het niet nodig om commentaar bij je code te schrijven totdat je besluit om hem ooit weer eens te gaan lezen. Op het moment dat je de wijzigingen maakt zit je juist het meeste “in” je code, na 1 maand kost het weer meer effort om te bedenken waarom je de code uberhaupt hebt gedupliceerd. En wat als je duplicate-tool niet goed genoeg is en een duplicate mist? Dat is een groot “broken window” om in de termen van Pragmatic Programmers te spreken, en past niet echt binnen agile.
@PaVaKe: Dat is juist het grote misverstand; developers denken tijd uit te kunnen sparen door code te dupliceren, maar in the long run kost het juist meer tijd. Dit is althans mijn eigen ervaring. Dit is misschien lastig uit te leggen aan managers, maar dat maakt het niet minder waar. Bovendien bestrijd ik dat het veel meer tijd kost om een stukje code generiek te maken, als je code al netjes geschreven is in the first place.
Helemaal eens met Martijn Coenen. Code duplicatie: daar wil je vanaf … Ik heb veel problemen gezien als gevolg van code duplicatie. Gekste voorbeelden:
– Pietje voert maintenance uit op een stuk code, Jantje ook op gedupliceerde code. Dubbel werk!
– Pietje lost een fout op, Jantje ziet de fout over het hoofd. Potentieel probleem!
– We willen re-use toepassen: welke code is het meest geeigend?
Mijn conclusie: code duplicatie is ongewenst, maar natuurlijk kom je er alleen in kleinere refactoring stappen vanaf. Nog beter: maak gebruik van tools om tijdens ontwikkeling code duplicatie te vermijden, dan hoef je achteraf ook niet te klagen dat er geen tijd voor is!
Code duplicatie is slechts een van de tientallen code style checks die je op je source zou moeten uitvoeren wil je de boel kwalitatief een beetje op orde houden. Puur focussen op duplicatie is kortzichtig; Start in ieder geval met het inrichten van een continuous integration methodiek met daarin een uitgebreidere set met QA tests, waar de duplicate/clone finding er eentje is. Findings op dat vlak vormen vervolgens een warning of een exceptie in je rapportage, afhankelijk van de vooraf gestelde kwaliteitseisen.
Wanneer je de juiste tools in place hebt voor automatische regressie tests, kun je refactoren (bv. het terugbrengen van duplicate code) zonder al te groote risico’s te lopen. In een Agile ontwikkelomgeving zal dit refactoren al tijdens de ontwikkelfase door de ontwikkelaars gedaan worden. Een duur tool is dan niet nodig.
Ik denk dat het echte probleem niet de aanwezigheid van gedupliceerde code is, maar het feit dat er mensen in je team zitten die het vrijuit copy-pasten van code als een geoorloofde ontwikkelmanier zien.
Wat je uiteindelijk zou willen is binnen het team een consensus bereiken over de voorwaarden waaraan kwalitatief goede code moet voldoen.
Om dit probleem bij de wortel aan te pakken zou ik, naast de eerder genoemde automatische controle hulpmiddelen, code reviews introduceren en een discussie op gang helpen over kwaliteitsbewustzijn. Spreek mensen aan op hun eergevoel en vakmanschap. Code duplicatie en broken window theory komen dan vanzelf langs.
@Martijn: ik ben het met je eens, maar je raakt de kern van het probleem wat ik beschrijf: probeer het eens verkocht te krijgen aan je manager. De gemiddelde projectmanager kijkt alleen naar de korte termijn (zijn eigen project). De langere termijn (onderhoud) is voor het maintenance project.
Voor degelijk ontwerpen is geen tijd, dan haalt’ie z’n deadlines niet.
@Joost: dat werkt misschien wel voor relatief kleine hoeveelheden code, die je van scratch af aan opbouwt, maar hoe had je dat in gedachten voor een code-base van zo’n 20 miljoen regels code, waarop je nieuwe ontwikkelingen gaat doen?
Code duplicatie is bij ons ongewenst, vreet geheugen. Leuke tools om dit te analyseren en te visualiseren gevonden op http://www.solidsource.nl. Zijn dit ook de schrijvers van dat artikel?