Umgang mit einer großen Code-Basis einer Angular-Anwendung

 Vor ein paar Tagen bin ich auf einen sehr interessanten Blog-Post gestoßen, auf den ich gerne aufmerksam machen möchte. Der Beitrag heißt How we upgraded a website with half a billion annual users to Angular 7 in less than a day.

Die beschriebene Angular-Anwendung hat einen riesigen Nutzerkreis und ist recht umfangreich. Und natürlich steht diese Anwendung vor der Herausforderung, dass die Angular Version regelmäßig aktualisiert werden soll. Denn in der Dokumentation von Angular ist beschrieben, dass alle 6 Monate ein neues Major Release veröffentlicht wird. Der Zeitplan dazu ist in der Dokumentation gut beschrieben. Jedenfalls bedeutet das, dass potentiell zwei Mal im Jahr ein Update ansteht. Wenn man das Update durchführt. Denn ein Major Update einer zentralen Komponente einer Anwendung bedeutet häufig der Umgang mit Breaking Changes. Und Breaking Changes sind erstmal unangenehm und kosten Zeit. Die Frage ist also unter anderem, ob man dieses Tempo halten kann und auch möchte.

Die Erfahrungen, die das Team mit diesen Updates gemacht hat, sind im verlinkten Blog-Post beschrieben. Ich möchte nicht zuviel vorweg nehmen. Aber eine Haupterkenntnis und wichtige Aussage möchte ich herausstellen, bevor ihr euch den Post anschaut.

We believe that the best measure of a healthy codebase and development team, is the time it takes from wanting a change to the time it is developed and deployed in production.

How we upgraded a website with half a billion annual users to Angular 7 in less than a day

Aus dieser Aussage ziehe ich eine entscheidene Erkenntnis. Dies möchte ich an einen Beispiel verdeutlichen. 

Steht man vor dem Update einer Kern-Bibliothek - z.B. ein umfangreiches Update von Spring Boot oder das Update einer GUI-Komponentenbibliothek - muss man meist mit umfangreichen Breaking Changes umgehen. In diesen Situationen zahlt es sich aus, wenn die Software eine saubere Schichten-Architektur vorweist und eine gute Test-Abdeckung besitzt. Denn durch fehlschlagene Tests kann man die problematischen Stellen schnell identifizieren. Falls also z.B. Änderungen in der Datenbankzugriffen notwendig sind, können diese ohne große Gefahr durchgeführt werden. Durch ein sauberes Design hat dies z.B. keine Auswirkung auf mögliche Rest-Schnittstellen oder andere Teile der Software.

Oder anders ausgedrückt: es können schnell Änderungen an wichtigen Stellen einer Software durchgeführt werden ohne gleich die ganze Anwendung umbauen zu müssen? Das spricht für eine sauber strukturierte Anwendung und eine gute Qualität des Codes und hilfreiche (Unit-)Tests.

Eine ähnliche Erkenntnis haben die Kollegen aus dem verlinkten Blog-Post. Ein Update einer wichtigen Bibliothek ist spielend einfach durchgeführt, wenn es sich um eine gut strukturierte Code-Basis handelt.

Viel Spaß beim Lesen!