Hoe realiseer je kwalitatief goede code

  – Scheid concerns binnen modules (‘Separate Concerns in Modules’) – 

– Blog 8 – 

Kwalitatief goede software voorkomt hoge kosten voor onderhoud en aanpassingen, performance problemen, downtime, gegevensverlies en imagoschade. Vandaar dat we bij OVSoftware garant staan voor de goede kwaliteit van de softwarecode die we opleveren. Dit doen we onder andere door bij de ontwikkeling van maatwerk softwareoplossingen, de tien richtlijnen voor codekwaliteit van de Software Improvement Group (SIG) toe te passen. In een serie van tien blogs leggen onze IT-specialisten uit wat deze richtlijnen zijn, hoe zij developers ondersteunen bij het schrijven van code en welke voordelen ze opleveren voor de klant.

Separate Concerns in Modules’– wat houdt dat in?
Voor je mensen zonder kennis van technische aspecten van softwareontwikkeling de richtlijnen van de SIG uit kunt leggen, is het handig om eerst in te gaan op de betekenis van de gebruikte termen. In deze richtlijn komen ‘concerns’ ‘modules’ en ‘klasse’ aan bod, maar wat houden deze in? Een concern van een module bepaalt welke belangen deze module heeft en welke acties deze verzorgt. Een module bestaat op zijn beurt uit klassen die qua opbouw bij elkaar horen, waarbij een klasse staat voor een bestand met code. Vergelijken we het met meer toegankelijke techniek, bijvoorbeeld die in een auto, dan kun je zeggen dat er binnen een module code staat voor het ontvangen van energie. In een andere module staat de code voor de accu zodat deze energie kan versturen. Op deze manier zijn de concerns goed gescheiden. Als er daarentegen in de verlichtingsmodule ook klassen zijn die coderen hoé de energie uit de accu komt, dan is dat niet goed gescheiden en geeft het eerder problemen. Dus door er bij het ontwikkelen van softwarecode voor te zorgen dat je binnen een module niet meer dan één concern hebt, kun je naderhand wijzigingen in de code doorvoeren of nieuwe functionaliteit toevoegen zonder dat je daarbij het risico loopt dat er ergens anders ongewild (en soms ook ongemerkt) dingen fout gaan.

blank

Gökhan Güler

Meer informatie? Neem contact met mij op!


De richtlijn toegepast in de praktijk
Stel je voor dat je een applicatie hebt gemaakt waar de klant na verloop van tijd nieuwe features aan toe wil voegen of elementen van aan wil passen. Op dat moment zijn er een aantal dingen die bepalend zijn voor hoeveel dit gaat kosten: 1) de hoeveelheid code die aangepast moet worden, 2) hoe eenvoudig (of lastig) is het wijzigen van deze code, 3) hoe groot is het risico dat jouw wijziging ongewild iets stukmaakt dat door andere developers of de applicatie zelf wordt gebruikt en 4) hoeveel bestaande code je kunt hergebruiken. Het goed gescheiden houden van concerns binnen een module is vooral bepalend voor het derde punt, het risico dat er door een wijziging ergens anders in de code iets fout gaat.

Neem een voorbeeld uit de praktijk waarbij wij de opdracht hadden om een bestaand systeem voor het opstellen en wijzigen van documenten verder uit te breiden. Doordat het systeem klassen bevatte die niet goed aan de richtlijn voldeden, was het om te beginnen al heel lastig om te achterhalen wat het systeem precies deed en kon. Klassen waren enorm groot, hadden meerdere taken (ofwel teveel concerns) en alles liep in elkaar over, wat het geheel bijna onleesbaar maakte.  Ook het inwerken van nieuwe collega’s was lastig en het duurde lang voordat we aanpassingen aan het systeem door konden voeren. Aanpassingen in één deel van het systeem hadden bijna altijd ongewenste effecten in andere delen van de applicatie. Gelukkig hadden we een groot budget tot onze beschikking om de code- en databasestructuur voor de klant te kunnen verbeteren. Naast het financiële aspect heeft dit project het nodige bloed, zweet en tranen gekost.

blank


Zo helpt de richtlijn mij als ontwikkelaar
Als developers zich aan de richtlijn houden om concerns binnen modules gescheiden te houden, dan betekent dit dat je bij latere wijzigingen minder code aan hoeft te passen. Namelijk alleen díe code waar het op dat moment over gaat, zonder dat dit ergens anders een ongewenst effect heeft wat je door uitgebreid testen en aanpassen moet achterhalen en corrigeren. Dat geldt ook wanneer je interfacing en dergelijke toepast. Beschrijft je concern dat er een koppeling met welke willekeurige database dan ook gemaakt kan worden, dan kun je de database op elk moment, door elke gewenste database vervangen. Specificeer je in je concern nauwkeurig met welke database een integratie gerealiseerd moet worden, dan heb je te maken met een veel minder flexibele opzet. Het gescheiden houden van concerns betekent uiteindelijk ook minder stress voor mij als developer. Je hoeft dan niet de hele tijd op eieren te lopen in afwachting van wat er, waar fout gaat. Werk je met goed gescheiden concerns, dan kun je meestal ook meer bestaande code hergebruiken.


Dit levert de richtlijn op voor de klant
Het achteraf aanpassen van software waarbij de concerns binnen modules sterk met elkaar verweven zijn, is nogal een avontuur en kostbaar. Het doorvoeren van wijzigingen is duurder omdat je meer tijd kwijt bent aan het zekerstellen dat jouw wijzigingen geen negatief effect hebben op andere delen van de applicatie. Werk je aan een applicatie die al in de lucht is, dan moet je bij aanpassingen extra voorzichtig zijn omdat de fouten die je maakt direct merkbaar/zichtbaar kunnen zijn voor de buitenwereld. Tijdsdruk, het beschikbare budget en zeker ook de senioriteit van de betrokken developers zijn bepalend voor de kwaliteit van je softwarecode. Maar het leggen van een goede basis levert je uiteindelijk altijd meer op dan de investering die daar in eerste instantie voor nodig is.


Over de auteur
Gökhan is full stack developer bij OVSoftware waarvoor hij onder andere werkzaam is bij de ICTU, een onafhankelijke advies- en projectenorganisatie binnen de overheid. Gökhan werkt het liefst met .NET en C#, waarmee hij makkelijk uitbreidbare, goed leesbare code oplevert waardoor applicaties, websites en mobiele apps zo lang mogelijk meegaan.