Maak je software ‘future-proof’, je kunt het!

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!rnrnMet 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.rnrnPer richtlijn laat ik de u003cstrongu003einhoudu003c/strongu003e zien, u003cstrongu003ewaaromu003c/strongu003e deze nuttig is en u003cstrongu003etechniekenu003c/strongu003e om toe te passen om aan de richtlijnen te voldoen.rnrnVoordat 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.rnrnu003cemu003eu003cuu003eWaarom?u003c/uu003eu003c/emu003ernrnMet 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.rnrnu003cemu003eu003cuu003eTechnieken om toe te passen:u003c/uu003eu003c/emu003ernrnAfsplitsen van blokken code in een nieuwe functie.rnrnZie u003ca href=u0022https://refactoring.com/catalog/extractMethod.htmlu0022u003ehttps://refactoring.com/catalog/extractMethod.htmlu003c/au003e.

Write simple units of code

Limiteer het aantal aftakkingen in units tot maximaal 4.rnrnAftakkingen vinden plaats bij o.a. de volgende operatoren:rnrnif, case, ?, ??, u0026amp;u0026amp;, ||, while, for, foreach en catch.rnrnu003cemu003eu003cuu003eWaarom ?u003c/uu003eu003c/emu003ernrnAftakkingen maken de software complexer en dus lastiger te begrijpen.rnrnu003cemu003eu003cuu003eTechnieken om toe te passen:u003c/uu003eu003c/emu003ernrnBereken voor de code de McCabe index of ook wel cyclomatische complexiteit. Elke aftakking levert een punt op in de index of complexiteit.rnrnIn Visual Studio kan dit berekend worden vanuit het menu, zie u003ca href=u0022https://blogs.msdn.microsoft.com/zainnab/2011/05/17/code-metrics-cyclomatic-complexityu0022u003ehttps://blogs.msdn.microsoft.com/zainnab/2011/05/17/code-metrics-cyclomatic-complexityu003c/au003ernrnVoorbeeld:rnu003cfigure class=u0022clearfixu0022u003eu003cimg src=u0022https://vxcompany.com/wp-content/uploads/Visual-Studio.pngu0022 srcset=u0022u0022 alt=u0022Visual Studio@4xu0022 width=u0022100%u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/Visual-Studio.png 376w, https://vxcompany.com/wp-content/uploads/Visual-Studio@2x.png 751w, https://vxcompany.com/wp-content/uploads/Visual-Studio@4x.png 1502wu0022 /u003eu003c/figureu003ernSpoor zogenaamde arrow-ifs op, dit zijn diep geneste if/else condities. Zie een voorbeeld hier: u003ca href=u0022https://blog.codinghorror.com/flattening-arrow-code/u0022u003ehttps://blog.codinghorror.com/flattening-arrow-code/u003c/au003ernrnHieronder een voorbeeld met de bekende ‘arrow-if’:rnu003cfigure class=u0022clearfixu0022u003eu003cimg src=u0022https://vxcompany.com/wp-content/uploads/arrow-if.pngu0022 srcset=u0022u0022 alt=u0022arrow-if@4xu0022 width=u0022100%u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/arrow-if.png 170w, https://vxcompany.com/wp-content/uploads/arrow-if@2x.png 340w, https://vxcompany.com/wp-content/uploads/arrow-if@4x.png 679wu0022 /u003eu003c/figureu003e

Write code once

Kopieer geen code. Ook wel het DRY (Don’t Repeat Yourself) principle genoemd.rnrnu003cemu003eu003cuu003eWaarom?u003c/uu003eu003c/emu003ernrnAls code een bug bevat, moet dit op meer plekken worden aangepast, waardoor dit meer werk oplevert en ook meer kansen op fouten.rnrnu003cemu003eu003cuu003eTechnieken om toe te passen:u003c/uu003eu003c/emu003ernrnSplits code af in herbruikbare functies ten behoeve van hergebruik.rnrnJe 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.rnrnu003cemu003eu003cuu003eWaarom?u003c/uu003eu003c/emu003ernrnCode 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.rnrnu003cemu003eu003cuu003eTechnieken om toe te passen:u003c/uu003eu003c/emu003ernrnZet parameters die gerelateerd zijn aan elkaar in een nieuwe class.rnrnNeem dit voorbeeld, waarbij je merkt dat er veel classes zijn als input van de constructorrnu003cfigure class=u0022clearfixu0022u003eu003cimg src=u0022https://vxcompany.com/wp-content/uploads/constructor-over-injection.pngu0022 srcset=u0022u0022 alt=u0022constructor over-injection@4xu0022 width=u0022100%u0022 height=u0022autou0022 data-srcset=u0022https://vxcompany.com/wp-content/uploads/constructor-over-injection.png 192w, https://vxcompany.com/wp-content/uploads/constructor-over-injection@2x.png 383w, https://vxcompany.com/wp-content/uploads/constructor-over-injection@4x.png 766wu0022 /u003eu003c/figureu003ernDit 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)).rnrnPas dan ‘Refactoring to facade services’ toe, zie u003ca href=u0022http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/u0022u003ehttp://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/u003c/au003e

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!rnrnWist je dat SIG ook een website heeft waarmee code op deze 10 richtlijnen automatisch getoetst kan worden? Kijk hier: u003ca href=u0022https://bettercodehub.com/u0022u003ehttps://bettercodehub.com/u003c/au003ernrnJe 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.rnrnSucces met deze tips en happy coding 🙂