24 lines
1010 B
Markdown
24 lines
1010 B
Markdown
 
|
# DD-002 — Sviluppo document-first
|
|||
|
|
|
|||
|
|
**Data:** agosto 2026
|
|||
|
|
**Stato:** Accettata
|
|||
|
|
|
|||
|
|
**Contesto**
|
|||
|
|
Con più persone (e assistenti AI) che lavorano sul codice, serviva un modo per evitare funzionalità “inventate” al volo e incoerenze tra moduli.
|
|||
|
|
|
|||
|
|
**Decisione**
|
|||
|
|
Ogni nuova funzionalità significativa viene prima **progettata e documentata** in `docs/modules/`, poi implementata. Il flusso ufficiale è: idea → progettazione → documentazione → database → codice → test → release.
|
|||
|
|
|
|||
|
|
**Alternative scartate**
|
|||
|
|
|
|||
|
|
- Documentare solo a posteriori → troppo spesso incompleto o assente.
|
|||
|
|
- Affidarsi solo al codice come documentazione → illeggibile per chi non programma.
|
|||
|
|
|
|||
|
|
**Conseguenze**
|
|||
|
|
|
|||
|
|
- Rallenta leggermente l’avvio di nuove feature, ma riduce rework e discussioni infinite.
|
|||
|
|
- I moduli preesistenti vanno retro-documentati quando possibile.
|
|||
|
|
- Nessuna feature non documentata entra in produzione.
|
|||
|
|
|
|||
|
|
**Riesame**
|
|||
|
|
Se il team diventa molto piccolo e la documentazione smette di essere consultata.
|