Senior Ruby on Rails — Ruby-on-Rails-Interviewfragen

Wie führst du eine Migration auf einer großen Tabelle ohne Downtime durch?

Geh davon aus, dass die Tabelle so lange gesperrt ist, wie das Statement läuft, und gestalte die Änderung so, dass das nicht passiert. Spalten fügst du nullable und ohne Default hinzu, den Backfill fährst du in Batches außerhalb der Migration, Indizes erstellst du concurrent, und erst danach fügst du das Constraint hinzu. Umbenennen und Löschen sind die gefährlichen Fälle, weil während des Deploys noch alter Code läuft — die erledigst du in zwei Releases mit einem Dual-Write dazwischen.

Wie zerlegst du einen zu groß gewachsenen Rails-Monolithen?

Zieh die Grenzen, bevor du irgendetwas extrahierst — meist entlang der Domänenteile, die sich gemeinsam ändern. Setze sie zuerst innerhalb derselben Codebase durch, mit Modulen oder Engines und ohne Datenbankzugriffe über die Grenze hinweg — genau dort merkst du fast kostenlos, dass die Grenze falsch gezogen war. Einen Service herauszulösen ist der letzte Schritt, nicht der erste, und lohnt sich nur, wenn ein Team oder ein Skalierungsbedarf das wirklich verlangt.

Wann lohnt sich Metaprogrammierung, und was kostet sie?

Es zahlt sich in einer kleinen Library aus, wo es viel Wiederholung eliminiert — define_method über eine Liste von Attributen ist völlig in Ordnung. Es kostet dort, wo jemand nach einem Methodennamen grept und nichts findet, oder wo ein Tippfehler zu einem stillen nil wird, weil method_missing ihn geschluckt hat. Wenn du method_missing definierst, definiere respond_to_missing? gleich mit, sonst lügt das Objekt darüber, was es kann.

Wie entscheidest du, was gecacht wird?

Cache, was teuer und stabil ist, und erst, wenn die Query schon so gut ist, wie sie überhaupt werden kann — Caching behebt kein N+1, es versteckt es nur bis zum ersten Cache-Miss. Die Invalidierung entscheidest du vor dem Caching: Ein Key, der updated_at enthält, läuft von selbst ab, während ein manueller Cleanup genau das ist, was irgendwann vergessen wird. Falsch gecachte Daten sind schlimmer als eine langsame Seite.

Wie gehst du ein großes Rails-Upgrade auf einem laufenden Produkt an?

Bring zuerst die Testsuite in einen ehrlichen Zustand, denn der Upgrade ist nur so sicher wie das, was sie dir sagen kann. Danach gehst du eine Minor-Version nach der anderen, kümmerst dich um Deprecation-Warnings, bevor sie zu Fehlern werden, und hältst die App dort, wo das Framework es zulässt, im selben Branch auf alter und neuer Version lauffähig. Unterschätzt werden meistens die Gems: Der Blocker ist in der Regel eine unmaintainte Abhängigkeit, nicht Rails selbst.