Hou je code componenten in balans

(‘keep architecture components balanced’)

“10 richtlijnen codekwaliteit”- Blog 2

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.

Code componenten in balans houden – wat betekent dat?

Een code component is een aantal pagina’s met code bij elkaar die verschillende dingen doen. Neem ruitenwissers, die kunnen aan en uit staan, langzaam, snel of extra snel gaan of bewegen met interval. Het snel bewegen en extra snel bewegen zouden qua code in één pagina staan, de getrapte beweging is ook een pagina op zich. Alle pagina’s, of ‘klassen’ zoals we dat in techtaal noemen, gaan over hetzelfde onderwerp en vormen samen het component. Het in balans houden van code componenten doe je door hen onderling niet te veel van elkaar te laten verschillen qua omvang. Door de hoeveelheid code per component ongeveer gelijk te houden en er goed over na te denken welke onderdelen je bij elkaar zet en welke niet. Goed groeperen dus. Als je alles op een onlogische manier in één grote en drie hele kleine componenten zou zetten, dan heb je onbalans. Deze onbalans is slecht voor de overzichtelijkheid van de code. De richtlijn dat je code componenten in balans houdt, is niet heel strikt, maar het is een guideline die je bij het ontwikkelen in je achterhoofd houdt.

De richtlijn toegepast in de praktijk

Ik was ooit ontwikkelaar bij een klant waar de balans in de code ver te zoeken was, met als gevolg dat ik veel tijd kwijt was om te achterhalen wáár in de code je moest zijn. Zijn componenten wel in balans, dan kun je veel sneller en makkelijker achterhalen waar de specifieke code zit die je nodig hebt om bijvoorbeeld een bug op te lossen. Als je één stuk code aanpast, kun je in theorie daarmee ook andere stukjes code beïnvloeden. Het is dus goed om te weten welke stukken code elkaar raken. Als de componenten klein zijn en logisch gegroepeerd, is ook dat veel eenvoudiger vast te stellen. Volgens deze richtlijn ligt het ideale aantal componenten rond de negen wat blijkt uit onderzoek (SIG).

blank

Laszko van Kessel

Meer informatie? Neem contact met mij op!
blank



Dit levert de richtlijn op voor de klant

Ook deze richtlijn heeft impact op de onderhoudbaarheid van software. Het zorgt ervoor dat onderhoud minder tijd en geld kost; dat je sneller in kunt grijpen als het fout gaat waardoor de applicatie weer sneller beschikbaar is. Als je code componenten in balans zijn, kun je vlot traceren waar de problemen zitten, preciezer ingrijpen en sneller corrigeren. Als de componenten niet te groot zijn, wordt testen ook minder complex. Je hoeft alleen díe specifieke kleine delen te testen waar het om gaat en de delen die mogelijk beïnvloed zijn in plaats van alle delen weer opnieuw door de molen te halen. Als je een nieuw onderdeel van de defecte ruitenwisser hebt geplaatst, ga je toch ook de bandenspanning niet checken?

Zo helpt de richtlijn mij als ontwikkelaar

Het naleven van deze richtlijn zorgt ervoor dat je als developer niet eindeloos aan het zoeken bent in enorme brokken code voordat je problemen kunt achterhalen en repareren. Ook het testen kun je beperken tot de specifieke delen die direct of indirect geraakt zijn. Dit scheelt gewoon veel tijd en vaak ook ergernis. Deze richtlijn van negen componenten is geen wetmatig getal, er zit bewegingsvrijheid in, maar is desalniettemin een goede check om mee te nemen.


Over de auteur

Laszko van Kessel is ooit begonnen als archeoloog en in een ver verleden omgeschoold tot software developer. Tijdens deze studie was hij vooral enthousiast over HTML programmeren omdat je daar direct resultaat van je werk ziet. Inmiddels is Laszko alweer 6 jaar werkzaam bij OVSoftware waar hij op een grote diversiteit aan projecten wordt ingezet om software te ontwikkelen en verbeteren. Zijn specialiteiten zijn: .NET, C#, SQL Server, Angular en HTML en Software Kwaliteit.