Eine Next.js-Codebasis übernehmen, die niemand anfassen will

Ein Team erbt eine Anwendung. Die Leute, die sie geschrieben haben, sind weg. Jedes Deployment ist ein kleines Ereignis, niemand ist sicher, welche Teile tragend sind, und innerhalb eines Monats fällt in einer Besprechung das Wort "Rewrite".

Manchmal ist ein Rewrite richtig. Er ist weit seltener richtig, als er vorgeschlagen wird, und die Entscheidung fällt fast immer, bevor irgendjemand die Informationen hat, um sie zu treffen.

Zwei Wochen lesen, bevor eine Zeile geschrieben wird

Die Orientierung, die wir auf einer geerbten Codebasis fahren, ist festgelegt: lesen, kartieren, dokumentieren - und nichts ändern. Zwei Wochen, und das Ergebnis ist ein Dokument, kein Pull Request.

Was hineingehört:

Die Routenkarte. Jede Route, ihr Rendering-Modus, welche Daten sie liest und welche sie schreibt. Im App Router ist das weitgehend aus der Build-Ausgabe und den page.tsx-Dateien rekonstruierbar; in einer Pages-Router-Anwendung heißt es, getServerSideProps-Rümpfe zu lesen. Es ist stumpfe Arbeit und das mit Abstand wertvollste Artefakt, denn "was tut diese Anwendung eigentlich" stellt sich als Frage heraus, die niemand beantworten kann.

Die Datengrenze. Welche Aufrufe gehen an welchen Dienst, welche davon sind authentifiziert, welche gecacht. Achten Sie auf den, den niemand dokumentiert hat: eine interne API, die aus einer Client-Komponente mit einem Schlüssel in NEXT_PUBLIC_ aufgerufen wird.

Der Deployment-Pfad. Was baut es, welche Tests laufen, welche Umgebungsvariablen es gibt und was passiert, wenn es fehlschlägt. Lautet die Antwort "Ali weiß das" und Ali ist gegangen, ist das der wichtigste Punkt im ganzen Dokument.

Der Wirkungsradius jedes Bereichs. Welche Dateien werden von allem importiert und welche von einer Route. Eine gemeinsame utils.ts mit vierzig Exporten und hundert Importeuren sagt Ihnen, wo aus einer kleinen Änderung eine große wird.

Was eine Codebasis wirklich schwer änderbar macht

Nach vielen solchen Audits sind die Eigenschaften, die mit Angst korrelieren, eng und immer dieselben.

• Keine Typen an den Grenzen. Nicht "kein TypeScript" - die meisten dieser Projekte haben TypeScript. Es ist any an jedem Fetch, sodass der Compiler das Innere der Anwendung gegen Annahmen prüft, die am Rand niemand kontrolliert hat.
• Zustand an mehr als einer Stelle. Ein Server-Cache, ein Client-Store und URL-Parameter, die alle denselben Wert zu halten behaupten, ohne Regel darüber, wer gewinnt.
• Seiteneffekte im Render. useEffect-Ketten, die holen, dann Zustand setzen, dann den nächsten Effekt auslösen. Das sind die Änderungen, die drei Bildschirme weiter etwas kaputt machen.
• Keine Naht zwischen Framework und Domäne. Geschäftsregeln, die inline in Route Handlern stehen, lassen sich ohne Request nicht testen - also werden sie nicht getestet.

Beachten Sie, was nicht auf der Liste steht: alte Abhängigkeiten, eine unmoderne Ordnerstruktur, Klassenkomponenten, CSS, das jemandem missfällt. Das ist sichtbar und billig zu ändern. Es ist nicht das, was Deployments beängstigend macht, und ein damit begründeter Rewrite kauft ein Jahr Risiko für eine ästhetische Verbesserung.

Erst sicher machen, dann gut machen

Die Reihenfolge zählt, und es ist nicht die befriedigende.

1. Das Deployment reproduzierbar machen. Solange Sie nicht jederzeit deployen und jederzeit zurückrollen können, ist jede Verbesserung ein Glücksspiel.
2. Die Grenzen typisieren. Externe Daten am Rand parsen - mit zod oder Ähnlichem -, damit falsche Daten beim Fetch mit einer nützlichen Meldung scheitern, statt drei Komponenten später als undefined is not a function.
3. Tests dort, wo das Geld ist. Nicht Coverage. Der Checkout, der Auth-Flow, die eine Berechnung, von der das Geschäft abhängt.
4. Dann umbauen, Bereich für Bereich, hinter diesen Tests.

Der größte Teil der Angst ist nach Schritt zwei weg, und Schritt zwei ist meist eine Woche Arbeit an einer Codebasis, die man als unrettbar beschrieben hat.

Wann ein Rewrite wirklich die Antwort ist

Es gibt diese Fälle. Nach unserer Erfahrung lohnt er sich, wenn das Framework selbst das Problem ist - eine Anwendung auf einem aufgegebenen Meta-Framework, oder eine, deren Rendering-Modell die nötigen Seiten nicht erzeugen kann. Er lohnt sich auch, wenn die Anwendung klein genug ist, dass ein Rewrite in Wochen gemessen wird; dann spielt das Argument kaum eine Rolle.

Er lohnt sich nicht, weil der Code hässlich ist, weil er auf einer älteren Hauptversion läuft oder weil das jetzige Team ihn nicht geschrieben hat. Das sind die drei Gründe, aus denen er üblicherweise vorgeschlagen wird.

Und wenn das eigentliche Problem ist, dass die Anwendung auf dem Pages Router läuft und der Weg nach vorn unklar ist, dann ist auch das kein Rewrite, sondern vom Pages Router zum App Router ohne Feature-Stopp

• eine andere und weit billigere Arbeit.

Was Sie der nächsten Person schulden

Wie auch immer Sie entscheiden: Lassen Sie das Dokument da. Die Codebasis war beängstigend, weil das Verständnis des letzten Teams mit ihm gegangen ist, und die einzige dauerhafte Lösung dafür ist, es dort aufzuschreiben, wo der Code daneben gelesen werden kann.

Wir übergeben diese Karte, ob der Kunde mit uns weitermacht oder nicht. Es ist der Teil des Auftrags mit der längsten Lebensdauer.