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
Door ‘copy & paste’ te gebruiken ipv ‘cut & paste’ zal er ook veel minder functionaliteit verloren gaan.
Code Duplication
Een interessant gezichtspunt, zoals Voinea en Reniers in Computable 18 tegen code duplication kijken: Duplication heeft voordelen, heeft nadelen, maar met een handig tool kan je al de nadelen teniet doen.
Ik zie het anders. DRY, dat herhaal ik maar één keer: Don’t Repeat Yourself. Een ontwikkelaar die haar vak verstaat heeft dat met grote letters in haar hersens gebrand. Zij heeft ook voldoende testcases. Als zij tijdens het programmeren ontdekt dat ze zichzelf aan het herhalen ben, gaat ze net zo lang aan het refactoren (dat kan dankzij de testcases) tot de duplicatie er uit is. Haast of geen haast, ze doet dat. Niet omdat ze dat zo leuk vindt, of omdat het zo hoort, nee, het loont dubbel en dwars.
Stel je voor, je programmeert, dupliceert en breng dan de hele code in productie. Vervolgens mag jij, of een ongelukkige collega, een tooltje gebruiken om te kijken waar de verdubbelde code zit en mag je dat handmatig gaan oplossen. Vreselijk, wat een saai en ondankbaar werk. Programmeurs die hun code dupliceren zijn vast en zeker niet de programmeurs die goede testen maken (of generaliseer ik nu), dus dat handmatig verminderen van verdubbelde code brengt ook een groot risico met zich mee dat je de code om zeep helpt.
Code duplication heeft het schijnbare voordeel dat je snel code schrijft, maar, zoals Voinea en Reniers zeggen, op lange termijn krijg je problemen. Volgens mij is die “lange” termijn al aan z’n eind op het moment dat je de Ctrl-V loslaat. Op dat moment heb je al twee stukken code die ieder een eigen leven gaan leiden.
Een bedrijf dat ontdubbeltools nodig heeft is in grote problemen, het is veel te duur uit: dure ontdubbeltools kopen, extra ontwikkeltijd, extra testtijd en programmeurs die het nooit leren (of gefrustreerd weglopen). De oplossing is lastig, maar goedkoop. Zorg dat je goede ontwikkelaars in dienst neemt, laat ze boeken lezen (b.v. The Pragmatic Programmer) en doe het in één keer goed. Als een goede programmeur twee keer zo duur is als een goedkope die alles dubbel doet is dat de eerste winst. Een boek is veel goedkoper dan een ontdubbeltool.
In het artikel wordt gesproken over cut & paste, iets waar ik geen problemen mee heb. Helaas wordt er copy & paste bedoelt.
Kortom: weg met de ontdubbeltool, leve de vakbekwame programmeur.
Jaap Droogers
Java programmeur
Natuurlijk is duplicatie van code niet goed. Alhoewel, soms juist wel.
Er moet gekeken worden naar de functie van de code. Het kan zijn dat twee verschillende ‘procedures’ momenteel gelijksoortige code nodig hebben, maar dat dit functioneel van elkaar gescheiden is. Ofwel code ‘a’ kan los wijzigen van code ‘b’, hoewel deze code nu gelijk is. En dan zie je nog wel eens dat de code ‘geoptimaliseerd’ wordt, bv. door overerving. Ja, laten we er gelijk maar lekker High Coupling van maken met Low Cohesion, bah, ik krijg er soms een punthoofd van.
Dus, natuurlijk is het goed om te zorgen voor zo min mogelijk duplicatie, maar ga daar niet te ver in.
Een andere kijk op hergebruik van code:
http://www.bits-chips.nl/nieuws/achtergrond/bekijk/artikel/configuratiemanagement-en-hergebruik-een-potentieel-gevaarlijke-combinatie.html