Decisioni reversibili vs irreversibili in architettura

Non tutte le decisioni costano lo stesso. Cambiare nome a un componente costa minuti. Cambiare schema dati di un’app in produzione con un milione di record costa settimane e rischia di perdere dati. Trattarle allo stesso modo significa o sovra-progettare ogni dettaglio (lento) o agitare alla leggera scelte costose (rischioso). Distinguere le due categorie è il principio architetturale più utile.

Perché questa lezione conta

Bezos chiamò questo principio “porte a uno o a due sensi”. Una porta a due sensi (reversibile): entri, se non ti piace torni indietro. Decidi velocemente. Una porta a uno solo (irreversibile): entri e basta. Decidi piano. La maggior parte degli errori architetturali nei prototipi vibe coding sono porte a uno scambiate per porte a due, perché il modello AI non distingue.

Obiettivo operativo

Alla fine devi saper:

1. classificare una decisione come reversibile o irreversibile;
2. proteggere le irreversibili (più analisi, più alternative, più tempo);
3. non sovraingegnerizzare le reversibili (decidi rapido, prototipa, cambia).

Nucleo della lezione

1. Decisioni reversibili (porte a due sensi)

Caratteristiche:

• cambio rapido (ore, giorni);
• nessun dato perso o degradato;
• impatto contenuto a poche aree;
• nessuna comunicazione esterna (ad altri team, agli utenti).

Esempi tipici:

• Layout e microcopy: cambi UI, sposti elementi, riformuli testi.
• Naming di variabili/funzioni: refactor banale.
• Struttura di componenti piccoli: scorpori, accorpi, sposti.
• Librerie sostituibili: utility piccola, componente UI, helper. Cambiare con altro è ore.
• Contenuti: dati statici, immagini, copy.
• Stile (design tokens): cambi colori, typography, spacing.
• Endpoint interni non documentati: cambi route GET interna senza client esterni.

Approccio: decidi rapido, prototipa, cambia se non funziona. Il modello AI è un eccellente collaboratore qui — costo dell’errore basso, beneficio della velocità alto.

2. Decisioni irreversibili (porte a un senso)

Caratteristiche:

• cambio lento e costoso (settimane, mesi);
• rischio di perdita o degrado dati;
• impatto su molte aree;
• conseguenze esterne (utenti, integrazioni, contratti).

Esempi tipici:

• Schema dati con utenti reali: cambiare struttura tabelle in produzione richiede migrazioni complesse, rischio di downtime, possibile perdita dati.
• Provider di autenticazione: passare da Auth0 a Clerk significa migrare utenti, gestire credenziali, riconfigurare sessioni. Operazione di settimane.
• Modello di permessi: passare da RBAC semplice a ABAC granulare richiede ripensare ogni endpoint.
• Linguaggio/framework principale: passare da Rails a Next.js è praticamente un rewrite.
• Database engine: Postgres → Mongo significa ridisegnare query, schema, accesso.
• Integrazioni profonde: dipendere da un’API esterna che si infiltra in ogni componente → uscirne è un rewrite di feature.
• Identificatori esposti pubblicamente: URL pubblici degli articoli, ID utente in API; cambiarli rompe link esterni.
• Termini contrattuali / pricing: cambiare tier, far pagare ciò che era gratis, modificare ToS.

Approccio: più analisi, più alternative, più tempo. Per queste, chiedi al modello almeno 2-3 alternative motivate, valuta costo migrazione, prototipa il caso più rischioso prima di impegnarti.

3. Casi misti (semi-reversibili)

Alcune decisioni stanno nel mezzo:

• Linguaggio sul progetto piccolo nuovo: reversibile (rewrite di 1000 righe è giorni). Sul progetto medio: irreversibile (rewrite di 50K righe è mesi).
• Stack frontend (React/Vue/Svelte): reversibile su prototipo, irreversibile su app matura con community/lavoratori abituati.
• Hosting: cambiare Vercel → Fly.io è giorni. Ma se hai serverless function infiltrate, è settimane.

Test: stima il costo di reversione in tempo + rischio. Sotto 1 settimana di lavoro = reversibile. Oltre = trattalo come irreversibile.

Procedura pratica

Per ogni decisione architetturale:

1. Classifica: reversibile / irreversibile / mista.
2. Se reversibile: decidi rapido, prototipa, valida, cambia se serve.
3. Se irreversibile: chiedi 2-3 alternative al modello, valuta costo migrazione futura, prototipa il caso più rischioso, decidi con calma.
4. Documenta motivazione: per le irreversibili, scrivi perché hai scelto così. Una settimana dopo dimentichi.
5. Cerca di rendere reversibili: incapsula dipendenze (un wrapper attorno al provider auth ti permette di sostituirlo più facilmente in futuro). Quando possibile, sostituisci una porta a uno con una porta a due.

Laboratorio guidato

Dieci scelte di un progetto, classifica:

1. Postgres come DB primario per app SaaS → irreversibile (cambiarlo dopo lancio = mesi).
2. Tailwind come sistema CSS → reversibile per progetto piccolo, mista per medio, irreversibile per grande con design system.
3. shadcn/ui per componenti → reversibile (componenti copiati nel tuo codice, modificabili).
4. Auth0 come provider auth → irreversibile (cambio = migrazione utenti).
5. JWT short-lived + refresh token in cookie → semi-reversibile (cambio in sessione tradizionale = riconfigurazione client + server, settimane).
6. Slug /articoli/[slug] come URL pubblico → irreversibile dopo che è indicizzato e linkato esterno.
7. Color palette del brand → reversibile (con design tokens centralizzati) o irreversibile (con colori hardcoded ovunque).
8. Email transazionale via Resend vs Postmark → reversibile (è un’API, swap).
9. Stripe come gateway pagamenti → irreversibile (integrazione profonda, webhook, contratti merchant).
10. Naming di una funzione interna → reversibile (refactor di 5 minuti).

Per ognuna delle “irreversibili”, chiediti: come potrei rendere questa decisione più protetta (es. astrazione)?

Output atteso

Tabella decisionale a 3 colonne (decisione, classificazione, strategia) per le 5-10 scelte tecniche principali del tuo progetto attuale. Riusabile come “decision log” del progetto.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: imparare a proteggere le decisioni costose e a non sovra-progettare quelle facilmente cambiabili. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Decisioni reversibili: layout, microcopy, struttura di componenti piccoli, librerie sostituibili.
• Decisioni difficili da cambiare: schema dati, provider di autenticazione, modello di permessi, integrazioni profonde.
• Come chiedere all’AI alternative motivate quando una scelta ha alto costo di inversione.

3. Applicazione: svolgi il laboratorio: classificare dieci scelte tecniche di un progetto per reversibilità, impatto e incertezza. L’output da ottenere è: una mappa delle decisioni da prendere subito, rimandare o prototipare prima di impegnarsi.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• so distinguere reversibile / irreversibile / mista;
• per le irreversibili del mio progetto, ho documentato motivazione e alternative scartate;
• ho almeno una decisione che ho reso più reversibile tramite astrazione;
• non sovraingegnerizzo dettagli reversibili.

Errori comuni

Trattare ogni decisione come irreversibile. Paralisi. Per le reversibili, decidi rapido.

Trattare ogni decisione come reversibile. Salti analisi su scelte costose, paghi mesi dopo.

Schema dati cambiato senza migration plan. Disastro: dati corrotti, downtime, perdite.

Provider scelto senza piano di uscita. “Lock-in non è un problema oggi” → diventa problema dopo 3 anni.

URL pubblici cambiati. “Cambio struttura URL”. Link esterni rotti, SEO perso. Soluzione: ridirezioni 301 permanenti, mantenute per anni.

Niente astrazione attorno a integrazioni profonde. Stripe chiamato direttamente in 50 file. Provando a cambiare = inferno. Wrapper centralizzato salva.

Prompt di lavoro

Sto valutando questa decisione architetturale: [descrizione]

Voglio:

1. Classificare reversibile / irreversibile / mista, con motivazione.
2. Stima del costo di reversione (tempo + rischio dati).
3. Almeno 2 alternative considerate, con trade-off.
4. Suggerimenti per rendere la decisione più protetta (es. astrazione, wrapper, indirezione).
5. Cosa prototipare prima di impegnarsi (se irreversibile).
6. Decision log: testo breve da salvare con motivazione.

Non scrivere codice. Aiutami a decidere bene prima di iniziare.

Esercizio finale

Prendi 3 progetti tuoi (anche vecchi). Per ciascuno, identifica una decisione che con il senno di poi era irreversibile e che hai trattato come reversibile (o viceversa). Cosa ti è costato l’errore di classificazione? Quasi sempre un’ora di analisi in più prima della decisione avrebbe risparmiato giorni dopo. La lezione è esattamente quella: fai un’ora in più, una volta, sui pochi punti che contano davvero.