Klasse Vetheid | Waarom het moet worden gemeten?

Hoe groot is je klas? – Hoe groot is te groot? Voor iedereen die de code schrijft, was er deze zorg: wat zou de ideale grootte van mijn code moeten zijn in een klasse/methode/functie. Het verschilt per ontwikkelaar. Als regel van 30 zegt Steve McConnell in zijn boek Code Complete dat als een element uit meer dan 30 subelementen bestaat, er hoogstwaarschijnlijk een serieus probleem is:

a) Methoden mogen niet meer dan gemiddeld 30 coderegels bevatten (regelafstanden en opmerkingen niet meegerekend).

b) Een klasse moet gemiddeld minder dan 30 methoden bevatten, wat resulteert in maximaal 900 regels code.

c) Een pakket mag niet meer dan 30 klassen bevatten, dus maximaal 27.000 coderegels.

Studies tonen aan dat het aantal regels code de basis vormt voor de kwaliteit en complexiteit van de software die je bouwt. De echte waarde van een richtlijn als de regel van 30 is wanneer u code beoordeelt en risico’s en kosten identificeert. Te veel regels code zijn moeilijk te compileren en te testen. Er zijn echter geen ideale statistieken die de vettigheid van de klas meten. Het is niet alleen gebaseerd op ‘mening’, het is gebaseerd op het resultaat van tientallen jaren praktijk. Codebeoordelingen helpen bij het identificeren en corrigeren van problemen in de codebase. In informele beoordelingen kunnen 20 %-30% codedefecten worden gevonden. Studies bij IBM, HP, Microsoft en andere plaatsen tonen aan dat het vele malen goedkoper is om bugs in coderecensies te vinden dan door te testen. En het bewijs blijft komen dat code reviews werken. Horus, een engineering management platform, helpt bij het beoordelen van de regels code die worden geschreven en wat deze betekenen voor de ontwikkelaars die ze schrijven, risico’s en kosten die ermee gepaard gaan voor het midden- en topmanagement, ongeacht het domein, het volwassenheidsniveau van de organisatie of de levenscyclusfase waarin ze zijn toegepast.
Lees meer over Horus in het vorige artikel. Lees ook Cyclomatische complexiteit