Bevor du eine Rails-Codebase übernimmst, miss diese fünf Dinge

Wenn ein Team eine bestehende Rails-Anwendung übernimmt – nach einer Akquise, einem Teamwechsel oder weil der bisherige Dienstleister abgesprungen ist – läuft die erste Einschätzung fast immer gleich ab: Jemand klont das Repo, öffnet ein paar Controller, findet den Code "eigentlich ganz ordentlich" und gibt grünes Licht. Drei Monate später kommt die Rechnung.

Die erste Einschätzung ist fast nie falsch, weil der Code schlecht aussieht. Sie ist falsch, weil sie die falschen Dinge misst. Lesbarkeit ist ein schwacher Indikator für Übernahmerisiko. Diese fünf sind stärker – und lassen sich an einem Nachmittag erheben, bevor überhaupt ein Angebot geschrieben wird.

1. Versionsabstand, nicht Versionsnummer

Entscheidend ist nicht, welche Rails- oder Ruby-Version im Gemfile steht, sondern wie weit sie vom aktuellen Long-Term-Support-Pfad entfernt ist – und ob es dazwischen noch unterstützte Zwischenschritte gibt. Eine App auf Rails 5 lässt sich oft nicht direkt auf Rails 7 heben; man braucht die Zwischenversionen, und für jede davon lohnt sich die Frage, ob die verwendeten Gems dort überhaupt noch funktionieren. Ich zähle die Major-Versionen zwischen Ist-Zustand und aktuellem Support-Ende und multipliziere grob mit dem, was eine einzelne Migration in diesem Projekt bisher gekostet hat (falls es eine gab). Das ist die realistischere Zahl als "Upgrade auf Rails 7", die in jedem Angebot einfach so dasteht.

2. Testsuite-Wirksamkeit statt Coverage-Prozent

Eine Coverage von 90 % sagt nichts darüber, ob die Tests etwas prüfen, das beim Ändern des Codes tatsächlich bricht. Der schnellste Praxistest: einen zentralen Wert in einem Model-Callback vertauschen (z. B. eine Bedingung umdrehen) und schauen, wie viele Tests rot werden. Bei einer gesunden Suite sind das viele. Bei einer Suite, die nur Controller-Responses auf Status 200 prüft, bleibt es erschreckend still. Diese eine Stichprobe sagt mehr über die tatsächliche Sicherheit beim Ändern von Code als jeder Coverage-Report.

3. Zustand der Background-Jobs

Sidekiq-, Resque- oder Solid-Queue-Dashboards werden in Übernahmegesprächen fast nie gezeigt – dabei stecken dort oft die unangenehmsten Überraschungen. Wie groß ist die Dead-Letter-Queue, und seit wann wächst sie? Gibt es Jobs, die regelmäßig retryen und nie erfolgreich durchlaufen? Werden Jobs so geschrieben, dass ein zweiter, versehentlicher Lauf keinen Schaden anrichtet (Idempotenz), oder verlässt sich das System stillschweigend darauf, dass jeder Job nur genau einmal läuft? Eine tote Queue mit dreitausend fehlgeschlagenen Jobs, die niemand angeschaut hat, ist ein zuverlässigerer Indikator für den Wartungszustand eines Projekts als das gesamte restliche Repository.

4. Migrationshistorie gegen tatsächliches Schema

In jeder langlebigen Rails-App gibt es Abweichungen zwischen dem, was die Migrationsdateien erzählen, und dem, was tatsächlich in der Produktionsdatenbank liegt – manuelle Hotfixes direkt auf der DB, Migrationen, die in einer alten Rails-Version anders liefen als heute, Spalten, die nie sauber entfernt wurden. Ich vergleiche structure.sql bzw. schema.rb mit einem tatsächlichen Produktions-Dump und suche gezielt nach Divergenzen. Jede gefundene Abweichung ist ein Hinweis darauf, dass Migrationen in diesem Projekt nicht der verlässliche Weg sind, für den sie gehalten werden – und dass ein zukünftiges Schema-Update ein größeres Risiko trägt, als die Migrationshistorie suggeriert.

5. Tatsächliche Rollback-Fähigkeit

Die Frage "Könnt ihr im Ernstfall zurückrollen?" wird fast immer mit Ja beantwortet. Die bessere Frage ist: Wann wurde das zuletzt gemacht – nicht geübt, sondern unter echtem Druck? Ein Deployment-Prozess, der seit zwei Jahren nur in eine Richtung gelaufen ist, ist in der Praxis ein Prozess ohne Rollback, ganz gleich, was die Pipeline-Konfiguration behauptet. Das gilt besonders für Rails-Apps mit Datenmigrationen, die nicht trivial umkehrbar sind – dort ist der Rollback-Knopf oft nur solange vorhanden, wie er nicht gedrückt werden muss.

Was das für ein Angebot bedeutet

Keiner dieser fünf Punkte braucht Zugriff auf die komplette Codebase oder Wochen an Zeit. Zusammen ergeben sie aber ein deutlich ehrlicheres Bild als "der Code sieht ordentlich aus" – und sie lassen sich in ein konkretes Angebot übersetzen: Wie viele Rails-Major-Versionen liegen dazwischen, wie belastbar ist die Testsuite tatsächlich, wie groß ist die verdrängte Fehlerqueue, wie weit ist das Schema vom Modell entfernt, und wurde der Rollback jemals unter echtem Druck genutzt. Jede dieser fünf Antworten kostet ungefähr eine Stunde – und jede davon kann den Umfang eines Projekts um Wochen verschieben, bevor die erste Zeile Code angefasst wurde.