+31 (0) 53 30 33 600

Schrijf kleine functies (‘write short units of code’)

“10 richtlijnen codekwaliteit”- Blog 1

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 10 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.

Schrijf kleine functies – wat houdt dat in?

De eerste richtlijn in deze serie gaat over ‘write short units of code’. Het geeft aan dat je bij het schrijven van functies erop moet letten dat je het aantal coderegels beperkt houdt. Divers onderzoek van de SIG heeft uitgewezen dat de menselijke hersenen maar een beperkt aantal regels kunnen bevatten. Is er sprake van te veel regels, dan kun je het niet meer overzien en begrijpen. En code wordt nu eenmaal door mensen geschreven en onderhouden. Uit diverse studies en vergelijkingen van onder meer de SIG, blijkt dat 15 coderegels het optimale aantal is voor een mens om te bevatten. Er is zelfs een rekenmodel op losgelaten waardoor men deze conclusie met concrete cijfers heeft kunnen onderbouwen.

De richtlijn toegepast in de praktijk

Onderhoud aan software kun je vergelijken met onderhoud aan je auto: door intensief gebruik, voortschrijdende ontwikkelingen (inzicht) en veranderende wet- en regelgeving moet je onderdelen van de auto aan blijven passen en vervangen voor een optimale performance. Om vergelijkbare redenen moet ook software worden onderhouden en daarbij is het prettig wanneer dit op een efficiënte manier kan gebeuren.

Ik werk op dit moment veel aan onderhoud van legacy code die zo’n 10 tot 12 jaar geleden is ontwikkeld. Daarin kom ik met grote regelmaat veel te grote functies tegen met soms wel meer dan 30 regels. Dan merk ik dat het een stuk lastiger is en meer tijd vraagt om mee te werken dan wanneer de functies kort zijn. Het verkorten van code om software beter onderhoudbaar te maken, doe je door bepaalde regels code uit de grote functie te halen (extracten) en onder te brengen in een nieuwe functie. Visual studio (het programma waar ik mee werk) kan dat automatisch doen. De aanpassing op zich is dus eenvoudig, maar het vraagt wel om discipline om dit structureel door te voeren.

Laszko van Kessel

Meer informatie? Neem contact met mij op!


Dit levert de richtlijn op voor de klant

Al is het toepassen van deze richtlijn nog zo belangrijk, de klant ziet er in eerste instantie niets van. Wanneer je op slechte banden rijdt zal ook niet iedereen dit zien, maar is de kans op een ongeluk groter met veel schade en kosten tot gevolg. Zo is het ook met te lange functies die door de complexiteit de kans op fouten vergroten en de herstelkosten verhogen. Je wilt niet dat belangrijke software niet meer functioneert of dat er door een beveiligingslek gegevens op straat komen te liggen. En deurtjes die door slimme hackers kunnen worden opengezet, wil je zo snel mogelijk weer dicht doen. Kleine functies schrijven maakt de software inzichtelijker waardoor iedereen het snapt en ermee kan werken. Het maakt het ook eenvoudiger om onderhoud en aanpassingen door wisselende personen uit te laten voeren omdat de opbouw voor zich spreekt en goed ‘behapbaar’ is. Op termijn leveren kleine functies tijd en geld op.

Zo helpt de richtlijn mij als ontwikkelaar

Ik had nooit gedacht dat het maximum aantal regels met een vast getalletje aangegeven zou kunnen worden. Natuurlijk is 50 regels te veel, maar dat 15 dan het specifieke streefgetal is, had ik niet zelf kunnen bedenken. Maar het is wel fijn om te weten. Ik heb genoeg lange functies gezien die onmogelijk waren om te doorgronden. Het is niet alleen onoverzichtelijk, maar bij te lange functies kun je er bijna vanuit gaan dat er dan ook andere dingen niet goed zijn. De lengte van code heeft namelijk ook effect op de werking van de architectuur: bij lange code gebeurt er te veel in een specifieke functie, terwijl bepaalde dingen misschien veel beter op een heel andere plek zouden passen. Om in het voorbeeld van de auto’s te blijven: stel dat één en hetzelfde motortje de wielen én de ruitenwissers aanstuurt. Rijdt de auto snel, dan gaan de ruitenwissers snel, zelfs wanneer de zon schijnt. Het motortje dat de ruitenwissers beweegt moet in dit geval natuurlijk anders zijn dan die de wielen in gang zet. Voor coderegels in functies geldt hetzelfde. De richtlijn van maximaal 15 regels per functie geeft je als developer houvast. Getallen zijn voor technici hartstikke fijn: ze zijn duidelijk, logisch, het is goed of niet goed, ja of nee. Ik word er in elk geval blij van.


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.

Contact

Wil je meer informatie over OVSoftware?
Neem dan contact op.

Werken bij OVSoftware

Wil je meer weten over onze bedrijfscultuur en vacatures?
Bekijk dan onze werken bij pagina

Branches

Wil je meer weten over de branches waarbinnen OVSoftware actief is?
Bekijk de branches.

Referenties & Projecten

Lees hier klantreferenties en door OVSoftware begeleide lopende en afgeronde projecten waar wij trots op zijn.

Over ons

OVSoftware is één van de eerste softwarebedrijven van Nederland.
Lees meer over ons.

Volg ons op