[SL] Erstkontakt: Ein Rundgang durch das Projekt Corona-Warn-App

Großprojekte sind ja selten öffentlich zugäglich, also wäre es doch interesssant, beim Projekt Corona-Warn-App mal einen Blick hinter die Kulissen zu werfen. Die App wird von der Deutschen Telekom (T-Systems) und SAP für den stolzen Betrag von 25 Mio Euro entwickelt und soll morgen offiziell freigegeben werden.

Der Quelltext ist auf 9 GitHub Repositories (von Android App bis Website) offen zugänglich, außerdem sehen wir dort die Entwicklungsgeschichte seit ca. 20. Mai 2020. Ich habe mir bewusst nur wenig Zeit genommen für einen ersten Rundgang.

Also was kann man über so ein Projekt herausfinden, indem man "nur mal kurz" darin herumwandert? Ziemlich viel, wie sich herausstellt…

Ersteindruck - die B-Note

Sehr gut: es gibt eine übergreifende Projektdokumentation, so geht es in der Solution Architecture um das technische Gesamtkonzept, es wird nicht an Schaubildern gespart:

Solution Architecture
Quelle: GitHub

Neue EntwicklerInnen können sich also nicht nur gut einarbeiten, es wird auch das gemeinsame Verständnis zur Lösung festgehalten.

Im Scoping Document wird gleich zu Beginn klargestellt, was wir hier machen:

The aim of the Corona-Warn-App is to identify SARS-CoV-2 chains of infection as quickly as possible and to break them. It does this by rapidly and reliably notifying people that they have had contact with infected persons and therefore may have been exposed to the virus. These individuals can then self-isolate, to help stop the SARS-CoV-2 pandemic.

Die Epics und User Stories gehen dann in's Detail. Ich greife mal zwei zentrale User Stories heraus:

Weiterer Pluspunkt: man kann (via GitHub) Feedback geben zur Dokumentation, wovon das Publikum schon regen Gebrauch gemacht hat. Nicht nur das, einige Externe liefern auch Beiträge zur Verbesserung der Dokumentation. So soll es laufen in erfolgreichen Open-Source-Projekten!

Alle Komponenten, inklusive der Website coronawarn.app sind als Quelltext verfügbar, in den GitHub repositories gibt es brauchbare README-Files zur ersten Orientierung, angefangen mit cwa-documentation/README.md.

Kontinuierliche Lieferung inklusive

Auch das ist mir positiv aufgefallen: In allen Repositories gibt es Automatisierung für Builds, Qualitätssicherung und Deployment (DevOps). Es ist sinnvoll (und best practice), dass diese Mechanismen von Anfang an mit eingeführt werden.

Mit etwas mehr Zeit würde ich hier in den einzelnen Teilprojekten systematisch tiefer einsteigen:

Weiter geht's: Ein Blick in den Source Code

Nun bin ich natürlich neugierig: Wie sieht es im Detail aus? Wie machen die EntwicklerInnen ihre Arbeit? In der begrenzten Zeit kann man natürlich nur Episoden sammeln und kein fundiertes Gutachten abgeben.

Aber auch Episoden haben eine gewisse Aussagekraft. Es ist ein bisschen wie wenn man ein neues Restaurant betritt: Krümel auf der Tischdecke, unfreundliche Bedienung und wenige andere Gäste sind schlechte Vorzeichen. Das kann man einschätzen, ohne Koch oder Profi-Restaurant-Kritiker zu sein.

Ich habe mich auf das Backend konzentriert, weil es mir technologisch am nächsten liegt (unabhängig davon, dass ich mit dem verwendeten Technologie-Stack keine Erfahrung habe).

Eine Backend-Komponente ist der “Verification Server”. Er sichert die Integrität der Testergebnisse, so dass sich niemand ein positives Testergebnis erschleichen kann.

Ich gehe gern zuerst mal in die Tests, in den Kommentaren VerificationApplicationTest.java sehe ich, dass viele Szenarios bedacht wurden:

Das ist ein gutes Zeichen!

In TanServiceTest.java finde ich eine Menge duplizierten Code, so wiederholt sich dieser Abschnitt an drei Stellen:

VerificationTan tan = new VerificationTan(); 
LocalDateTime start = LocalDateTime.parse(LocalDateTime.now().format(FORMATTER));
tan.setCreatedAt(start); 
tan.setUpdatedAt(start);
tan.setRedeemed(false);

Diese Art von Copy-Paste-Programming würden erfahrenere EntwicklerInnen nicht praktizieren, denn solche Duplikation ist immer eine Einladung für schwer zu diagnostizierende Bugs. Es wird unweigerlich zu Änderungen im Code kommen, bei denen einzelne Kopien des Abschnittes vergessen werden.

Dieses Phänomen der auseinanderlaufenden Kopien schon in Ansätzen zu beobachten:

VerificationTan tan = new VerificationTan();
tan.setCreatedAt(LocalDateTime.now());
tan.setUpdatedAt(LocalDateTime.now()); 
tan.setRedeemed(false);

Hier werden die Attribute CreatedAt und UpdatedAt auf leicht verschiedene Zeiten gesetzt (LocalDateTime.now()) ist die aktuelle Uhrzeit). Das könnte zu Problemen führen, wenn sich irgendwann mal jemand darauf verlässt, dass für eine “frisch erzeugte” TAN immer UpdatedAt == CreatedAt gelten muss.

Erfahrenere EntwicklerInnen hätten hier eine Factory-Methode verwendet, um Objekte für die Tests einheitlich zu erzeugen. Außerdem wird der Zweck des Tests klarer, wenn man unwesentliche Teile auslagert. Den obigen Abschnitt sollte man also ersetzen durch so etwas:

VerificationTan tan = makeFreshTan();

Apropos Duplikation: Ich war erfreut zu sehen, dass ein Entwickler als Teil seines Pull-Requests den vorhandenen Code verbessert, indem er mit Refactoring die Duplikation entfernt. Er macht das gewissermaßen im Vorübergehen, Hauptgegenstand seines Pull Requests ist das Hinzufügen eines Integrationstests (Bonuspunkte auch dafür!)

Interessanterweise ist das ein externer Entwickler (GitHub user name selectAll), der ein Sicherheitsproblem entdeckt hat (Issue #144) zu dem er auch gleich den o.g. Integrationstest mitliefert. In Issue #144 kann man sehr schön nachverfolgen, dass das Problem vom T-Systems-Team am selben Tag behoben wurde (Pull Request #145). Nur leider ohne einen zugehörigen Test! Es ist schade, dass der vom Externen nachgelieferte Integrationstest auch nach 8 Tagen immer noch nicht in den Code aufgenommen ist (Stand heute).

Das mag auch daran liegen, dass jeder Pull Request automatisch acht(!) Leute als Reviewer zugeordnet bekommt. Es müssen nicht alle ihr OK zu jeder Änderung geben, aber ich frage mich schon, ob dabei nicht ein paar Dinge liegen bleiben, weil jeder denkt, das sich jemand Anderes darum kümmert.

Der Blick auf das Große Ganze

Da müssten wir zunächst über den Scope sprechen, wie er im Scoping Document beschrieben ist. Ich habe übrigens nichts gesehen, was den Projektfortschritt als Ganzes darstellen würde – sind wirklich alle aufgelisteten Epics implementiert? Sicherlich gibt es so etwas intern bei T-Systems.

Wir vertreten ja die Auffassung, dass man Scope immer so strukturieren sollte, dass man ihn später ohne größere Kollateralschäden verringern kann.

Bei der Corona-Warn-App scheint, wie so oft, der Scope fest vorgegeben zu sein. Mag sein, dass es in diesem Fall das absolute Minimum ist, aber vielleicht hätte man doch eine erste Version schon früher bekommen können, indem man Teile der Funktionalität auf spätere Releases verschiebt?

Ein paar Vorschläge für eine reduzierte Version 1.0:

Wohlgemerkt, diese Punkte sind sicher wünschenswert und sollten in späteren Versionen nachgereicht werden. Trotzdem muss man darüber sprechen, ob ein früheres Release nicht mehr Wert hat als ein größeres Feature-Set. Das braucht den von uns propagierten Scope-Manager als produkt- und projektübergreifenden Experte und ein gutes Verständnis der Beziehung zwischen Features und Nutzen. (Kurze Zwischenfrage: Wie würden Sie den Nutzen der Corona-Warn-App quantitativ erfassen?)

Nun ist die Corona-Warn-App hochpolitisch, ich kann mir schon ausmalen, wie die Presse auf eine “unvollständige” Version 1.0 reagieren würde. Man darf also vermuten, dass eine Reduktion des Scopes nie zur Debatte stand.

In ein paar GitHub issues werden Themen angesprochen, die sich auf das gesamte Projekt beziehen. Das wären Steilvorlagen für qualifizierte Antworten eines Scope-Managers:

Das Scope-Management ist also, zumindest in der Außendarstellung, etwas unterrepräsentiert.

Fazit: Solider Eindruck

Trotz aller Kritik im Detail: Der erste Eindruck des Projektes Corona-Warn-App ist solide, ich habe nichts gefunden, was den Projekterfolg in Frage stellen würde. Wir dürfen gespannt sein, wie die Entwicklung nach dem ersten echten Release weitergeht.

Matthias Berth

Alle Emails