57 lines
2.2 KiB
Markdown
57 lines
2.2 KiB
Markdown
# ASV-Format-Validator
|
|
|
|
## Projektüberblick
|
|
- Java-/Maven-Projekt zur Validierung segmentorientierter Dateien gegen eine fachliche ASV-Spezifikation.
|
|
- Bestehenden Projektstand respektieren und darauf aufbauen.
|
|
- Keine Neuarchitektur.
|
|
|
|
## Technik
|
|
- Java 21
|
|
- Maven
|
|
- Log4j2
|
|
- kein Spring Boot
|
|
|
|
## Architektur- und Arbeitsregeln
|
|
- Nur kleine, kontrollierte Änderungen.
|
|
- Pro Arbeitsschritt genau eine kleine fachliche Regel oder eine eng abgegrenzte Stabilisierung.
|
|
- Kein Parser-Umbau ohne ausdrückliche Anweisung.
|
|
- Keine EDIFACT-Neuinterpretation auf Verdacht.
|
|
- Keine neue Validator-Hierarchie auf Verdacht.
|
|
- Keine Refactorings auf Verdacht.
|
|
- Bereits vorhandene Regeln und Tests dürfen nicht semantisch verbogen werden.
|
|
- Bestehende Funktionalität darf nicht verschlechtert werden.
|
|
|
|
## Parser-Leitplanken
|
|
- Aktuelle Parser-Annahmen respektieren.
|
|
- Keine zusätzliche Zerlegung von Feldwerten, außer ein bestehender Test und der aktuelle Projektstand erzwingen eine eng begrenzte lokale Korrektur.
|
|
- Keine allgemeine Normalisierung einführen, wenn nur ein lokaler Sonderfall benötigt wird.
|
|
|
|
## Code-Stil
|
|
- Technische Bezeichner auf Englisch.
|
|
- Kommentare, JavaDoc und benutzernahe Fehlermeldungen auf Deutsch.
|
|
- Vollständigen, kompilierbaren Code liefern.
|
|
- Änderungen minimal halten.
|
|
|
|
## Test- und Qualitätsregeln
|
|
- Nach jeder Änderung vollständig testen.
|
|
- Standardbefehl: `mvn clean test`
|
|
- Wenn Tests fehlschlagen:
|
|
- zuerst alle fehlgeschlagenen Tests gemeinsam analysieren
|
|
- gemeinsame Ursachen clustern
|
|
- dann alle zugehörigen Fehler in einem sauberen Durchgang beheben
|
|
- keine Fehler-für-Fehler-Mini-Iterationen
|
|
- Wenn neue Tests ergänzt werden:
|
|
- Testdaten fachlich isoliert halten
|
|
- keine unnötigen Zusatzfehler provozieren
|
|
|
|
## Änderungsschwerpunkte
|
|
- Bevorzugt bestehende Klassen gezielt ergänzen.
|
|
- Neue Klassen nur, wenn technisch wirklich nötig und klein.
|
|
- Für Validator-Schritte bevorzugt im bestehenden `DefaultStructureValidator` ergänzen, solange kein ausdrücklicher Architekturwechsel gefordert ist.
|
|
|
|
## Ausgabeerwartung
|
|
- Zuerst den ausgeführten Maven-Befehl nennen.
|
|
- Danach kurzes Testergebnis.
|
|
- Danach kurze Liste der geänderten Dateien.
|
|
- Danach vollständigen Code aller tatsächlich geänderten Dateien.
|
|
- Keine langen Erklärungen. |