1. Scegliere il perimetro
Decidere se la versione 1 del software sarà solo in lettura oppure in lettura e scrittura. Decidere anche se supportare solo `ENTRY` oppure `ENTRY` e `LIB`.
Procedere rapidamente senza perdere l’essenziale
Questa pagina funge da rampa di lancio pratica. Riassume ciò che un team deve stabilizzare nei primi giorni: perimetro, modello interno, lettura, scrittura e test. Non sostituisce le specifiche, ma aiuta a non disperdere troppo presto gli sforzi.
Che cosa fissare subito
Prima di sviluppare i raffinamenti, il team deve allinearsi su terminologia, formati supportati e comportamento del writer.
2. Fissare il nucleo di lettura
Tutto deve convergere verso un unico parser testuale, anche quando l’ingresso arriva come `.eevz` o come un `.eevcz` già emesso che va solo letto. La compressione è trasporto, non un secondo linguaggio.
3. Progettare un modello pulito
Creare strutture chiare per libreria, voci, blocchi globali, matrici, modi e `peak_tracks`. Evitare il più a lungo possibile di memorizzare righe grezze.
MVP ragionevole
- lettura di `.eev` e `.eevz`
- supportare prima `ENTRY`, poi `LIB` se necessario
- validazione con errori bloccanti e avvisi legacy
- usare il writer canonico solo per i campi che il software comprende davvero
- test di round-trip su esempi reali
Versione 2 utile
- supporto completo di `LIB`
- supporto in lettura per `.eevc` e `.eevcz`
- preservazione più fine delle sezioni opzionali
- strumenti di diff e diagnostica
- compatibilità legacy più ricca
Primo sprint consigliato
L’obiettivo del primo sprint non è coprire tutta la specifica. È produrre una catena affidabile, spiegabile e testabile.
Fare il parsing di un `ENTRY` testuale
Iniziare dal caso più semplice. Leggere l’header, aprire `@entry`, riconoscere i blocchi principali, produrre un modello in memoria e restituire diagnostica leggibile.
Riemettere in ordine canonico
A partire dal modello interno, produrre un testo stabile e deterministico. L’obiettivo è che due esportazioni identiche generino la stessa uscita.
Aggiungere il trasporto compresso
Quando il testo funziona, aggiungere il livello `.eevz`. Decomprimere prima della lettura, comprimere dopo la scrittura. Mantenere lo stesso nucleo applicativo.
Testare su casi reali
Mescolare esempi puliti, casi legacy, campi mancanti e acquisizioni reali. Un parser che vede solo esempi perfetti resta fragile.
Trappole frequenti
- confondere livello di qualità e stato documentale
- lasciare che l’header di libreria descriva una singola entry
- riemettere automaticamente tutto ciò che è stato tollerato in lettura
- trattare l’hash come una questione del contenitore compresso
Riflesso sano
Quando emerge un dubbio, tornare a tre domande: si tratta del contratto pubblico, della strategia di implementazione o della qualità della cattura? Questa separazione evita molta confusione nel codice e nelle discussioni di prodotto.
Consegna credibile di prima versione
Una prima versione credibile sa leggere correttamente un sottoinsieme chiaro del formato, produrre diagnostica onesta, riemettere un testo deterministico e documentare esplicitamente ciò che ancora non gestisce. Non è una debolezza: è una base sana.