Risiko- und Qualitätsschulden: Was Sie nicht wissen, kann Sie verletzen

Wenn es darum geht, das Risiko einer Codebasis zu bewerten, handelt es sich nicht um eine einzelne magische Ziffernzahl, und es handelt sich nicht um eine einfache Ampel, die nicht funktioniert. Das Risiko ist mehrdimensional und variantenreich und wird für verschiedene Organisationen unterschiedlich gemessen.

Sie wissen wahrscheinlich bereits, wo sich die risikoreichen oder „schlechten“ Teile des Codes befinden - es sind die Teile des Codes, die Sie ständig ändern, kleine Änderungen hier und da, um kleine Probleme zu beheben, die an sich harmlos erscheinen, aber normalerweise eine Überlagerung darstellen Merkmale zusätzlich zu schlechtem Design. Aus diesem Grund ist das Vornehmen von Änderungen am vorhandenen Code die häufigste Ursache für das Einbringen von Fehlern in eine Anwendung.

Wir wissen aber auch, dass der Wandel konstant ist. Sie implementieren nie alles vollständig oder korrigieren es beim ersten Mal, aber gleichzeitig geht das Wissen über jeden Anwendungsfall und jedes Szenario verloren, die Komplexität steigt und der Code wird immer riskanter, wenn Sie den vorhandenen Code überlagern. Es sind diese Änderungen, die den Schlüssel zum Anwenden des Kontexts auf das Risiko darstellen.

Genauso wichtig wie die Sichtbarkeit des Risikos selbst ist es, zu verstehen, wie man damit umgeht - wie man Sanierungsmaßnahmen priorisiert, um ein „akzeptables Risikoniveau“ zu erreichen und gleichzeitig die Auswirkungen auf die Teamgeschwindigkeit zu minimieren. Dieser Beitrag befasst sich genau damit: wie man das Risiko von Codeänderungen bewertet und wie man das Risiko effizient priorisiert und mindert.

Ermittlung des Multi-Varianten-Risikos

Das Risiko ist keine einzelne Zahl oder eine Ampel auf Projektebene (obwohl wir die leicht zuzuordnenden Ampelfarben in unserer Benutzeroberfläche verwenden), sondern eine Kategorisierung der Codebasis und eine Anleitung, wo echte und potenzielle Probleme auftreten existieren. Siehe unten:

Ein Beispiel für ein Kreisdiagramm aus der Process Intelligence Engine von Parasoft, das den Anteil von Code mit hohem, mittlerem und niedrigem Risiko zeigt.

Die Kategorisierung des Risikos ist sowohl mehrdimensional als auch variantenweise. Sie müssen Qualitätsmetriken aus Techniken wie statischer Analyse, Metriken, Codeabdeckung und Tests zusammenführen, um sie wirklich zu verstehen. Keine dieser Techniken gibt Ihnen den Wert für eine bestimmte Dimension, sondern einen Wert für eine Formel. Zum Beispiel ist die Codeabdeckung für sich genommen keine gute Zahl, da Sie eine 100% ige Abdeckung haben könnten, aber nur eine kleine Anzahl von Tests, die etwas Sinnvolles bewirken - Sie müssen darüber nachdenken, was Sie mit der Codeabdeckung sagen (dh "Wie gut ist mein Code getestet?") Und ergänzen Sie dies mit mehr Daten, um eine aussagekräftigere Analyse zu erhalten.

Ein Beispiel für ein Blasendiagramm mit riskanten Codeänderungen, das zeigt, wo die höchsten Risiken liegen. (Blasen können erweitert werden, um die Metriken anzuzeigen, die die Kategorisierungen steuern.)

Das obige Blasendiagramm zeigt die Kategorisierung des Risikos anhand von zwei Dimensionen (auch in der folgenden Tabelle dargestellt):

• Wartungsaufwandunter Verwendung einer Kombination aus Halstead-Volumen, strikter zyklomatischer Komplexität, Anzahl der Codezeilen und Verhältnis von Code zu Kommentaren, um zu quantifizieren, wie wartbar und verständlich der Code ist, und
• TestdefizitVerwenden Sie die Anzahl der Tests, die Anzahl der Methoden und die Codeabdeckung, um zu quantifizieren, wie gut der Code getestet wurde.

Schlecht getesteter Code (dh höheres Testdefizit) wird als hohes Risiko (rot) eingestuft, während gut getesteter und gut konstruierter Code (dh geringerer Wartungsaufwand) als geringes Risiko (grün) eingestuft wird.

Flüchtige Codebasen, bei denen jede Änderung ein Risiko darstellt

Während der Hitze der Entwicklung befindet sich Ihre Codebasis in einem konstanten Fluss und jede einzelne Codezeile, die geändert wird, birgt ein unbekanntes Risiko. Wird es ein grundlegendes Merkmal brechen? Führt es eine Sicherheitslücke ein? Je weniger Informationen, desto größer das Risiko. In früheren Beiträgen diskutieren wir die Auswirkungen von Änderungen auf das Testen und wie die Codeabdeckung intelligent verwendet werden muss, um vorherzusagen, wo sich die Testressourcen konzentrieren müssen. Selbst bei erhöhter Abdeckung und Tests besteht jedoch immer noch ein zusätzliches Risiko, das sich im Laufe der Zeit ansammelt.

Die Änderung der Codebasis gibt uns die dritte und wichtigste Risikodimension: Zeit. Nicht Zeit im traditionellen Sinne, sondern Zeit in Bezug auf die Builds und die Veränderungen zwischen ihnen. Wenn wir uns auf die Teile der Codebasis konzentrieren, die sich zwischen den Builds geändert haben, können wir uns darauf konzentrieren, den Code zu adressieren, der sowohl das höchste Risiko als auch das relevanteste ist, da das Team derzeit in diesem Teil der Codebasis arbeitet.

Verlangsamt Sie die Belastung durch Qualitätsschulden?

Wiederverwendeter und älterer Code hat bereits seine eigene Belastung, insbesondere für die Sicherheit. Jede eingereichte oder geänderte Codezeile erhöht diese Verschuldung, wenn keine ausreichenden Überprüfungen zur Aufrechterhaltung oder Verbesserung der Qualitätsgrundlage vorliegen. Um aus dieser Verschuldung herauszukommen, sind wie bei jeder Verschuldung Konzentration und die Verpflichtung zur Reduzierung erforderlich. Wie bei Schulden weiß man auch, wie man spart, wenn man nicht weiß, wo Geld ausgegeben wird?

Sobald Sie den Code mit dem höchsten Risiko und der höchsten Priorität identifiziert haben, müssen Sie auch den Arbeitsaufwand berücksichtigen, der zur Risikominderung erforderlich ist. Dies ist die vierte und letzte Dimension: Qualitätsschulden. In der obigen Blasendiagramm wird die Qualitätsverschuldung durch die Größe der Blase dargestellt. Je größer die Blase, desto bekannter sind die Probleme, die behoben werden müssen. In unserem Beispiel ist die Qualitätsverschuldung eine Kombination aus Verstößen gegen die statische Analyse mit hohem Schweregrad (einschließlich Verstößen gegen festgelegte Schwellenwerte für Codemetriken) und Testfehlern, normalisiert durch die Anzahl der logischen Codezeilen (siehe Abbildung 3).

Diese Zusammenfassung herausragender Qualitätsaufgaben gibt Hinweise zum relativen Arbeitsaufwand, der erforderlich ist, um das Risiko des Codes zu verringern.

Aber so messe ich Risiken nicht!

Nicht jede Organisation wird die gleichen Qualitätspraktiken anwenden oder sich darauf einigen, welche Faktoren bei der Berechnung der Dimensionen berücksichtigt werden müssen. Sie müssen in der Lage sein, Ihre eigene Risikodefinition zu konfigurieren und zu erstellen.

Das Beispiel in diesem Blog steht Benutzern auf dem Parasoft Marketplace zur Verfügung. Sie können es sofort verwenden und erweitern und ändern, um es Ihren spezifischen Anforderungen anzupassen. Beginnend mit dem Beispiel können Sie die statische Analyse, Metrikschwellenwerte und Risikokategorisierungen an Ihre Organisation anpassen.

Fazit

Das Abwägen von Budgets, Zeitplänen und Qualitätszielen mit angemessenen Sicherheitsmaßnahmen bei gleichzeitiger Zufriedenheit der Kunden ist eine große Aufgabe mit Risiken auf Schritt und Tritt. Die Automatisierung von Qualitätspraktiken und Prozessinformationen hilft Ihnen jedoch dabei, herauszufinden, wo Ressourcen am besten eingesetzt werden. Wenn Sie verstehen, wo das Risiko liegt und wie sich jede Codeänderung auf Ihre Basisqualität und -sicherheit auswirkt, werden viele Unbekannte in der Entwicklungsgleichung reduziert. Qualitäts- und Sicherheitsschulden können mit dem richtigen Fokus besiegt werden.