insight 
Je merkt het vaak op het moment dat software die door andere ontwikkelaars is geschreven – of zelfs een paar maanden geleden door jezelf – lastig te lezen en te doorgronden is. Of een nieuwe feature kost significant meer tijd dan normaal omdat code lastig uit te breiden is. Soms wordt een softwareproject gedwongen om een kwaliteitsaudit te doen omdat dit vanuit de industrie vereist wordt om in beheer te laten nemen. Vooral bij dat laatste is de druk vaak groot in het ontwikkelteam om aan de eisen te voldoen, veelal door technical debt dat ontstaan is in de loop der tijd.
Ik kwam in aanraking met het boek ’10 richtlijnen voor future-proof code’ van de Software Improvement Group (SIG), waarmee je de kwaliteit van software kunt verhogen. Ook tijdens de innovatiedag van VX op 24 januari heb ik deze richtlijnen doorgenomen met een aantal klanten en VX-collega’s. De reacties waren erg positief!
Met deze blog maak ik een selectie uit deze 10 richtlijnen en laat ik zien hoe ik ze in praktijk het meest toepas. Meer diepgang is te vinden in het boek ‘Building Maintainable Software – Ten Guidelines for Future-Proof Code, Joost Visser, ISBN 9781491954522 (C# edition)’. Op basis van de 10 richtlijnen wordt inzichtelijk gemaakt of de software van voldoende kwalitatief niveau is om een 4-sterren SIG score te behalen. Zodoende kan de overall score vergeleken worden met andere softwareprojecten.
Per richtlijn laat ik de inhoud zien, waarom deze nuttig is en technieken om toe te passen om aan de richtlijnen te voldoen.
Voordat ik begin, eerst nog over de definitie van een unit: een unit is de kleinste groep van code dat onafhankelijk uitgevoerd en onderhouden kan worden. In C# zijn dat: methoden (void), functies en constructors. Deze term zal ik verder dan ook gebruiken.
Write short units of code
Limiteer de inhoud van een unit tot maximaal 15 regels.
Waarom?
Met maximaal 15 regels is in één oogopslag de werking van de code te overzien, bij een groter aantal regels moet er vaak gescrold worden en is het overzicht weg.
Technieken om toe te passen:
Afsplitsen van blokken code in een nieuwe functie.
Write simple units of code
Limiteer het aantal aftakkingen in units tot maximaal 4.
Aftakkingen vinden plaats bij o.a. de volgende operatoren:
if, case, ?, ??, &&, ||, while, for, foreach en catch.
Waarom ?
Aftakkingen maken de software complexer en dus lastiger te begrijpen.
Technieken om toe te passen:
Bereken voor de code de McCabe index of ook wel cyclomatische complexiteit. Elke aftakking levert een punt op in de index of complexiteit.
In Visual Studio kan dit berekend worden vanuit het menu, zie https://blogs.msdn.microsoft.com/zainnab/2011/05/17/code-metrics-cyclomatic-complexity
Voorbeeld:
Spoor zogenaamde arrow-ifs op, dit zijn diep geneste if/else condities. Zie een voorbeeld hier: https://blog.codinghorror.com/flattening-arrow-code/
Hieronder een voorbeeld met de bekende ‘arrow-if’:
Write code once
Kopieer geen code. Ook wel het DRY (Don’t Repeat Yourself) principle genoemd.
Waarom?
Als code een bug bevat, moet dit op meer plekken worden aangepast, waardoor dit meer werk oplevert en ook meer kansen op fouten.
Technieken om toe te passen:
Splits code af in herbruikbare functies ten behoeve van hergebruik.
Je kunt ook deelbare code in een base class zetten.
Keep interfaces small
Limiteer het aantal parameters unit tot maximaal 4. Kom je er boven, zet dan de parameters in een object.
Waarom?
Code is overzichtelijker bij minder parameters. Ook is het makkelijker parameters toe te voegen als ze in een object staan, je breekt daarmee niet de bestaande interface.
Technieken om toe te passen:
Zet parameters die gerelateerd zijn aan elkaar in een nieuwe class.
Neem dit voorbeeld, waarbij je merkt dat er veel classes zijn als input van de constructor
Dit is een typisch voorbeeld van constructor over-injection. In de praktijk gebeurt dit vaak als veel uitbreidingen plaatsvinden op een class zonder dat er nagedacht is over de grootte en de verantwoordelijkheid van de class (Single Responsibility Principle (SRP)).
Pas dan ‘Refactoring to facade services’ toe, zie http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/
Tot slot
Hopelijk heb je met een selectie van 4 uit de 10 richtlijnen van SIG een goed beeld gekregen hoe je code onderhoudbaarder kunt maken voor de lange termijn. Ik pas deze richtlijnen regelmatig toe, zeker bij nieuwbouw, maar ook bij code reviews!
Wist je dat SIG ook een website heeft waarmee code op deze 10 richtlijnen automatisch getoetst kan worden? Kijk hier: https://bettercodehub.com/
Je kunt ook de Boy Scout Rule in acht nemen, waarbij je code die onderhanden is bij jou, beter achterlaat dan die was. Zo wordt een bestaande codebase kwalitatief steeds beter en je verlaagt je technical debt.
Succes met deze tips en happy coding 🙂
Meer weten over dit onderwerp?
Neem contact op met Joyce van Vliet
