1. Den Umfang wählen
Festlegen, ob Version 1 der Software nur liest oder liest und schreibt. Ebenso entscheiden, ob nur `ENTRY` oder sowohl `ENTRY` als auch `LIB` unterstützt werden.
Schnell vorankommen, ohne das Wesentliche zu verpassen
Diese Seite ist eine praktische Startrampe. Sie fasst zusammen, was ein Team in den ersten Tagen stabilisieren sollte: Umfang, internes Modell, Lesen, Schreiben und Tests. Sie ersetzt die Spezifikationen nicht, hilft aber, den Aufwand nicht zu früh zu zerstreuen.
Was zuerst festgelegt werden muss
Bevor Verfeinerungen implementiert werden, sollte sich das Team auf Terminologie, unterstützte Formate und das Verhalten des Writers einigen.
2. Den Lese-Kern festlegen
Alles sollte auf einen einzigen Textparser zulaufen, selbst wenn die Eingabe als `.eevz` oder als bereits ausgestellte `.eevcz` ankommt, die nur gelesen werden muss. Kompression ist Transport, keine zweite Sprache.
3. Ein sauberes Modell entwerfen
Klare Strukturen für Bibliothek, Einträge, globale Blöcke, Matrizen, Modi und `peak_tracks` anlegen. Das Speichern roher Zeilen so lange wie möglich vermeiden.
Sinnvolles MVP
- Lesen von `.eev` und `.eevz`
- zuerst `ENTRY`, bei Bedarf später `LIB`
- Validierung mit blockierenden Fehlern und Legacy-Warnungen
- den kanonischen Writer nur für Felder einsetzen, die die Software wirklich versteht
- Round-Trip-Tests mit realen Beispielen
Sinnvolle Version 2
- vollständige `LIB`-Unterstützung
- Leseunterstützung für `.eevc` und `.eevcz`
- feinere Erhaltung optionaler Abschnitte
- Diff- und Diagnosewerkzeuge
- reichere Legacy-Kompatibilität
Empfohlener erster Sprint
Das Ziel des ersten Sprints ist nicht, die gesamte Spezifikation abzudecken. Es geht darum, eine Kette zu erzeugen, die zuverlässig, erklärbar und testbar ist.
Ein textuelles `ENTRY` parsen
Mit dem einfachsten Fall beginnen. Header lesen, `@entry` öffnen, Hauptblöcke erkennen, ein Modell im Speicher erzeugen und lesbare Diagnosen ausgeben.
In kanonischer Reihenfolge erneut ausgeben
Aus dem internen Modell stabilen, deterministischen Text erzeugen. Ziel ist, dass zwei identische Exporte dieselbe Ausgabe liefern.
Komprimierten Transport hinzufügen
Sobald Text funktioniert, die `.eevz`-Schicht hinzufügen. Vor dem Lesen dekomprimieren, nach dem Schreiben komprimieren. Den gleichen fachlichen Kern behalten.
An realen Fällen testen
Saubere Beispiele, Legacy-Fälle, fehlende Felder und reale Aufnahmen mischen. Ein Parser, der nur perfekte Beispiele sieht, bleibt fragil.
Häufige Fallen
- Qualitätsstufe mit Dokumentstatus verwechseln
- einen Eintrag durch den Bibliotheks-Header beschreiben lassen
- alles automatisch erneut ausgeben, was beim Lesen toleriert wurde
- den Hash als Angelegenheit des komprimierten Containers behandeln
Gesunder Reflex
Wenn Zweifel auftauchen, zu drei Fragen zurückkehren: Geht es um den öffentlichen Vertrag, die Implementierungsstrategie oder die Aufnahmequalität? Diese Trennung vermeidet viel Verwirrung im Code und in Produktdiskussionen.
Glaubwürdiger Erstversions-Lieferstand
Eine glaubwürdige erste Version kann einen klar definierten Teil des Formats korrekt lesen, ehrliche Diagnosen liefern, deterministischen Text erneut ausgeben und ausdrücklich dokumentieren, was sie noch nicht beherrscht. Das ist keine Schwäche, sondern eine gesunde Basis.