1. Choisir le périmètre
Décider si la version 1 du logiciel lit seulement, ou lit et écrit. Décider aussi si vous supportez seulement `ENTRY`, ou `ENTRY` et `LIB`.
Démarrer vite sans rater l’essentiel
Cette page sert de rampe de lancement concrète. Elle résume ce qu’une équipe doit stabiliser dans les premiers jours : périmètre, modèle interne, lecture, écriture et tests. Elle ne remplace pas les spécifications, mais elle évite de disperser l’effort trop tôt.
Ce qu’il faut verrouiller dès le début
Avant de raffiner quoi que ce soit, il faut aligner la terminologie, les formats supportés et le comportement du writer.
2. Fixer le noyau de lecture
Tout doit converger vers un parseur texte unique, même quand l’entrée arrive en `.eevz` ou en `.eevcz` déjà émis que tu dois seulement lire. La compression est un transport, pas un second langage.
3. Écrire un modèle propre
Créer des structures nettes pour la bibliothèque, les entrées, les blocs globaux, les matrices, les modes et les `peak_tracks`. Éviter le stockage en lignes brutes aussi longtemps que possible.
MVP raisonnable
- lecture `.eev` et `.eevz`
- support `ENTRY` d’abord, `LIB` ensuite si besoin
- validation avec erreurs bloquantes et avertissements legacy
- n’utiliser le writer canonique que pour les champs réellement compris
- tests de round-trip sur des exemples réels
Version 2 utile
- support complet de `LIB`
- prise en charge de `.eevc` et `.eevcz` en lecture
- préservation plus fine des sections optionnelles
- outils de diff et de diagnostic
- compatibilité legacy plus riche
Premier sprint recommandé
Le but du premier sprint n’est pas de couvrir toute la spec. Il est de produire une chaîne fiable, explicable et testable.
Parser un `ENTRY` texte
Commencer par un cas simple. Lire l’en-tête, ouvrir `@entry`, reconnaître les blocs principaux, produire un modèle en mémoire et remonter des diagnostics lisibles.
Réémettre en ordre canonique
À partir du modèle interne, produire un texte stable et déterministe. Le but est que deux exports identiques produisent la même sortie.
Ajouter le transport compressé
Quand le texte fonctionne, ajouter la couche `.eevz`. Décompresser avant lecture, compresser après écriture. Garder le même cœur métier.
Tester sur de vrais cas
Mélanger exemples propres, cas legacy, champs manquants et captures réelles. Un parseur qui ne voit que des exemples parfaits reste fragile.
Pièges fréquents
- confondre niveau de qualité et statut documentaire
- faire décrire une entrée par le header de bibliothèque
- réémettre automatiquement tout ce qui a été toléré en lecture
- traiter le hash comme une affaire de conteneur compressé
Réflexe sain
Quand un doute apparaît, revenir à trois questions : est-ce du contrat public, de la stratégie d’implémentation, ou de la qualité de capture ? Cette séparation évite beaucoup de confusion dans le code et dans les discussions produit.
Livrable crédible de première version
Une première version crédible sait lire correctement un sous-ensemble clair du format, produire des diagnostics honnêtes, réémettre un texte déterministe et documenter explicitement ce qu’elle ne gère pas encore. Ce n’est pas une faiblesse : c’est une base saine.