marcus hinz
1.9 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| feedback-copy-not-share-wegwerf | Bei Wegwerfcode (z.B. Migration) bewusst KOPIEREN statt geteilte Logik mit dauerhaftem Code; Flows in EINER Tier halten (Migration läuft REIN BE). |
|
Zwei zusammenhängende Regeln, beide am 2026-05-28 hart eingefordert:
-
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.
-
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.