1. De scope kiezen
Bepaal of versie 1 van de software alleen leest of zowel leest als schrijft. Bepaal ook of alleen `ENTRY` of zowel `ENTRY` als `LIB` wordt ondersteund.
Snel vooruitgaan zonder het essentiële te missen
Deze pagina is een praktische lanceerbasis. Ze vat samen wat een team in de eerste dagen moet stabiliseren: scope, intern model, lezen, schrijven en tests. Ze vervangt de specificaties niet, maar helpt te voorkomen dat de inspanning te vroeg alle kanten opgaat.
Wat eerst moet worden vastgelegd
Voordat verfijningen worden gecodeerd, moet het team het eens zijn over terminologie, ondersteunde formaten en het gedrag van de writer.
2. De leeskern vastleggen
Alles moet samenkomen in één tekstparser, zelfs wanneer de invoer als `.eevz` of als een reeds uitgegeven `.eevcz` binnenkomt die alleen gelezen hoeft te worden. Compressie is transport, geen tweede taal.
3. Een schoon model ontwerpen
Maak duidelijke structuren voor de bibliotheek, items, globale blokken, matrices, modi en `peak_tracks`. Vermijd het zo lang mogelijk om ruwe regels op te slaan.
Redelijk MVP
- lezen van `.eev` en `.eevz`
- eerst `ENTRY` ondersteunen, daarna `LIB` indien nodig
- validatie met blokkerende fouten en legacy-waarschuwingen
- de canonieke writer alleen gebruiken voor velden die de software echt begrijpt
- round-trip-tests op echte voorbeelden
Nuttige versie 2
- volledige `LIB`-ondersteuning
- leessupport voor `.eevc` en `.eevcz`
- fijnere bewaring van optionele secties
- diff- en diagnosetools
- rijkere legacy-compatibiliteit
Aanbevolen eerste sprint
Het doel van de eerste sprint is niet om de volledige specificatie te dekken. Het is om een keten te produceren die betrouwbaar, uitlegbaar en testbaar is.
Eén tekstueel `ENTRY` parsen
Begin met het eenvoudigste geval. Lees de header, open `@entry`, herken de hoofdblokken, produceer een model in het geheugen en geef leesbare diagnoses terug.
Opnieuw uitgeven in canonieke volgorde
Produceer vanuit het interne model stabiele, deterministische tekst. Het doel is dat twee identieke exports dezelfde uitvoer opleveren.
Gecomprimeerd transport toevoegen
Voeg de `.eevz`-laag toe zodra tekst werkt. Decomprimeer vóór het lezen en comprimeer na het schrijven. Houd dezelfde business core aan.
Testen op echte gevallen
Combineer schone voorbeelden, legacy-gevallen, ontbrekende velden en echte opnames. Een parser die alleen perfecte voorbeelden ziet, blijft fragiel.
Veelvoorkomende valkuilen
- kwaliteitsniveau verwarren met documentstatus
- één entry laten beschrijven door de bibliotheekheader
- alles automatisch opnieuw uitgeven wat bij het lezen is getolereerd
- de hash behandelen alsof die alleen bij de gecomprimeerde container hoort
Gezonde reflex
Wanneer twijfel ontstaat, keer dan terug naar drie vragen: gaat het om het publieke contract, de implementatiestrategie of de opnamekwaliteit? Die scheiding voorkomt veel verwarring in code en productdiscussies.
Geloofwaardige oplevering van een eerste versie
Een geloofwaardige eerste versie kan een duidelijk afgebakende subset van het formaat correct lezen, eerlijke diagnoses geven, deterministische tekst opnieuw uitgeven en expliciet documenteren wat ze nog niet ondersteunt. Dat is geen zwakte: het is een gezonde basis.