Laravel-Entwicklung für Berliner Teams

Eine Berliner Produktfirma hat meist Entwickler, bevor sie ein Backend-Problem hat, und diese Reihenfolge entscheidet, wie eine Zusammenarbeit hier aussieht. Niemand kauft hier ein Lastenheft, das mitgenommen und nach drei Monaten zurückgebracht wird, weil es bereits ein Team gibt, das mit dem Ergebnis leben müsste.

Was stattdessen ankommt, ist ein benanntes Problem - ein Queue, das Jobs verliert, ein Schema, das das Geschäft nicht mehr beschreibt, eine Autorisierungsregel, die nur im Controller hält - und die Bitte, es in dem Repository zu reparieren, in dem es lebt.

Sieben Stunden Überschneidung mit Berlin

Berlin liegt eine Stunde hinter Ankara. Es gibt keinen Teil Ihres Arbeitstags, in dem wir nicht erreichbar sind, und das zählt vor allem für die Arbeit, die sich wirklich nicht asynchron machen lässt.

Eine Migration gegen eine Tabelle mit vierzig Millionen Zeilen wird in einem Call abgestimmt und von beiden Seiten beobachtet. Ein Worker, der sich nach einem Deploy anders verhält, wird diagnostiziert, während jemand, der weiß, was die Daten bedeuten, noch am Platz sitzt. Bei sechs bis acht Stunden Unterschied wird aus jedem dieser Fälle ein Vorgang für den nächsten Tag, und ein Backend-Fehler, der einen Tag wartet, kostet meist mehr als seine Behebung.

Was in Berlin üblicherweise zu reparieren ist

Die Lücken, die in Berliner Codebasen wiederkehren, lassen sich benennen.

Am häufigsten das Queue. Jobs, die nicht gefahrlos zweimal laufen können, in einem System, das von Haus aus wiederholt - was heißt, dass irgendwo bereits eine doppelte Mail, eine doppelte Belastung oder ein doppelt zugestellter Webhook liegt, den niemand zurückverfolgt hat.

Dann das Schema, das das Geschäft von vor zwei Pivots beschreibt. Spalten, in die niemand mehr schreibt, ein Status-Enum, dessen Werte je nach Entstehungsjahr der Zeile Unterschiedliches bedeuten, und eine JSON-Spalte, die zu dem Ort wurde, an den neue Felder wandern, weil eine Migration schwer wirkte. Jede Ergänzung war vernünftig; die Summe ist ein Modell, über das niemand mehr nachdenken kann.

Drittens Autorisierung in Controllern statt an den Daten. Das trägt, bis etwas die Datensätze auf einem anderen Weg erreicht - ein Export, ein geplanter Report, ein internes Werkzeug -, und genau diese Wege lecken. Autorisierung ist nicht Authentifizierung, und der Unterschied zeigt sich beim ersten direkten Aufruf.

Datenschutz ist eine Laravel-Schema-Entscheidung

Die deutschen Pflichten, die ein Backend betreffen, stehen nicht in der Datenschutzerklärung.

Löschen muss löschen. Eine deleted_at-Spalte ist ein Filter, und die Zeile bleibt für alles lesbar, was den Scope vergisst. Sie ist zudem selten die einzige Kopie - dieselben Daten liegen im Suchindex, in einem Analytics-Export, im Backup von gestern Nacht und in einer CSV, die jemand für ein Meeting erzeugt hat.

Auskunft muss zusammentragbar sein. Alles zu einer Person auszugeben setzt voraus zu wissen, wo alles liegt, und das ist eine Frage ans Datenmodell, nicht ans Formular.

Und Einwilligung ist ein Datensatz mit Version und Zeitstempel, kein Boolean. Gefragt wird später nie „hat zugestimmt", sondern „wozu, wann und unter welcher Fassung".

Keines davon ist am Anfang schwierig. Alles davon ist teuer, wenn drei Jahre Zeilen daliegen.

In Berlin hat der Betriebsrat ein Wort dazu, was das System erfasst

Ein internes Werkzeug, das in die Arbeit der Beschäftigten eingreift, ist in Deutschland keine rein technische Entscheidung. Wo ein Betriebsrat besteht, unterliegt ein System, das Leistung oder Verhalten überwachen kann, der Mitbestimmung, und das ist keine Formalität, die man nach dem Launch klärt.

Praktisch heißt das - was die Anwendung über ihre eigenen Nutzer festhält, wird zu einer ausdrücklichen Entwurfsfrage statt zu einem Nebeneffekt. Ein Zeitstempel auf jeder Aktion, ein Protokoll darüber, wer welche Maske aufgerufen hat, ein Dashboard mit Durchsatz pro Person - all das kann völlig vernünftig sein, und all das muss begründet, begrenzt und abgestimmt werden, statt gebaut zu werden, weil es einfach war.

Im Schema sieht das so aus - engere Protokollierung mit genanntem Zweck und Aufbewahrungsfrist, Aggregate dort, wo keine Zuordnung zu Einzelpersonen nötig ist, und die Möglichkeit, eine bestimmte Erfassung abzuschalten, ohne die Anwendung aufzureißen. Ein System, das davon ausgeht, dass alles für immer protokolliert wird, lässt sich nicht anpassen, wenn die Vereinbarung etwas anderes sagt. Eines, in dem jede Erfassung eine bewusste, einzeln abschaltbare Entscheidung ist, schon.

Früh zu reden ist billiger, und das ist der Teil, den man einem Projektsponsor klar sagen sollte. Eine Funktion, die gebaut, vorgeführt und dann wegen des Widerspruchs des Betriebsrats zurückgenommen wird, kostet den Bau zweimal. Dasselbe Gespräch, geführt solange die Funktion ein Absatz ist, kostet nichts.

Eine Berliner Anwendung, die allmählich langsam wurde

Nichts ist kaputt. Die Anwendung ist einfach langsamer als vor achtzehn Monaten, und niemand kann auf die Änderung zeigen, die dafür verantwortlich ist - weil es keine Änderung gab, sondern Wachstum.

Die Diagnose hat eine Reihenfolge, und sie zu überspringen kostet Wochen. Erst messen, in Produktion, mit Laufzeiten pro Query und einem Blick darauf, wofür die langsamsten Requests ihre Zeit tatsächlich verbrauchen. Die Intuition darüber, welche Seite langsam ist, trifft in etwa der Hälfte der Fälle zu, und die Ursache liegt fast nie dort, wo das Team sie erwartet hat.

Was es in einer Laravel-Anwendung dieses Alters meistens ist - eine Listenansicht, die eine Query pro Zeile abschickt. Bei tausend Zeilen unsichtbar, bei vierhunderttausend tödlich, und erzeugt genau von der Bequemlichkeit, die Eloquent angenehm macht. Eager Loading behebt das an einem Nachmittag, sobald man es gefunden hat, und verlässlich findet man es mit einem Werkzeug, das das Muster in den Tests meldet, nicht damit, dass ein Entwickler es bemerkt.

Zweithäufigster Fall ist ein Index, der nie angelegt wurde, weil die Query auf dem Datenbestand der Entwicklungsmaschine schnell war. Dritthäufigster ist eine Count-Query auf einer Tabelle, die über den Punkt hinausgewachsen ist, an dem Zählen billig ist, ausgeführt bei jedem Seitenaufruf für eine Paginierung, die niemand benutzt.

Nichts davon ist ein Rewrite, und der Reflex, allmähliche Langsamkeit als Beweis für eine falsche Architektur zu nehmen, ist teuer und meistens falsch. Die Messung unterscheidet beides, und sie kostet einen Tag.

Neben den Entwicklern arbeiten, die es erben

Ein Käufer mit eigenem Team schließt die Form aus, die Agenturen sonst verkaufen: ein paralleles Repository, ein paralleler Prozess und am Ende ein Übergabetermin.

Was an deren Stelle tritt, ist unspektakulär, und genau das ist der Punkt. Ihre Branch-Policy. Ihr Review-Prozess. Ihre CI. Ihre Entwickler, die unseren Pull Requests in Woche eins widersprechen, solange Widerspruch noch billig ist.

Monat eins ist so langsamer. Es ist auch die einzige Variante, in der das reparierte Queue ein Jahr später noch läuft, weil die Leute, die es pflegen, beim Bauen zugesehen haben.

Der Rahmen auf Länderebene - das E-Rechnungsformat, Hosting-Entscheidungen, was der deutsche Datenschutz von einem Dienstleister erwartet - steht auf der Länderseite Deutschland.