25. Januar 2023
In vielen Unternehmen, die Softwareprodukte herstellen, ist das folgende Problem gut bekannt:
Ein Quellcode wächst mit zunehmender Produktentwicklung, wird somit komplexer. Es wird also immer schwieriger für Mitarbeiter*innen anderer Teams sich in dem Code zurechtzufinden, was die Wahrscheinlichkeit von Fehlern erhöht. Diese Komplexität wird ausgedrückt durch die zyklomatische Zahl. Definition zyklomatische Komplexität laut ISTQB Glossar:
Die maximale Anzahl der linear unabhängigen Pfade in einem Programm. Die zyklomatische Komplexität kann wie folgt berechnet werden: L – N + 2P, wobei L: Anzahl der Kanten eines Kontrollflussgraphen N: Anzahl der Knoten eines Kontrollflussgraphen P: Anzahl der Verbundkomponenten eines Kontrollflussgraphen (z.B. ein aufgerufener Kontrollflussgraph oder eine Unterroutine).
Je höher also die zyklomatische Zahl, desto komplexer der Code und desto wahrscheinlicher das Risiko eines Fehlers.
Was aber sind neben Produkterweiterung Gründe für eine hohe zyklomatische Komplexität?
Das Management und der Vertrieb eines Unternehmens bestehen meist auf eine schnelle Veröffentlichung eines Produkts. Hier gilt also oft die Maxime: Quantität vor Qualität. Oft wird dem Entwickler Team nicht genug Zeit eingeräumt um, den Code “aufzuräumen”, ein sog. refactoring durchzuführen. “Das kommt dann eben in den nächsten Sprint”. Ein weiterer Grund kann die fehlende Kenntnis einiger Entwickler sein da es im Sprint keine Zeit gibt, um Wissenslücken zu füllen.
Wie kann die Komplexität und die damit verbundene Fehleranfälligkeit nun gesenkt werden?
Hierzu gibt es die Möglichkeit Tools für die Statische Codeanalyse einzuführen. Die statische Codeanalyse ist ein automatisches Lektorat, welches in den Deploymentprozess (CI/CD) mit eingebunden werden kann. Es findet Fehler im Code, die Konventionen verletzen oder Sicherheitslücken darstellen, und gibt Verbesserungsvorschläge, wie ein Code weniger komplex gehalten werden kann.
So ist es möglich lange Review-Sitzungen (im Worst Case sind mehrere Entwickler*innen durch diesen Termin geblockt und können in der Zeit nicht an neuen Produkten arbeiten) erheblich zu verkürzen (Zeit, die dann in den refactoring Prozess fließen kann), da sich in der Sitzung lediglich auf fachliche Anforderungen konzentriert werden kann.
Die von den Tools gefundenen Bugs und Sicherheitsverstöße werden klassifiziert. So ist ein Entwickler/Tester (m/w/d) z.B. in der Lage festzulegen, ab welcher Anzahl von Bugs einer bestimmten Klasse, ein Produkt nicht in den Abnahmetest kommen darf.
Wird dann ein Sprint dazu genutzt, ein Code Refactoring einzulegen, ist es sinnvoll KPIs einzuführen, bzw. an den Rest der Firma offen zu kommunizieren. Diese KPIs geben einen guten Überblick über die gefundenen/behobenen Bugs, die Komplexität des Codes oder z.B. welche Sicherheitslücken kritisch sind und erst mit einem Folge-Release verbessert werden.
Möchten Sie wissen, wie Ihr Unternehmen von einer Statischen Codeanalyse profitieren kann?
Kontaktieren Sie uns einfach. Wir freuen uns auf den Austausch mit Ihnen.
