Eine geerbte Laravel-Codebasis richtig lesen

Jemand ist gegangen, oder ein Unternehmen wurde übernommen, oder eine Agenturbeziehung ist zu Ende. Es gibt ein Repository, Produktionszugang und eine Frage danach, wie lange etwas dauern wird.

Der Impuls ist, die Controller zu öffnen und zu lesen. Es ist der langsamste Weg zum Verständnis, denn ein Controller sagt Ihnen, was ein Bildschirm tut, und nichts darüber, was das System ist.

Hier ist die Reihenfolge, die funktioniert.

1. Das Schema, vor jedem PHP

Die Datenbank ist das ehrlichste Dokument im Repository. Code lässt sich nach Laune umbauen; das Schema ist, was das Unternehmen tatsächlich tut, und seine unbequemen Stellen sind dort, wo die Anforderungen unbequem waren.

Lesen Sie die Migrationen der Reihe nach, oder ziehen Sie die aktuelle Struktur und lesen Sie die. Suchen Sie die Tabellen, auf die die meisten Fremdschlüssel zeigen – das ist der Kern der Fachlichkeit. Suchen Sie die, die niemand referenziert; das sind meist aufgegebene Funktionen. Suchen Sie vier Spalten, die alle einen Status zu halten scheinen, denn das ist eine Entscheidung, die dreimal von drei Leuten getroffen wurde.

Am Ende können Sie meist die fünf Substantive benennen, um die es dem Unternehmen geht – mehr, als in den meisten Übergabedokumenten steht.

2. Die Jobs, denn dort sitzt das Risiko

Controller machen die sichtbare Arbeit. Jobs machen die Arbeit, die Geld kostet, wenn sie schiefgeht – Karten belasten, Rechnungen ausstellen, Dinge an andere Systeme schicken, Daten exportieren.

Lesen Sie jede Job-Klasse. Fragen Sie bei jeder, was passiert, wenn sie zweimal läuft, denn irgendwann wird jede das tun. Sehen Sie dann in der Produktion in die Tabelle der fehlgeschlagenen Jobs und finden Sie heraus, welche bereits scheitern, wie oft, und ob irgendjemand hinsieht.

Die failed_jobs-Tabelle einer Anwendung ist eine Zusammenfassung ihrer ungelösten Probleme, und sie ist fast immer der erste Ort, an den niemand geschaut hat.

3. Das Deployment, denn es sagt Ihnen, was Sie ändern dürfen

Finden Sie heraus, wie Code in die Produktion kommt. Eine Pipeline, ein Skript, oder jemand mit SSH-Zugang und einer Gewohnheit.

Sie suchen konkrete Antworten: Laufen Migrationen automatisch, werden Queue-Worker neu gestartet, gibt es einen Rückweg, und hat ihn je jemand benutzt. Die Antworten entscheiden, wie mutig Ihre erste Änderung sein darf.

Ist das Deployment eine Person, die Schritte aus dem Gedächtnis abarbeitet, ist das unabhängig davon, wofür Sie geholt wurden, das Erste zu beheben. Alles andere hängt daran, sicher ausliefern zu können.

4. Composer, für die Abhängigkeiten, die gegangen sind

composer outdated --direct

Sie suchen zwei Dinge. Pakete, die mehrere Hauptversionen zurückliegen und einschränken, was Sie tun können. Und Pakete, die aufgegeben wurden – eine Entscheidung im Wartezustand, keine Versionsnummer.

Prüfen Sie, welches Laravel und welches PHP die Anwendung fährt und ob eines davon noch Sicherheitsfixes bekommt. Diese eine Tatsache ordnet jeden Plan neu.

5. Die Produktion, für das, was tatsächlich passiert

Nicht den Code – das Verhalten. Welche Endpunkte langsam sind, welche Fehler sich wiederholen, wie tief die Queue in ihrer schlimmsten Stunde wird, und wie groß die größten Tabellen sind.

Gibt es kein Monitoring, ist dessen Einrichtung Ihre erste Woche. Eine Anwendung, die niemand beobachten kann, ist eine, in der jede Schätzung ein Ratespiel und jeder Vorfall eine Überraschung ist.

6. Die Git-Historie, zuletzt und nützlich

Jetzt, wo Sie die Form der Dinge kennen, sagt Ihnen die Historie das Warum. Welche Teile ständig umgeschrieben werden – dort sind die Anforderungen instabil. Welche seit drei Jahren nicht angefasst wurden – entweder stabil oder furchteinflößend. Wer was geschrieben hat und ob diese Person noch da ist.

Commit-Nachrichten aus der Woche vor einem Launch sind die aufschlussreichste Dokumentation in den meisten Repositories, und niemand liest sie.

Was man in den ersten zwei Wochen nicht tut

Nichts umformatieren. Ein Whitespace-Commit zerstört die Blame-Historie, die Sie gleich brauchen werden.

Nichts beheben, was falsch aussieht. An Tag vier sieht ungewohnter Code nach einem Fehler aus. An Tag zwanzig stellt sich die Hälfte davon als Regel heraus, die jemand auf die harte Tour gelernt hat.

Keine Zahl nennen, bevor Sie fertig sind. Die Schätzung, die an Tag eins alle wollen, ist die, die Ihnen im dritten Monat vorgehalten wird.

Was dabei entsteht, ist ein Dokument: was die Anwendung tut, was brüchig ist, was aus dem Support gefallen ist, und was um drei Uhr morgens passieren würde. Dasselbe liefert unser Audit, und ob Sie es selbst machen oder wir – es ist das, woran jede Entscheidung danach hängt.