Wir kennen alle diese Situation: Ein Framework oder eine Library, die man im Projekt einsetzt, ist veraltet und wird nicht mehr gepflegt. Vor fünf Jahren galt sie noch als State of the Art – heute muss sie dringend ersetzt werden. Doch dafür braucht es Zeit, die im Projektalltag selten vorhanden ist. Der Product Owner müsste eigentlich ein Zeitfenster für die Code-Migration freigeben, doch aktuell liegt der Fokus klar auf der Entwicklung neuer Features. Der Druck durch Stakeholder und Markt ist hoch – Stillstand ist keine Option.
Progressive Migrationen: Zwischen Pragmatismus und Stillstand
Also machst du eine progressive Migration. Immer wenn sich ein paar Minuten Zeit ergeben, migrierst du Stück für Stück einzelne Codestellen. Entweder nimmst du dir am Freitagabend etwas Zeit für solche Änderungen, oder du fixt den Code immer, wenn du aus anderen Gründen in bestehendem Code etwas abändern musst. So oder so: Solche progressiven Migrationen dauern viele Monate bis Jahre und sind mühselig. So sollte es niemanden überraschen, wenn die Begeisterung und Disziplin nach einigen Monaten nachlässt und der Fortschritt zum Erliegen kommt.
Migrationsfortschritt: Mit einem einfachen Skript zur besseren Übersicht
Unser Team war auch in genau so einer Situation. Wir hatten mehrere fortlaufende Migrationen und es war sehr schwierig, den Überblick zu behalten. Wie weit waren die Migration fortgeschritten? Welche Codestellen müssen noch migriert werden? Welche Migrationen sind aktuell im Gange? Um diese Fragen zu beantworten, habe ich mir ein einfaches Skript geschrieben. Es findet sämtliche Codestellen, die noch angepasst werden müssen, und jene, die bereits migriert sind. Damit kann man dann vergleichen, wie weit die Migration vorangeschritten ist und welche Codestellen noch migriert werden müssen.
Wie die konkrete Implementierung aussieht, ist von der Migration abhängig. Aber am Beispiel „JavaScript zu TypeScript“ lässt sich das Prinzip gut erkennen.
Integration in den Entwicklungsprozess
Es ist bereits hilfreich, ein Skript zu haben, das einem auf Abruf den Migrationsfortschritt ausgibt. Allerdings hilft das nicht bei dem Problem, dass Migrationen mit der Zeit einschlafen. Dafür brauchen wir etwas anderes: Sichtbarkeit. Wir müssen das Problem für alle Entwickler:innen sichtbar machen und sie dafür belohnen, die Migration voranzutreiben.
Und dafür nutze ich Pull Requests. Immer wenn jemand aus unserem Team einen Pull Request öffnet, machen wir Folgendes:
- Target Branch („main“) auschecken
- Mit dem Skript den Migrationsfortschritt berechnen und speichern
- PR Branch auschecken
- Mit dem Skript den Migrationsfortschritt berechnen und wiederum speichern
- Die Ergebnisse vergleichen und direkt im Pull Request als Kommentar veröffentlichen
Der Bericht selbst ist recht kurz, vermittelt dem Teammitglied aber ein Belohnungsgefühl für die getane Fleißarbeit (Gamification).
Migration im Prozess
Fazit
Es ergeben sich mehrere Vorzüge aus dieser Vorgehensweise
- Entwickler:innen werden laufend daran erinnert, die Migrationen voranzutreiben
- Die Gamification mit Fortschrittsbalken hilft, die Motivation zu steigern
- Neue Teammitglieder sehen sofort, welche Migrationen aktuell laufen
- Fügt jemand Code hinzu, der nicht den aktuellen Coding Guidelines entspricht, sinkt der Migrationsfortschritt – und weist so auf den Fehler hin
Funktioniert der Ansatz für alle Teams gleichermaßen? Wahrscheinlich nicht.
Teams mit hoher Fluktuation oder großem Druck, permanent neue Features zu liefern, werden unter Umständen Schwierigkeiten haben, die Zeit für den Zusatzaufwand zu finden.
Für manche Teams oder Migrationen ist es besser, die Migration fokussiert in einem Zug durchzuziehen.
Aber: Es ist ein weiteres Tool im Werkzeugkasten erfolgreicher Teams – und wenn es im richtigen Moment eingesetzt wird, kann es sehr wirkungsvoll sein
