Corona-Warn-App – Auf dem Weg zu kritischen Technischen Schulden?

Wir haben unsere DETANGLE Analyse Suite zur Bewertung der Qualität und weiterer Risiken bzgl. Wartbarkeit und Erweiterbarkeit auf die Corona-Warn-App für iOS und Android angewendet. Bis Version 1.11 haben wir ermittelt, wie sich Features und Bugs im Code wiederfinden, haben die Architektur-Qualität gemessen, die Technischen Schulden geschätzt und die Risiken der Wissensverteilung analysiert.

Vorab möchten wir in aller Deutlichkeit unsere Anerkennung aussprechen, welche Leistung mit der Erstellung der Corona-Warn-App erbracht wurde. Das Gesamtsystem wurde unter hoher Medienaufmerksamkeit, engem Zeitrahmen, politischem Druck und sehr hohen Datenschutzanforderungen entwickelt. Wir möchten mit diesem Blog nun auf Qualitätsaspekte und Risiken hinweisen, die nach einem anfänglichen Entwicklungsstadium aus unserer Sicht Beachtung finden sollten.

Obwohl die aktuellen Code-Qualitätsmetriken aus SonarQube, dem verwendeten Tool zur Code-Analyse bei der Entwicklung der Corona-Warn-App, immer wieder bis Version 1.11 ein sehr gutes Rating für beide Apps aufzeigen, gibt es dennoch auffallende Findings, welche diesem guten Bild in Teilen widersprechen. In diesem Post gehen wir auf die Ergebnisse zur iOS-Version der App ein.

Mehr zur Corona-Warn-App im zweiten Teil des Blogs: (Collective) Code Ownership neugedacht – Über Risiken der Wissensverteilung am Beispiel der Corona-Warn-App

Mehr zu Technischen Schulden gibt’s hier: Technische Schulden erklärt am Beispiel eines beinahe gescheiterten Videospiels

Take-Aways

1. Weniger Entwicklungsaufwand für Features, mehr fürs Bug-Fixing

Bei der Betrachtung der Aufwandsverteilung für Features, Bugs und sonstige Arbeiten fällt auf, dass in Q4/2020 und in Jan/2021 der aufgebrachte Entwicklungsaufwand für Features  in 3 von 4 Monaten (inkl. Januar 2021) unter den Wert von 60% des Gesamtaufwandes gefallen ist. Umgekehrt ist der Wartungsaufwand in Form von Bug-Fixing in 2 von 4 Monaten (inkl. Januar 2021) auf 20% des Gesamtaufwandes gestiegen.

Abb. 1: Monate Juli 2020 – Jan 2021 Links: Anteil Bug-Fixing-Aufwand am Gesamtaufwand; Rechts: Anteil Feature-Entwicklungsaufwand am Gesamtaufwand

Das sind noch keine äußerst besorgniserregenden Aufwandsverteilungen,  aber sie könnten Frühindikatoren für eine Verstärkung des Trends eines sinkenden Feature-Durchsatzes darstellen.

Erläuterung der Messung des Entwicklungsaufwandes siehe [2].

2. Signal-Wert für den Feature-Debt in Q4/2020 überschritten

Anhand der DETANGLE Architektur-Qualitätsmetriken ist aber am Ausmaß der vorgefundenen Feature-Kopplung und Feature-Kohäsion im Code erkennbar, unter welchem Zeitdruck die ersten Versionen der Apps entwickelt werden mussten. In den Releases über die Sommermonate im dritten Quartal des Jahres 2020 war zwar ein Abnehmen der Technischen Schulden, wie wir sie messen, erkennbar.  Aber ab Version 1.7 und bis Version 1.11 wurde unserer Meinung nach im vierten Quartal des Jahres 2020 wieder ein Signal-Wert des gemessenen Feature-Debt-Index erreicht.

Abb. 2: Quartal 2, 2020 – Quartal 4,2020 Links: Feature-Debt-Index (FDI) über die 3 Quartale des Jahres 2020

Erläuterungen zur Feature-Kopplung, Feature-Kohäsion und des Feature-Debt-Index finden sich unter [1] und [3].

3. Architektur-Qualität dreier Feature-Blöcke zeigt Auffälligkeiten

Es besteht z.B. ein steigender Handlungsbedarf bezogen auf die Architektur-Qualität der Code-Module, wo folgende Features umgesetzt wurden:

1. Die mehrmalige Risikoberechnung pro Tag mit Version 1.7 vom Okt/2020 mit Berücksichtigung von 30min-Zeitfenstern zur Exposure Detektion der Übereinstimmungen von Begegnungen mit den heruntergeladenen anonymen Diagnose Keys von Covid-Betroffenen.
   Die entsprechenden GitHub Issues/PRs sind  hauptsächlich unter dem Stichwort “risk calculation” und “download packages” zu finden).
2. Die genauere Risikobewertung mit Version 1.9 vom Dez/2020, so dass mehrere einzelne Begegnungen mit niedrigem Risiko (grün) zu einem erhöhten Risiko (rot) führen können.
   Diese GitHub Issues/PRs sind im wesentlichen unter dem Stichwort “risk calculation” auffindbar.
3. Die verbesserten Abläufe zum Abrufen und Melden eines Test-Ergebnisses.
   Viele dieser GitHub Issues/PRs tragen das Stichwort “exposure submission”  wiederum im Titel.

Abb. 3: Kopplung der Risk Calculation Features (1472, 1457, 1518, 1541, 1550) zu anderen Features (nicht-nummerierte Kreisbögen) aus 4. Quartal, 2020.

Abb. 3 zeigt auf einem Kreis alle GitHub Issues/PRs aus dem 4. Quartal des Jahres 2020 als einzelne Kreisbögen. Eine Verbindung zwischen zwei Bögen stellt die Kopplung zwischen zwei Features dar. Die nummerierten Kreisbögen auf der rechten Seite repräsentieren die Features zur genaueren Risikoberechnung aus V1.9. Die Verbindungen legen eindeutig nahe, dass diese Features nicht nur untereinander, sondern zu vielen anderen umgesetzten Features aus dem 4. Quartal verwoben sind. Je umfangreicher die Kopplung unter nicht-verwandten Features, desto schwieriger wird es, neue Features ohne unbeabsichtigte Seiteneffekte zur Codebasis hinzuzufügen. 

Aus unserer Sicht ist damit zu rechnen, dass weitere Arten der Risikoberechnungen wie potentiell bei Besuchen von Restaurants, die einen QR-Code zum Einscannen bereitstellen, in die App Eingang finden werden. Was aber wiederum durch die nachlassende Erweiterbarkeit dieser Features aus V1.9 oder Ergänzbarkeit dieses Codes um neue Features ohne ein Refactoring zu stark ansteigendem Wartungsaufwand in Form von Bugs führen dürfte.

4. Quellcode-Verzeichnisse mit erhöhtem Feature-Debt

Die oben genannten Feature-Cluster konnten wir den jeweiligen Code-Bereichen mit einem erhöhten Feature-Debt-Index in Abb. 4 zuordnen.

Abb 4. Quellcode-Verzeichnisse. Feature-Debt-Index auf der x-Achse; Committer-Friction-Index auf der y-Achse (hier nicht relevant)

Dabei handelt es sich im Wesentlichen um folgende Quellcode-Verzeichnisse:

src/xcode/ENA/ENA/Source/Services/Exposure Submission
src/xcode/ENA/ENA/Source/Scenes/Exposure Submission
src/xcode/ENA/ENA/Source/Scenes/Exposure Submission/View
src/xcode/ENA/ENA/Source/Services/Exposure Transaction
src/xcode/ENA/ENA/Source/Models/Exposure
src/xcode/ENA/ENA/Source/Services/Risk/Provider
src/xcode/ENA/ENA/Source/Services/Risk/Calculation

In Abbildung 4 werden die Werte des Feature-Debt-Index für Verzeichnisse auf der x-Achse dargestellt (die y-Werte repräsentieren den Committer-Friction-Index (CFI), der erst im zweiten Blog zur Sprache kommen wird). Die Lines of Code der Verzeichnisse kommen durch die  Größe der Blasen zum Ausdruck. Die oben genannten Exposure Submission Verzeichnisse fallen unter die größten roten Verzeichnisse, während wiederum die Risk Verzeichnisse die größten beiden gelben Blasen darstellen. Diese genannten Verzeichnisse machen ca. 20% der Codebasis aus und sind in Q4/2020  um 50% bis 150% jeweils angewachsen.

5. Abnehmende Quellcode-Dokumentation

Die Quellcode-Dokumentation des gesamten Code-Basis ist in den letzten drei Monaten bis Ende Jan 2021 auf einen niedrigen Wert von 9% (an Kommentaren in Quelldateien im Vergleich zu deren nicht-leeren Zeilen Quellcode) gefallen. Insbesondere manche der oben als kritisch erachteten Quellcode-Verzeichnisse zeigen kritische Werte von 9% auf. Es liegt also eine Kombination von architekturellen Schwächen und mangelnder Verständlichkeit des Codes aufgrund geringer Code-Dokumentation in diesen Verzeichnissen vor.    

6. Kritische Quellcode-Verzeichnisse haben Konsequenzen

Konsequenzen in den o.g. Verzeichnissen werden bereits ersichtlich in: 

1. Einem nötigen, aber machbaren Abbau der Technische Schulden:

Der aktuelle Wartungsaufwand ist bereits um einiges höher als die Technischen Schulden, worunter wir den geschätzten Aufwand zur Verbesserung der Architektur-Qualität verstehen. Es lohnt sich daher, hier mit einem Refactoring anzusetzen, zumal der Verbesserungsaufwand gemessen an dem pro Monat umgerechneten Gesamtaufwand des letzten Quartals Q4/2020 ca. einer Mannwoche entsprechen würde.

2. Einem aktuell hohen Feature-Effort-Effectiveness-Index:

Der Aufwand zur Entwicklung neuer Features geht bereits mit einem erhöhten Refactoring-Aufwand zu deren Umsetzung einher.

7. Erhöhter Feature-Debt auch in test-Verzeichnissen

Einige der entsprechenden test-Verzeichnisse zu den obigen Quellcode-Verzeichnissen weisen auch kritische Feature-Debt-Index Werte auf. D.h. sie sind bezüglich der umgesetzten Features genauso verwoben wie der zu testende Code, so dass das Hinzufügen von Tests für neue Features auch mit Mehraufwand im Sinne von Umarbeiten verbunden sein dürfte.

8. Zugang zu Projekt-Issues eingeschränkt

Aufgrund des alleinigen Zugangs zu den GitHub-Projekten und ohne Zugriff auf die Tickets des nicht-öffentlichen SAP JIRA Issue Trackers können wir valide Ergebnisse nur für die iOS App anführen.

Die Gründe dafür werden unten genauer beleuchtet.  Erschwerend kommt hinzu, dass die Erfassung von Bugs, Features und deren Referenzierung bei der Entwicklung selbst innerhalb der iOS- und Android-App im Laufe des Projektes über die Monate sehr unterschiedlich gehandhabt wurde.

Um unsere Findings zur Corona-Warn-App-Entwicklung optimal für beide Apps nutzbar zu machen, müssten wir allerdings über die öffentlichen GitHub-Projekte hinaus ein Lesezugang zu den Tickets des nicht-öffentlichen SAP JIRA EXPOSUREAPP Projektes erhalten.

9. Benutzer-Feedback zu Features einholen?

Wir möchten als letztes “Take-Away” einen Vorschlag machen. Es gibt 25 Millionen Nutzer der Apps. Das ist eine nicht zu unterschätzende Möglichkeit anonymisiert Rückmeldungen einzuholen; sei es zur Meldung von Fehlern oder für freiwillige Umfragen im Rahmen der App-Nutzung mit Feedback zu potentiell neuen (oder laufenden) Features. Selbst die Meinung zu Feature-Optionen könnte man damit erfragen, um darauf aufbauend Entscheidungen für die Weiterentwicklung zu treffen. 

Ausblick – Risiken der Wissensverteilung

Aufgrund des Umfangs der Analysedaten war es uns in diesem Teil nicht möglich auf folgende Fragen eingehen:

• Wie sieht die Organisation bzw. Selbst-Organisation der Entwicklung aus?
• Gibt es Stabilitätsanker an Entwicklern, die konstant an der App oder dem System arbeiten? Ist das Software-Wissen zu den Apps gut verteilt? 
• Arbeiten die Entwickler gut zusammen, so dass das Team effektiv entwickelt? 
• Oder birgt die Zusammenarbeit ein gewisses Risiko und führt zu Qualitätsproblemen wie einer erhöhten Fehlerdichte?

Der zweite Teil der Blogserie wird Antworten darauf suchen und auf die Risiken in der Wissensverteilung bei der Entwicklung der Corona iOS App eingehen. 

Im Weiteren werden in diesem ersten Teil der Blogserie folgende Aspekte behandelt: 

• wie wir bei der Analyse anhand des Zugangs zu den Github Daten aber ohne Zugang zu den JIRA Tickets vorgangen sind
• wie wir zu den oberen Ergebnissen gekommen sind
• welche Empfehlungen wir im Detail zum Abbau der Technischen Schulden und gegen die Erosion der Feature-Erweiterbarkeit geben würden

Eine weitere Analyse – warum?

In der Software Entwicklung ist es gang und gäbe, Softwarequalität mittels Metriken der Code-Qualität zu messen. SonarQube hat sich unter Entwicklern fast schon als “Industriestandard” etabliert, um beispielsweise potentielle Bugs oder Code Smells, also schlechte Codestellen, im Code ausfindig zu machen. Das Tool bietet auch eine Schätzung der Technischen Schulden gemessen am Aufwand zur Beseitigung der besagten Codestellen an. 

SonarQube wurde daher auch bei der Entwicklung der beiden Corona-Warn-Apps durchgehend bei der gesamten Entwicklung eingesetzt.  Die Metriken von SonarQube zur Code-Qualität deuten für die beiden Corona-Warn-Apps durchgehend sehr gute Ratings an.

Bekanntermaßen ist Code-Qualität aber nicht alles. Die Frage nach der Architektur-Qualität ist mindestens genauso relevant!

Ganz konkret möchte man wissen, inwieweit die Architektur der beiden Apps die Entwicklung neuer Features oder die Erweiterung der bestehenden Funktionalität ermöglicht.  Aktuelle Ansätze bewerten eine gute Architekturqualität oftmals entlang gewisser Muster zu strukturellen Abhängigkeitsgraphen wie Aufruf-Hierarchien und -Zyklen zwischen Code-Modulen. Der Aussagewert dieser Bewertungen ist nur bedingt relevant, wenn es um die Fragestellung geht, wie weit die aktuelle Architektur die Entwicklung neuer Features begünstigt [4].

Wir haben daher mittels der DETANGLE Analyse Suite die Entwicklung der Apps anhand der Historie der GitHub Code-Repositories und der GitHub Issues und Pull Requests bezüglich der Architektur-Qualität analysiert und daraus priorisierte Handlungsempfehlungen abgeleitet, um die Wartungskosten in Form von Bug-Fixing aufgrund Technischer Schulden in Schach zu halten und die Feature-Erweiterbarkeit der iOS-App in bestimmten (aus unserer Sicht) künftig relevanten Code-Bereichen wiederherzustellen.

Zum Vorgehen

Die Erfassung von Bugs, Features und deren Referenzierung bei der Entwicklung des Codes wurde im Laufe des Projektes mittels GitHub Issues, GitHub Pull Requests (PRs) und JIRA Tickets des SAP-internen JIRA EXPOSUREAPP Projektes über verschiedene Zeitperioden unterschiedlich gehandhabt. Dabei wurde, unseres Erachtens, nach dem Umstieg als öffentliches Github Projekt das technische Koordinationsmittel der Pull Requests unter den Entwicklern im falschen Sinne zur Erfassung von Features und Bugs verwendet. Pull Requests sind hingegen ein Mittel zur Organisation gemeinsamer Codier-Arbeiten im Repository und sollten nicht fürs Requirements-Engineering verwendet werden. [5]

Die folgende Tabelle fasst die Facetten des unterschiedlichen Vorgehens bei der Entwicklung der iOS App über die Monate bis Jan 2021 zusammen.

Unser Vorgehen zum Bestimmen von Features und Bugs (und der auf sie zurückgehenden Änderungen im Code) bestand nun darin, aus Labels und Keywords von Github PRs und Issues deren Typ wie “feature”, “enhancement” und “bug” abzuleiten. Die Details dazu finden sich wiederum im Appendix. 

Die Bestimmung der Github PR/Issue Typen hat sich bei der Corona Android App nochmals schwieriger gestaltet, da wesentlich weniger PRs mit Labels und identifizierbaren Keywords vorhanden sind, was vor allem auf die Monate des Jahres 2020 bis September zutrifft. Das ist auch am prozentualen Anteil des durch DETANGLE erfassten Entwicklungsaufwandes für features, enhancements und bugs zu erkennen. Für die iOS App konnten über 70% des durch DETANGLE gemessenen Entwicklungsaufwandes den besagten Typen zugeordnet werden, während es bei der Android Entwicklung knapp 50% des Entwicklungsaufwandes ausmachen.  Daher können wir nur valide Aussagen für die Corona iOS App Entwicklung beanspruchen.

Unabhängig von den Umständen der Analyse ist zu hoffen, dass sich das im 4. Quartal abzeichnende Vorgehen für die weitere Versionsentwicklung etabliert. Dabei weisen die Vorgehensweisen bei der iOS und der Android App noch immer gewisse Unterschiede aus, auf die wir hier nicht eingehen. Für beide Vorgehensweisen gilt aber, dass die Verwendung des nicht-öffentlichen SAP JIRA Ticketingsystems die weitere Entwicklung der App in gewissem Grade doch intransparent erscheinen lässt.

Feature-Kopplung und Feature-Aufwand – Durchblick ohne Code-Kenntnisse

Erfreulicherweise lassen sich Schlüsse zur Architektur-Qualität bereits durch die reine Betrachtung der Features einer Version ziehen, ohne als Leser über Kenntnisse des Codes verfügen zu müssen. Durche eine geeignete Visualisierung der Feature-Kopplung lässt sich feststellen, inwieweit verwandte Features die gleichen Code-Stellen betreffen oder ob sie bereits über die Codebasis streuen und über eine hohe Schnittmenge zu den Code-Stellen anderer “fremder” Features im Code verwoben sind.

Damit eröffnet sich der Raum für Diskussionen zwischen den Produkt- bzw. Projektverantwortlichen und den Technikern, den Architekten bzw. den  Entwicklern über die Qualität der Architektur in Verbindung mit der künftigen Relevanz von Features. Falls für bestimmte Features (z.B. die Risikoberechnung) mit Erweiterungen oder Variationen zu rechnen ist, deren Feature-Kopplung über die Code-Basis hinweg ohne Durchsicht des Codes ersichtlich hoch ist, kann man schnell und fundiert die Entscheidung zur Ergreifung von priorisierten Refactoring-Maßnahmen des Codes hinter diesen Features gemeinsam mit allen Stakeholdern treffen.   

Im Folgenden gehen wir exemplarisch den verwandten Features für die jeweiligen Versionen V1.7  bis V1.11 nach. Dabei fangen wir aus “didaktischen” Gründen mit V1.10 an, kommen auf V1.11 zurück und gehen dann zu V1.9 bis V1.7 über.

Feature-Set in V1.10: Kontakttagebuch

Das bestimmende Feature-Set der Version 1.10 [8] war das Kontakttagebuch, worin der Benutzer seine Kontakte zu Personen und den Treffpunkt festhalten und über zwei Wochen zurückverfolgen kann.

GitHub PRs, die wir als Features (oder Teilarbeiten davon) der Version zuordnen konnten (Stichwort: “diary”, “legal” und “journal”):

• #1720: Feature/4199 contact journal UI tests
• #1707: Feature/task 4259 info screen legal texts
• #1701: Feature/4232 diary unit test
• #1694: Feature/3917 contact diary (STORY merge, already reviewed code)
• #1687: Feature/4174 diary edit entries screen
• #1676: Feature/3917 4180 contact diary persistence
• #1670: Feature/4172 diary day screen
• #1651: Feature/4171 diary overview screen

Das folgende Diagramm wirft einen Blick auf diese Features. Jeder Bogen entlang des Kreises stellt ein Feature (=GitHub Issue/PR) dar. Die Breite eines Bogens bildet den erbrachten Feature-Aufwand ab.

Abb. 5: Rein lokale Feature-Kopplung in V1.10

Es lassen sich visuell bereits folgende Schlüsse ziehen:

1. Zwei der nummerierten Features weisen einen hohen Aufwand auf, was insgesamt auf einen mittel-großen Aufwand dieses Feature-Sets hinweist.  
2. Die Features der Version 1.10 sind fast zu 100% nur untereinander gekoppelt. Es handelt sich also um eine rein lokale Kopplung basierend auf neuem Code. Es besteht nur eine Kopplung zu einem bestehenden Feature aus einer anderen Version. 
3. Die starke Kopplung der Features aus Version 1.10 untereinander erscheint unproblematisch und selbst bei einer guten Architektur-Qualität eher als eine normale Erscheinung bei der Umsetzung eines neuen Feature-Sets bis zur Herausbildung eines konsolidierten Code-Designs für die neuen Features.

Feature-Set in V1.11: Statistik

Das bestimmende Feature-Set der Version 1.11 [7] bestand in der Bereitstellung verschiedener vom Robert-Koch-Institut veröffentlichter bundesweiter Statistiken und deren Trends wie z.B. der Anzahl der Infizierten oder des R-Wertes.

GitHub PRs, die wir als Features (oder Teilarbeiten davon) der Version zuordnen konnten:

• #1829: Feature/3411 statistics
• #1825: Feature/task 4610 statistics app store screenshot
• #1820: Feature/task 3411 UI tests for statistics
• #1807: enhancement fetch & cache statistical dat
• 
  Abb. 6: Leichte nicht-lokale Feature-Kopplung in V1.11

Im Vergleich zu Version 1.10 handelt es sich bei diesem Feature-Set nicht um ein rein lokale Feature-Kopplung untereinander. Es ist eine gewisse, aber nicht übermäßige, Kopplung zu anderen nicht-verwandten Features erkennbar.

Fahren wir nun mit Version 1.9 fort, für die sich ein völlig neues Bild ergibt.

Feature-Set in V1.9: Risikobewertung und Testablauf

Version 1.9 [9] war bestimmt von der Berechnung einer genaueren Risikobewertung im Falle mehrerer “low-risk” Begegnungen. Des Weiteren wurde der Ablauf bei der Handhabung eines Testergebnisses verbessert. Die Github Issues/PRs zum ersten Feature-Set sind unter dem Stichwort “risk calculation”, die zum zweiten unter dem Stichwort “submission” und “result” aufgelistet.

Stichwort “risk calculation”:

• #1550: Feature/3854 risk calculation v2 ui
• #1541: Feature/3780 exposure window risk calculation v2 unit tests
• #1518: Feature/2582 risk calculation cleanup
• #1457: Feature/TASK 3483 risk calculation v2

Stichwort “submission” und “result”:

• #1626: Feature/task 4045 adjust exposure submission service
• #1583: Feature/3758 test result available cell
• #1562: Feature/3516 user consent switch automatic result sharing
• #1561: Feature/task 3630 testresult available
• #1319: feature Add new qr code information screen #2968

Abbildung 7 erfasst nun das Iris-Diagramm zum ersten Feature-Set der genaueren Risikobewertung:

Abb. 7: Breitgestreute Feature-Kopplung der Risikoberechnung in V1.9

Es ergibt sich ein scharfer Kontrast zum Bild zur Version 1.10 und 1.11. Rein visuell lässt sich bereits folgender Schluss ziehen: alle Features (nummerierte Bögen) des Feature-Sets sind breit mit vielen anderen nicht-verwandten Features (nicht-nummerierte Bögen) global über die Codebasis gekoppelt, obwohl ihr Gesamt-Aufwand im mittleren Bereich anzusiedeln wäre.

Abb. 8: Stark-gestreute Feature-Kopplung bzgl. Corona-Testablauf in V1.9

Ein ähnliches, noch verschärftes, Bild der lokalen UND globalen Feature-Kopplung (bei einem hohen Gesamtaufwand) ergibt sich beim zweiten Feature-Set des verbesserten Ablaufs zur Handhabung durch den User im Falle eines Corona-Testergebnisses. 

Als letztes schauen wir uns noch an, welches Bild sich in Version 1.7 ergibt.

Feature-Set in V1.7: Mehrmalige Risikokalkulation

In Version 1.7 [10] (Version 1.8 konnten wir übrigens nicht identifizieren) sind das Feature-Set der mehrmaligen Risikoüberprüfung pro Tag und die dahinterliegenden Github Issues/PRs, die unter den Stichworten “package”, “download” und “cycle” zu finden sind, interessant.

Stichwort “package“ und “download”:

• #1490: Feature/task 3611 risk detection only when new packages
• #1489: Feature/task 3667 dm disable hourly packages download
• #1483: Feature/task 3498 DM for hourly packages wifi mode toggle
• #1472: Feature/TASK 3582 increase risk calculation cycle
• #1468: Feature/Task 3583 Download Hour Packages on WiFi Only
• #1465: Feature/task 3497 download packages
• #1482: Feature/3298 reminder to share a positive test result

Abbildung 9 zeigt eine mittel-ausgeprägte Feature-Kopplung des Feature-Sets der mehrmaligen Risikoüberprüfung zu anderen nicht-verwandten Features.

Abb. 9: Feature-Kopplung bzgl. Risikoüberprüfung in V1.7

Nimmt man jedoch das Feature-Set zur genaueren Risikobewertung aus Version 1.9 hinzu, so verschmelzen Abbildung 7 und Abbildung 9 zu einem Bild in Abbildung 10. Daraus lässt sich folgern, dass diese beiden Feature-Sets aus den beiden unterschiedlichen Versionen, die beide den Code-Bereich der Risikoberechnung betreffen, sehr stark untereinander gekoppelt sind. 

Abb. 10: Feature-Kopplung bzgl. Risiko-Überprüfung bzw. -Bewertung in V1.7 u. V1.10

Folgende Zusammenhänge noch einmal zur Erinnerung: 

1. Features eines Feature-Sets aus einer Version können stark untereinander gekoppelt sein, da es bei der Implementierung eines neuen Feature-Sets einer gewissen Konsolidierung des Designs bedarf. Dieser Fall, wie z.B. im Kontakttagebuch aus V1.10, ist nicht weiter problematisch.
2. Im Falle einer breitgestreuten Kopplung von Features eines Feature-Sets zu vielen anderen nicht-verwandten, “fremden”, Features deuten diese Features auf Code-Stellen hin, die wiederum auf strukturelle Schwachstellen der Architektur verweisen.
3. Denn je umfangreicher die Kopplung unter nicht-verwandten Features, desto schwieriger wird es, neue Features ohne unbeabsichtigte Seiteneffekte zur Codebasis hinzuzufügen.
4. Daher gilt es, diejenigen Code-Bereiche hinter den breit-gekoppelten Feature-Sets zu identifizieren, die selber wiederum hohe Kopplungswerte und einen hohen Feature-Quality-Debt-Index aufweisen.

Der nächste Schritt besteht nun darin, diese Quellcode-Verzeichnisse und Quellcode-Dateien genauer zu untersuchen, um daraus Handlungsempfehlungen abzuleiten.

Betroffene Code-Bereiche

Die untere Tabelle 1 führt die Quellcode-Verzeichnisse mit kritischen Feature-Debt-Index (FDI) Werten auf. Sie nimmt Bezug auf Abbildung 4 und stellt die gleiche Information in Form quantifizierter Werte dar. Zur leichteren Vergleichbarkeit haben wir Abb. 4 hier nochmals vor der Tabelle aufgeführt.

Abb. 11 (wie Abb. 4): Quellcode-Verzeichnisse. Feature-Debt-Index auf der x-Achse; Committer-Friction-Index auf der y-Achse (hier nicht relevant)

Tabelle 1: Feature-Debt-Index im 4. Quartal 2020

Gelb markierte Werte stellen einen Signal-Level dar, während rote Zahlen erkennbar machen, dass ein kritischer Wert erreicht wurde. Die in den Take-Aways bereits erwähnten Quellcode-Verzeichnisse sind in der Tabelle hervorgehoben. Das sind genau diejenigen Verzeichnisse, welche für die breite Feature-Kopplung der Feature-Sets zur Ansteckungs-Risikobewertung/-Kalkulation und der verbesserten Handhabung von Testergebnissen aus den Versionen 1.7 und 1.9 verantwortlich sind. Zudem ist erkennbar, dass einige der dazugehörigen Test-Verzeichnisse auch einen Signal- oder kritischen Level erreicht haben.

Außerdem fällt auf, dass auch einige ContactDiary Verzeichnisse mindestens  Signal-Level erreicht haben. Im oberen Abschnitt zum Feature-Set Kontaktbuch der Version 1.10 wurde dargelegt, dass es sich dabei um eine lokale Kopplung dieser Features untereinander handelt. Das spiegelt sich hier wieder in den dazugehörigen Verzeichnissen. Diese lokale Kopplung kann bei der Berechnung des Feature-Debt-Index herausgerechnet werden. Wir haben es hier aber aus Gründen der Vollständigkeit und der Konsistenz der Aussagen unterlassen. 

Wartung (Bug-Fixing) als Auswirkung

Was sind nun die Auswirkungen und Symptome dieser hohen Feature-Debt Werte? Eine leicht erkennbare Auswirkung kann man im Umfang des Wartungsaufwands in diesen Quellcode-Verzeichnissen ausmachen. Tabelle 2 listet den Bug-fixing Aufwand aus dem 4. Quartal des Jahres 2020 auf (sortiert nach Ausmaß in der Einheit cLOC, also changed Lines of Code, wie unter [2] beschrieben). Wiederum sind einige der erwähnten Exposure Submission Verzeichnisse und Risk Verzeichnisse am meisten vom Wartungsaufwand betroffen.  

Tabelle 2: Defect-Effort im 4. Quartal 2020

Das Auftragen des Feature-Debt-Index auf der x-Achse und des Defect-Efforts als Bubble Size hilft in Abb. 12 das Ganze auch besser zu visualisieren. Man sieht, dass ein Zusammenhang zwischen Feature-Debt-Index und Defect-Effort besteht: je größer der Feature-Debt, desto größer der Bug-Fixing-Aufwand (als Bubble Size).

Abb. 12: Defect-Effort als Bubble Size versus Feature-Debt-Index und CFI

Implementierung neuer Features wird aufwändiger

Idealerweise möchte man messen können, ob das Hinzufügen neuer Features schwerer fällt. Dafür einfach die Anzahl an Features pro Zeiteinheit (z.B. Quartal) zu messen, ergibt irreführende Werte, da der Aufwand pro Feature sehr variiert. Unserer Erfahrung nach gilt für Entwicklungsaufwände pro Feature eher die Pareto-Regel, dass ungefähr 80% des Aufwands für ca. 20% der Features aufgebraucht wird. Unter [4] und [11] haben wir einen Ansatz erläutert, wie man den Refactoring-Aufwand bei der Implementierung neuer Feature anteilig berechnen kann. Dabei spielt das Verhältnis von Aufwand zu dem Anteil des neu erstellten Codes für das Feature eine Rolle. Je mehr sich das Verhältnis vom Wert 1 in Richtung 2 oder höher bewegt, desto höher sind die Refactoringanteile. Das gilt für einzelne Features aber auch für Quellcode-Verzeichnisse und -Dateien. 

Tabelle 3 führt diese Zahlen für Quellcode-Verzeichnisse auf. Wir nennen das besagte Verhältnis von Aufwand zu neu erstelltem Code für Features den Feature-Effort-Effectiveness-Index (FEE). Dabei wird erneut ersichtlich, dass hinsichtlich dieser Kennzahl die gleichen Quellcode-Verzeichnisse wie bzgl. Defect-Effort einen FEE Wert größer als 1.5 aufweisen.

Tabelle 3: Feature-Effort-Effectiveness im 4. Quartal 2020

Auch in dem Kontext ist eine Visualisierung mit dem Auftragen des Feature-Debt-Index auf der x-Achse und des Feature-Effort-Effectiveness als Farbe der Bubbles in Abb.  12 hilfreich. Eine rote Farbe bedeutet, dass die  Feature-Effort-Effectiveness des jeweiligen Verzeichnisses den kritischen Wert von 2.0 überschritten hat, während eine orange Färbung Signal-Level Werte zwischen 1.5 und 2.0 abbildet. 

Die identifizierten problematischen Quellcode-Verzeichnisse haben die höchsten Wartungsaufwände UND weisen Symptome einer bereits eintretenden schlechten Erweiterbarkeit um neue Features auf. Die Gründe sind strukturelle Schwächen der Architektur in diesen Bereichen des Codes wie wir sie mit dem Feature-Debt-Index messen. 

Kann man dies nun mit Bestimmtheit sagen?

Zum einen kann man schlechte Code-Qualität ausschließen. Wie bereits erwähnt, wird in der Entwicklung das SonarQube Tool dafür eingesetzt und für eine gute Code-Qualität Sorge getragen. Eine weitere Betrachtung aus einem neuen Blickwinkel in Tabelle 4 bringt zusätzliche Klarheit.

Tabelle 4: Defect-Impact im 4. Quartal 2020

Mit dem Defect-Impact erfassen wir das Ausmaß an sogenannten “Cognitive Bugs”, die sich als Konsequenz eines schlechten Feature-Debt-Index ergeben. Das Besondere daran ist, dass sich zum einen das Beheben dieser Bugs über mehrere Quellcode-Dateien hinweg erstreckt. Zum anderen kommt es in Code-Bereichen mit hohen FDI oftmals zu Folgebugs, die daher hoch zu den vorherigen Bugs gekoppelt sind. Ein Versuch zur Behebung eines solchen Bugs ist meistens nicht ausreichend, da man aufgrund der Verwobenheit der Features im Code das Verständnis über die zusammenhängenden Code-Stellen verliert, und oftmals nicht alle betroffenen Code-Stellen wie erforderlich auf einmal bereinigt. Mehr Details sind wiederum unter [12] zu finden. 

Rückgang an Code Dokumentation an kritischen Stellen

Es wird aber sichtbar, dass bisher bloß der Defect-Impact für das Risk/Provider Verzeichnis die gelbe Signal-Stufe erreicht hat. Also lässt sich daraus durchaus schließen, dass es neben den FDI Werten auch andere Faktoren für den hohen Defect-Effort bei den Exposure Submission Verzeichnissen gibt. Wie bereits besprochen kann es nicht an der Code-Qualität liegen. Daher haben wir den Stand der Source Code Dokumentation und deren Trends in den Exposure Submission Verzeichnissen und Risk Verzeichnissen analysiert. Dabei erachten wir ein Verhältnis von Kommentaren zu Programmcode ohne Leerzeilen (unserer Bezeichnung nach die Source-Code-Documentation (SCD) Ratio) unter 10% als einen kritischen Level und innerhalb von 10% bis 20% als Signal-Level. 

Tabelle 5: SCD Ratio und Defect-Effort für Exposure Submission im 4. Quartal 2020 und Jan 2021

Bei der Beobachtung der Trends  wird zudem sichtbar, dass die SCD-Ratio Werte in den Quellcode-Dateien der Exposure Submission Verzeichnisse in den letzten Monaten bis Januar 2021 kräftig gefallen sind. 

Abb. 14: Trends der SCD-Ratio Zahlen für Exposure Submission

In den Risk Verzeichnissen gibt es ähnliche, wenn auch weniger ausgeprägte Trends und Abfälle vom Dez 2020 auf Jan 2021. Die SCD-Ratio im relevanten Risk/Provider Verzeichnis liegt (im Gegensatz zum Risk/Calculation Verzeichnis) noch immer bei 17%, also recht nahe bei den unkritischen 20%.

Tabelle 6: SCD-Ratio und Defect-Effort für Risk im 4. Quartal 2020 und Jan 2021

Abb. 15: Trends der SCD-Ratio Zahlen für Risk

Zusammenfassung

Mittels DETANGLE schätzen wir auch den Verbesserungsaufwand, um diese kritischen Code-Bereiche zu refactorn. Wir sehen diesen Aufwand als das Ausmaß der Technischen Schulden an, die man in Zukunft zurückzahlen muss. Die Details der Berechnung sind hier weniger interessant. Es sei erwähnt, dass die Schätzung dieses Aufwandes gemessen an dem pro Monat umgerechneten Gesamtaufwand des letzten Quartals Q4/2020 laut DETANGLE einem machbaren Aufwand von ca. einer Mannwoche entsprechen würde. Wir lassen uns gerne daran messen, ob diese Aussage der Durchführung auch entsprechen würde. Wir empfehlen Refactoring-Arbeiten unbedingt als einen eigene nIssue-Typen aufzunehmen und Refactoring-Commits mit diesen Tickets zu assoziieren.

Feature-Netzwerk-Diagramme

Zum Schluss möchten wir noch auf eine weitere Visualisierung aufmerksam machen, welche die Auswirkung der Feature-Kopplung sehr plastisch zum Ausdruck bringt. Unter einem Feature-Netzwerk-Diagramm verstehen wir ein Netzwerk an Knoten und Kanten, welches Issues mit Quellcode-Dateien in Verbindung bringt.

Zum einen stellen die runden Knoten in Abb. 17 feature, enhancement und bug Issues/PRs in GitHub dar. Zum anderen sind die rechteckigen Knoten Quellcode-Dateien. Es besteht eine Kante zwischen einem feature, enhancement oder bug und einer Datei genau dann, wenn zur Umsetzung des Issues/PRs die Quellcode-Datei verändert wurde. 

Nun stellen Abb. 17 und Abb. 18 zwei unterschiedliche Perspektiven bzgl. der Feature-Kopplung dar. Abb. 17 enthält die Quellcode-Dateien mit hohen Feature-Kopplungswerten ab einem gewissen (recht niedrigen) Schwellenwert, während Abb. 18 Quellcode-Dateien aufführt, die sehr geringe oder gar keine Feature-Kopplung aufweisen.

Abb. 17: Feature-Netzwerk mit Quellcode-Dateien von hoher Feature-Kopplung ZeitraumJuli 2020 bis Januar 2021

Die roten Kreise stellen bug Issue/PRs dar. Quellcode-Dateien aus den Risk und Submission Verzeichnissen sind schwarz umrandet. Man kann mit bloßem Auge schnell feststellen, dass diese Dateien mit hoher Feature-Kopplung sehr oft verstärkt von Bugs (mit Rot gekennzeichnet) betroffen sind.

Abb. 18: Feature-Netzwerk mit Quellcode-Dateien von niedriger Feature-Kopplung, Zeitraum Juli 2020 bis Januar 2021

Abbildung 18 bietet ein Kontrastbild an. Quellcode-Dateien mit keiner oder niederschwelliger Feature-Kopplung sind im Großen und Ganzen nur sehr vereinzelt von Bugs geschweige denn vielen Bugs betroffen.

Diese beiden Bilder führen die Konsequenzen einer hohen Feature-Kopplung plastisch vor Augen. Falls ein Refactoring zur Beseitigung der architekturellen Schwächen der Feature-Kopplung ausbleibt, stellen diese Quellcode-Dateien eine Art Attraktoren für Wartungsaufwände dar und sind potentiell für deren unkontrolliertes Wachstum verantwortlich.

Links

[1] JCON 2020 Talk “Feature and Time-Based Software Analysis”,
How it works: https://youtu.be/aD4OQScGILo?t=510
2 Minuten: 8:30 – 10:32

[2] JCON 2020, “Feature and Time-Based Software Analysis”,
Measuring Development Effort: https://youtu.be/aD4OQScGILo?t=790
5 Minuten: 13:10 – 18:27

[3] JCON 2020, “Feature and Time-Based Software Analysis”,
Calculating Feature Debt: https://youtu.be/aD4OQScGILo?t=1073
10.5 Minuten: 17:53 – 28:30

[4] Blog Cape of Good Code, “Architektur-Hotspots trotz guter Abhängigkeitsstruktur”
https://capeofgoodcode.com/de/wissen/architektur-hotspots-trotz-guter-abhaengigkeitsstruktur/

[5] Github Pull Requests:
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

[6] Releasebeschreibung 1.12 Corona Warn App:
https://www.coronawarn.app/de/blog/2021-02-04-cwa-1-12-announcement/

[7] Releasebeschreibung 1.11 Corona Warn App:
https://www.coronawarn.app/de/blog/2021-01-28-corona-warn-app-version-1-11/

[8] Releasebeschreibung 1.10 Corona Warn App:
https://www.coronawarn.app/de/blog/2020-12-28-corona-warn-app-version-1-10/

[9] Releasebeschreibung 1.9 Corona Warn App:
https://www.coronawarn.app/de/blog/2020-12-16-corona-warn-app-version-1-9/

[10] Releasebeschreibung 1.7 Corona Warn App:
https://www.coronawarn.app/de/blog/2020-11-25-corona-warn-app-version-1-7/

[11] JCON 2020, “Feature and Time-Based Software Analysis”,
Refactoring-Anteile bei Feature-Implementierung messen:
https://youtu.be/aD4OQScGILo?t=871
3 Minuten: 14:34 – 17:50

[12] JCON 2020, “Feature and Time-Based Software Analysis”,
Cognitive Bugs: https://youtu.be/aD4OQScGILo?t=1658
2 Minuten: 27:38 – 28:22

Appendix – Details zum Vorgehen

Unser Vorgehen zum Bestimmen von Features und Bugs (und der auf sie zurückgehenden  Änderungen im Code) bestand nun darin, aus Labels und Keywords von Github PRs und Issues deren Typ abzuleiten. Dabei haben wir versucht, nicht nur die Typen “feature”, “enhancement” und “bug”, sondern auch die Typen wie “chore” (Hausarbeit), “refactor” und “technical” nach folgenden Regeln für Github PRs und Issues abzuleiten, wobei wir uns hier im Blog auf “feature”, “bug” und “enhancement” beschränkt haben.  Die Handhabung der Referenzierungen in Commits können wir hier auch nur anschneiden. Folgende Regeln haben wir vereinfacht angewendet:

1. PR/Issue Typ per PR/Issue Label festlegen, falls ein Label vorhanden war. Im Falle mehrerer Typen haben wir folgende Vorrangregel festgelegt:
   1. bug
   2. feature
   3. enhancement
   4. chore
2. PR/Issue Typ über Keywords im Titel bestimmen, falls kein Label vorhanden war: 
   1. Keyword “feature” im Titel: PR/Issue wird zu feature
   2. Keyword “bug” im Titel: PR/Issue wird zu bug
   3. Keyword “fix” aber ohne “typo” im Titel: PR/Issue wird zu bug
3. Pro Commit referenzierte PRs/Issues auflösen:
   1. Falls ein PR im Commit referenziert wird, werden zu diesem PR die im PR Titel weiter referenzierte PRs/Issues und deren Typ (über die ganze transitive Hülle an Referenzierungen) bestimmt.
   2. Zu jedem Commit wird der PR, zu dem der Commit laut Github zugeordnet ist, mitberücksichtigt.
   3. Anschließend werden alle PRs/Issues, die einen Typ haben, ausgewählt. Alle anderen PRs/Issues werden fallen lassen.
   4. Referenzierte PRs/Issues ohne Typ werden beibehalten, falls es keine PRs/Issues mit Typ-Angabe gibt.

Um einen besseren Eindruck zu gewinnen, seien einigeZahlen genannt für den Zeitraum ab Beginn, also dem 30.05.2020, bis zum 28.01.2021:

Zum Beispiel konnten wir aufgrund der Keywords im Titel von den 681 PRs ohne Label für 451 PRs (114 + 156 + 181) einen Typ bestimmen.