marcus hinz
19 lines
1.9 KiB
Markdown
19 lines
1.9 KiB
Markdown
---
|
|
name: feedback-copy-not-share-wegwerf
|
|
description: Bei Wegwerfcode (z.B. Migration) bewusst KOPIEREN statt geteilte Logik mit dauerhaftem Code; Flows in EINER Tier halten (Migration läuft REIN BE).
|
|
metadata:
|
|
node_type: memory
|
|
type: feedback
|
|
originSessionId: da22c6d7-9f9f-4834-b8f6-bdd06d220c38
|
|
---
|
|
|
|
Zwei zusammenhängende Regeln, beide am 2026-05-28 hart eingefordert:
|
|
|
|
1. **Wegwerfcode kopiert benötigte Logik, statt sie zu teilen.** Wenn ein Teil temporär/Wegwerf ist (z.B. die SQLite/Excel-**Migration**) und einen Teil aus dem dauerhaften Code braucht (z.B. den SAP-Adapter), dann **kopieren** — keine gemeinsame Funktion/Abstraktion zwischen Wegwerf- und Bleibe-Code.
|
|
|
|
2. **Flows nicht über Tiers springen lassen.** Die Migration läuft **komplett im BE**: parsen → SAP-Abfrage → anreichern → speichern in EINEM BE-Durchlauf. Daten im Flow NICHT BE→FE→BE schaufeln.
|
|
|
|
**Why:** Beim SAP-Einbau in die Migration. Marcus wörtlich: „bitte KOPIEREN — KEINE GEMEINSAME LOGIK (das eine ist wegwerfCode, das andere brauchen wir)". Und massiver Ärger, als ich vorschlug, im Migrationsflow BE→FE→BE zu round-trippen: „Dein Schritt 1 ist ein ABSOLUTES NO GO". Davor ebenfalls Ärger, weil ich eine geteilte Offline-first-Methode (`createOrUpdate`) angefasst hatte, obwohl die Änderung NUR den Migrate-Schritt betreffen durfte.
|
|
|
|
**How to apply:** Bei Migrations-/Wegwerf-Aufgaben Logik **duplizieren** statt teilen. Den Offline-first-Pfad (`persistentStorage.createOrUpdate/createOrUpdateList`, Outbox, Reconciler, BE `CommandService`/`CustomerCoreService.createOrUpdate(List)`) **nie** für Migrationszwecke anfassen — dafür gibt es separate Migrations-Pfade (`batchImport`, `replaceLocal`). Flows in einer Schicht halten. Und: ein Fall nach dem anderen, kurze lesbare Antworten — er sagte „NEIN das ist mir zu unstrukturiert" und „ich kann's nicht lesen". Siehe [[feedback-klein-und-pragmatisch]].
|