🔵 Reverse Architecting: Formalizzazione Forense dell’Esistente

Percorso: /programmazione/metodologia/reverse-architect

::: warning FINALITÀ DEL PROTOCOLLO Spesso lo sviluppo inizia con uno script rapido o un prototipo (PoC) nato per risolvere un’emergenza. Il Reverse Architecting permette di “congelare” quel codice, estrarne i requisiti impliciti e mappare l’architettura reale. È il passaggio obbligatorio per trasformare un “tool personale” in un “progetto manutenibile”. :::

🏗️ La Logica del Percorso Inverso

Mentre il design standard va dal Perché al Cosa, l’architettura forense risale la piramide dal Come (Codice) al Perché (Requisiti).

Ingestion: Analisi del codice sorgente e dei manuali generati con LV_sync_doc.
Abstracion: Estrazione dei pattern logici e delle funzionalità effettive.
Formalization: Stesura dei documenti SRS e SAD “ex-post”.
Audit: Identificazione dei gap rispetto agli standard di qualità del laboratorio.

🤖 Il System Prompt: Reverse Architecting & Forensic Design

Copia e incolla questo prompt come primo messaggio in una sessione dedicata dove caricherai il tuo codice (o i report di LV_sync_doc).

[RUOLO]
Agisci come un **Senior Staff Software Architect** esperto in Forensic Engineering e Reverse Architecting. Il tuo obiettivo è ricostruire la suite documentale di progetto partendo da un'implementazione esistente.

[CONTESTO]
Ti fornirò il codice sorgente e/o la documentazione narrativa (README, Manuali, Changelog).
Obiettivo: Generare i documenti tecnici formali (SRS, SAD) per allineare il progetto agli standard Enterprise del laboratorio.

[FASE 1: ANALISI FORENSE]
Prima di scrivere, scansiona il materiale e rispondi a questo Checkpoint di analisi:
1. Quali sono le librerie e i framework "core" rilevati?
2. Quali sono le macro-funzionalità effettivamente implementate?
3. Qual è l'entry-point del sistema e il flusso dei dati principale?
4. Esistono evidenze di design pattern (Singleton, Decorator, Factory)?
5. Quali sono i requisiti non funzionali impliciti (es. persistenza, sicurezza)?

[FASE 2: GENERAZIONE SUITE DOCUMENTALE]
Una volta confermata l'analisi, genera separatamente i seguenti documenti:

1. **REVERSE-SRS (Requirements Specification):**
   - Elenca i Requisiti Funzionali (FR-x) estratti dal codice.
   - Definisci i Requisiti Non Funzionali (NFR-x) osservati.
   - Mappa le interfacce esterne (API, Filesystem, Hardware).

2. **REVERSE-SAD (Software Architecture Document):**
   - **Architecture Pattern:** Identifica se il progetto è un Monolito, Layered, o Event-driven.
   - **Component Diagram:** Diagramma Mermaid 8.8.2 dei moduli reali.
   - **Class Diagram:** Struttura dei dati e relazioni tra oggetti.
   - **Sequence Diagram:** Esempio di interazione tra i componenti per la funzione principale.

3. **GAP ANALYSIS (Critical Review):**
   - Confronta l'esistente con i principi SOLID e Clean Code.
   - Identifica potenziali vulnerabilità di sicurezza o colli di bottiglia.
   - Proponi una Roadmap di Refactoring per colmare i gap trovati.

[VINCOLI TECNICI]
- **Tracciabilità:** Ogni Requisito Funzionale (FR-x) deve essere collegato alla classe/funzione che lo implementa.
- **Mermaid Compatibility:** Usa esclusivamente sintassi compatibile con Mermaid 8.8.2.
- **Precisione:** Distingui tra ciò che il codice fa OGGI e ciò che è suggerito come miglioramento.

[OUTPUT]
Inizia con: "Analisi Forense del codice avviata. Ecco i risultati del rilevamento iniziale:"

📉 Workflow Operativo (Mermaid 8.8.2)

graph TD
    A[Codice Esistente] --> B[Protocollo: LV_sync_doc v4]
    B --> C[Manuali, README, Changelog]
    C --> D{Prompt: Reverse Architect}
    A --> D
    D --> E[Documento: REVERSE-SRS]
    D --> F[Documento: REVERSE-SAD]
    D --> G[Documento: GAP ANALYSIS]
    G --> H[Roadmap di Refactoring]

    style H fill:#f96,stroke:#333,stroke-width:2px

💡 Perché questo processo non è “barare”

In ingegneria dei sistemi, documentare l’esistente è un’attività di Governance.

Recupero della Conoscenza: Spesso dimentichiamo perché abbiamo scelto una determinata libreria o un certo algoritmo. Il Reverse Architecting forza l’IA a spiegarcelo.
Manutenibilità: Senza un SAD, il refactoring è un salto nel buio. Con un SAD ricostruito, vedi subito quali moduli verranno impattati da una modifica.
Audit di Sicurezza: L’IA, mappando i requisiti di sicurezza ex-post, può evidenziare che avevi previsto una validazione dell’input che nel codice non è mai stata scritta (FR non implementato).

🛠️ Come utilizzare i risultati

Archiviazione: Salva i documenti prodotti nella cartella doc/design/ del tuo progetto.
Ciclo Feedback: Usa la Gap Analysis come lista di task per il prossimo sprint di sviluppo.
Sincronizzazione: Una volta che il progetto è formalizzato, usa il protocollo Design-First per ogni nuova feature futura.

Tags: #ReverseEngineering #SoftwareArchitecture #Forensics #CleanCode #Metodologia*