"Die DETANGLE® Analyse spiegelt die Anstrengungen wider, die zur Verbesserung der internen Architekturqualität des Vaadin Flow Frameworks unternommen wurden. Sie gibt auch Einblicke in mögliche zukünftige Qualitätsverbesserungen.”
Yuriy Yevstihnyeyev and Mikhail Shabarov
(Technical Lead und Product Owner Flow Framework)
Das Vaadin Entwicklungsteam hat in den letzten beiden Jahren große messbare Anstrengungen unternommen, die interne Architektur-Qualität des Vaadin Flow Webframeworks zu verbessern. Der Fokus auf Qualitätsverbesserungen statt alleiniger Feature-Neuentwicklung hat sich bezahlt gemacht. Der steigende Wartungsaufwand zur Beseitigung neuer Bugs konnte im Jahr 2021 reduziert und 2022 konstant gehalten werden.
Abb. 1: Wartungs- vs. Primary/Feature-Entwicklungsaufwand in % (2018-2022)
Die Diagramme in Abbildung 1 zeigen links den Wartungsaufwand über die letzten fünf Jahre bis Ende 2022 und rechts gegenüber den Feature-Entwicklungsaufwand. DETANGL®E misst den Aufwand als eine Gewichtung der changed Lines of Code über die Commit-Historie des Code-Repositories hinweg. Details zu dem Vorgehen finden Sie hier.
Auffallend ist der besagte Rückgang der Feature-Entwicklung in den Jahren 2021/22, so dass der Aufwand 2022 leicht unter dem kritischen Schwellenwert von 40% gegenüber einem Wert von 65% im Jahr 2020 liegt. D.h. der Fokus der Entwicklungsarbeit in 2021/22 lag nicht nur auf der Entwicklung neuer Features, sondern auf verstärkten Verbesserungsarbeiten im Code.
Das wird durch die Diagrammen der Abbildung 2 bestätigt, wo nun links die Verbesserunsaufwände mit den besagten Feature-Entwicklungsaufwände rechts verglichen werden können:
Abb. 2: Improvement vs. Primary/Feature-Entwicklungsaufwand in % (2018-2022)
Verbesserungsarbeiten wurden im Projekt unter den Tickettype “Chore” (auf Deutsch “Hausaufgaben”), “Refactor”, “Internal improvement” und “Performance” erfasst und betrugen 28,56% des Entwicklungsaufwands im Jahr 2022. Das macht im Zeitraum 2021-2022 mehr als den Anteil der Wartungsarbeiten bzw. mindestens die Hälfte des Umfangs der jeweiligen Feature-Entwicklung aus.
Somit ist leicht zu erkennen, dass sich der Fokus der Arbeiten der Entwicklungsmannschaft im Zeitraum 2021-22 teilweise weg von der Feature-Entwicklung zu den Verbesserungsarbeiten an der Software-Qualität durch das Hinzufügen von Tests, dem Refactoring und Performance-Verbesserungen verlagert hat.
Das Resultat ist eindeutig. Die DETANGLE Qualitätsmetriken zur Software-Architektur zeigen nun in Abbildung 3 für die Jahre 2021/22 aufgrund der Verbesserungsarbeiten einen starken Abwärtstrend hin in den grünen Wertebereich im Vergleich zu den Jahren vor 2018-2020.
Abb. 3. Primary/Feature Debt Index (PDI) und
Contributor Friction Index (CFI) im Zeitraum 2018-2022
Der Primary Debt Index (manchmal auch Feature Debt Index genannt) misst die Einhaltung des Single-Responsibility- Prinzips auf Architektur-Ebene. Zum einen sollten neue Features im Code kohäsiv umgesetzt worden sein bzw. die Architektur sollte das ermöglichen. Das heißt, dass ein Feature nicht über die gesamte Codebasis verstreut sein darf. Zum anderen sollten Features, die unabhängig voneinander sind, in der Codebasis nicht gekoppelt zueinander sein. Feature Cohesion und Feature Coupling ergeben zusammen den Feature bzw. den Primary Debt Index (PDI).
Weitere Details dazu finden Sie hier. Bzw. eine Erklärung zum Contribution Friction Index (CFI), der zweiten DETANGLE® Architektur-Metrik, finden Sie wiederum an dieser Stelle.
Die wenigen verbleibenden Hotspots im Code wurden mit DETANGLE® identifiziert und daraus konkrete Handlungsempfehlungen zum Refactoring abgeleitet, um deren Design-Qualität zu verbessern. Dabei handelt es sich vorwiegend um das Design der “frontend” Codebereich, wie folgende Tabellen der Source-Folder zeigen:
Abb. 4: Verbleibende “frontend” Hotspot Verzeichnisse
Die beiden ersten Tabellen zur Architecture Extensibility zeigen genau zwei “frontend”- Folder an, deren Primary Debt Index (PDI) gelb markiert sind, da deren Wert über der Warning-Schwelle liegt.
Dabei handelt es sich um den flow-server/src/main/java/com/vaadin/flow/server/frontend Folder und dem entsprechenden test-Folder. Die beiden Folder machen jeweils rund 16kLOC aus, so dass sie zusammen knapp 10% der gesamten Codebasis darstellen. Beide sind ungefähr im gleichen Umfang von ca. 1.5k changed LOC an Wartungsaufwand betroffen, wobei dieser im test-Folder bereits bei 23% des gesamten Entwicklungsaufwands und im src-Folder knapp unter 20% liegt.
PDI ist ein Maß für Architecture Extensibility. Es misst die Modularität des Codes im Sinne, ob neue Features kohäsiv ohne starke Kopplung zu bestehenden Features im Code implementiert werden können. Daraus lässt sich schließen, dass sowohl die Source-Files in flow-server/src/main/java/com/vaadin/flow/server/frontend als auch der test-Files untereinander stark gekoppelt sind und sich darin neue Features weiterhin kaum ohne unbeabsichtigte Seiteneffekte (wie neuer Bugs) umsetzen lassen.
Ergänzend dazu messen die DETANGLE® Metriken Defect Density (DI) und Defect Impact (DI) in der dritten Tabelle die Architecture Maintainability. Defect Density sagt aus, wie stark der Code von neuen Bugs betroffen ist (Anzahl pro 1000 Zeilen neuem Code). Zudem gibt Defect Impact an, in welchem Umfang Follow-up Bugs auftauchen, d.h. wie stark das Fixing von Bugs untereinander gekoppelt ist und öfters die gleichen Codestellen betrifft. Daher zeigt die dritte Tabelle an, dass der flow-server/src/main/java/com/vaadin/flow/server/frontend Folder auch unter dem Aspekt Architecture Maintainability bzgl. seiner DD- und DI–Werte auffällt, und die gefürchteten Seiteneffekte bei der Umsetzung neuer Features weiterhin auftreten.
Mit DETANGLE ist es möglich, ein Drill-down zu den Source-Files dieser beiden Folder durchzuführen und zu einer Liste der Hotspots auf File-Ebene wie in Abbildung 5 dargestellt zu gelangen.
Abb. 5: Verbleibende “frontend” Hotspot Dateien
Des Weiteren kann man diese Source-Files, deren Feature-Kopplung und Kohäsion auch qualitativ mittels eines DETANGLE® Netzwerk-Graphen untersuchen. Daraus lassen sich Refactoring-Empfehlungen wie das Aufteilen eines Source-Files oder das Extrahieren von Code aus mehreren Files zu einem neuen File ableiten. Darauf soll in einem separaten Blogbeitrag eingegangen werden.
Zusammenfassend kann man sagen, dass das Vaadin Flow Open-Source Webframework auf dem besten Weg zu einem hohen selbst gesetzten Qualitätsstandard ist und für den Einsatz in kommerziellen Projekten sehr empfohlen werden kann.
Neue Requests und Anforderungen seitens der Kunden dürften mit Leichtigkeit von der Entwicklungsmannschaft nun umgesetzt werden können, ohne einen hohen Wartungsaufwand oder den Bruch bestehender Features nach sich ziehen zu müssen.