Erklär mir, wie du ein Feature zuschneiden und ausliefern würdest, das Datenbank, API und UI berührt.

Schneide es vertikal und liefer in Stufen, statt drei Schichten parallel zu bauen. Fang beim Datenmodell und einer additiven Migration an, dann die API mit Contract-Tests, dann die UI hinter einem Feature Flag. Bring früh einen schmalen Fall end to end zum Laufen, denn genau dort kommen falsche Annahmen günstig ans Licht. Halt Pull Requests klein genug, dass jemand sie in einem Rutsch ordentlich reviewen kann.

Bevor ich irgendetwas schreibe, will ich die kleinste Version, die wirklich nützlich ist, weil die Hälfte des Spezifizierten im ersten Release nicht gebraucht wird. Dann mache ich eine dünne vertikale Scheibe: ein Feld, ein Endpoint, ein Screen, in ein bis zwei Tagen end to end funktionierend. Genau dort merkst du, dass das Datenmodell falsch ist, und das an Tag zwei zu merken kostet nichts im Vergleich zu Tag neun. Migrationen kommen zuerst und sind immer additiv, damit sie vor dem Code ausgeliefert werden können, der sie nutzt. Baut jemand anderes die UI, einigen wir uns früh auf den API-Vertrag, und die Person arbeitet gegen einen Mock oder ein typisiertes Schema, damit niemand auf mich warten muss. Bei Pull Requests ziele ich auf Änderungen, die eine Reviewerin im Kopf behalten kann: Migration und Model in einem, Endpoint und Tests in einem zweiten, UI in einem dritten, alle hinter ein Flag gemergt, das aus ist. Dann schalten wir intern ein, dann für einen kleinen Prozentsatz. So dunkel auszuliefern hat mich mehr als einmal gerettet, wenn die Last schlimmer war als erwartet.