20 lines
1.0 KiB
Markdown
20 lines
1.0 KiB
Markdown
 
|
# 0005 – Grundlegendes Refactoring erst nach grüner Baseline und festgeschriebenen Verträgen
|
|||
|
|
|
|||
|
|
Status: vorgeschlagen · Datum: 2026-09-02 · Beteiligte: AG QGIS
|
|||
|
|
|
|||
|
|
## Kontext
|
|||
|
|
Der Code ist gewachsen (zehn Dateien über 600 Zeilen, implizite Verträge, rote Tests). Ein Umbau jetzt würde Wissen
|
|||
|
|
zerstören, das nur im Code steht, und wäre nicht durch Tests abgesichert.
|
|||
|
|
|
|||
|
|
## Entscheidung
|
|||
|
|
Reihenfolge: (1) Workspace und Wissensbasis, (2) Tests mit Baseline und CI, Rot→Grün, (3) Verträge festschreiben
|
|||
|
|
(Abhängigkeiten, Variablen, Linkliste, Manifest), (4) Refactoring-Konzept mit Zielarchitektur und Scheiben,
|
|||
|
|
erst dann (5) Umbau. Bis dahin gilt „kein Refactoring nebenbei“; strukturelle Änderungen brauchen ein Issue.
|
|||
|
|
|
|||
|
|
## Folgen
|
|||
|
|
Fachliche Weiterentwicklung bleibt möglich. Die Fachschale-Idee des Alternativansatzes wird im Refactoring-Konzept
|
|||
|
|
bewertet, nicht vorher eingebaut.
|
|||
|
|
|
|||
|
|
## Verworfene Alternativen
|
|||
|
|
Sofortiges Refactoring (Risiko); Neuentwicklung auf Basis des Alternativansatzes (verwirft 29 500 Zeilen Fachlogik).
|