Einführung in technische Schulden
Technische Schulden beschreiben die in Zukunft anfallenden Kosten, wenn heute eine einfache Lösung anstelle besserer Verfahren verwendet wird, weil deren Durchführung längere Zeit beansprucht.
Der Begriff „technische Schulden“ wurde gewählt, weil ein Vergleich mit finanziellen Schulden nahe liegt. Es kommt häufig vor, dass Menschen, die sich finanziell verschulden, Entscheidungen treffen, die zu diesem Zeitpunkt angemessen oder die einzige Option zu sein scheinen, aber dadurch steigen die Zinsen.
Je mehr Zinsen sich ansammeln, desto schwieriger wird es für sie in der Zukunft und desto weniger Möglichkeiten stehen ihnen später zur Verfügung. Bei finanziellen Schulden steigen bald die Zinskosten weiter an, sodass ein Schneeballeffekt entsteht. Auf ähnliche Weise können technische Schulden so weit gehen, dass Entwickler – geplant oder ungeplant – fast ihre gesamte Zeit für das Aussortieren von Problemen und Nacharbeiten aufwenden müssen, anstatt mehr Nutzen zu schaffen.
Wie kommt es dazu?
Die häufigste Ausrede sind knappe Terminvorgaben. Wenn Entwickler gezwungen sind, Code in kurzer Zeit zu erstellen, nehmen sie oft Abkürzungen. Anstatt eine Methode beispielsweise so umzugestalten, dass sie neue Funktionalität enthält, kopieren Entwickler Code, um eine neue Version zu erstellen. Dann testen sie nur ihren neuen Code und können den erforderlichen Testaufwand vermeiden, wenn die ursprüngliche Methode geändert wird, da andere Teile des Codes sie verwenden.
Jetzt liegen zwei Kopien (anstatt einer Version) desselben Codes vor, die in Zukunft geändert werden müssen, und es wird riskiert, dass die Programmlogik abweicht. Es gibt viele Ursachen. So kann es beispielsweise an technischen Fähigkeiten und Reife bei den Entwicklern mangeln, oder es gibt keine klare Produktverantwortung oder -ausrichtung.
Die Organisation hat möglicherweise überhaupt keine Codierungsstandards. Daher wissen Entwickler nicht einmal, was sie erstellen sollten. Die Entwickler haben möglicherweise keine genauen Anforderungen als Zielvorgaben. Sie könnten sogar noch in letzter Minute mit Änderungen der Anforderungen konfrontiert werden.
Erforderliche Refactoringarbeiten können verzögert werden. Es gibt möglicherweise keine Tests der Codequalität (manuell oder automatisiert). Letztendlich wird es immer schwieriger, in einem angemessenen Zeitrahmen und zu angemessenen Kosten Kundennutzen zu realisieren.
Technische Schulden sind einer der Hauptgründe, warum Projekte nicht die vorgesehenen Terminvorgaben erfüllen.
Im Laufe der Zeit wachsen sie in etwa auf die gleiche Weise wie finanzielle Schulden. Häufige Quellen für technische Schulden sind:
- Fehlender Codierungsstil und fehlende -standards.
- Fehlendes oder schlechtes Design von Komponententestfällen.
- Ignorieren oder Nichtverständnis von objektorientierten Entwurfsprinzipien.
- Monolithische Klassen und Codebibliotheken.
- Die Verwendung von Technologie, Architektur und Ansatz wurde nicht ausreichend geplant. (Vergessen, dass alle Systemattribute, die sich auf Wartung, Benutzerfreundlichkeit, Skalierbarkeit usw. auswirken, berücksichtigt werden müssen.)
- Übermäßiges Engineering von Code (Hinzufügen oder Erstellen von Code, der nicht erforderlich ist, Hinzufügen von benutzerdefiniertem Code, wenn vorhandene Bibliotheken ausreichend sind, oder Erstellen von Ebenen oder Komponenten, die nicht benötigt werden).
- Unzureichende Kommentare und Dokumentation.
- Fehlen von selbstdokumentierendem Code (einschließlich Klassen-, Methoden- und Variablennamen, die beschreibend sind oder die Absicht angeben).
- Verwenden von Abkürzungen zum Einhalten von Terminvorgaben.
- Beibehalten von totem Code.
Hinweis
Im Laufe der Zeit müssen die technischen Schulden zurückbezahlt werden. Andernfalls dauert die Fähigkeit des Teams, Probleme zu beheben und neue Features und Verbesserungen zu implementieren, länger und wird schließlich kostenintensiv.
Wir haben gesehen, dass technische Schulden während der Entwicklung eine Reihe von Problemen verursachen und es viel schwieriger machen, zusätzlichen Kundenwert zu schaffen.
Technische Schulden in einem Projekt beeinträchtigen die Produktivität, frustrieren Entwicklungsteams, führen dazu, dass Code schwer zu verstehen und anfällig wird, und verlängern die Zeit, um Änderungen vorzunehmen und diese Änderungen zu überprüfen. Ungeplante Arbeiten steht geplanten Arbeiten häufig im Weg.
Langfristig wird auch die Stärke der Organisation geschwächt. Technische Schulden neigen dazu, sich in einer Organisation einzuschleichen. Sie beginnen klein und wachsen im Laufe der Zeit. Jedes Mal, wenn ein schneller Hack durchgeführt oder das Testen umgangen wird, weil Änderungen im Eiltempo vorgenommen werden müssen, wird das Problem größer und größer. Die Supportkosten werden immer höher, und es entsteht unweigerlich ein ernstes Problem.
Schließlich kann die Organisation nicht mehr rechtzeitig und kostengünstig auf die Anforderungen ihrer Kunden reagieren.
Automatisierte Messung für die Überwachung
Eine wichtige Möglichkeit, die konstante Anhäufung technischer Schulden zu minimieren, ist die Verwendung automatisierter Tests und Bewertungen.
In den folgenden Demos untersuchen wir eines der gängigen Tools zur Bewertung der Schulden: SonarCloud. (Die ursprüngliche lokale Version war SonarQube.)
Es sind auch andere Tools verfügbar, und wir werden einige davon vorstellen.
Später (im nächsten Praxislab) erfahren Sie, wie Sie Ihre Azure Pipelines für die Verwendung von SonarCloud konfigurieren, die Analyseergebnisse verstehen und schließlich Qualitätsprofile konfigurieren, um die Regelsätze zu steuern, die von SonarCloud bei der Analyse Ihrer Projekte verwendet werden.
Weitere Informationen finden Sie unter SonarCloud.
Zu beurteilen ist Folgendes:
Azure DevOps kann in eine Vielzahl vorhandener Tools integriert werden, die verwendet werden, um die Codequalität während der Buildvorgänge zu überprüfen.
Welche Codequalitätstools nutzen Sie derzeit (falls zutreffend)?
Was gefällt Ihnen an den Tools und was nicht?