TypeScript: Come la Type Safety Ci Ha Salvato
Tre anni fa il nostro frontend era in JavaScript puro. Poi un bug in produzione è costato due giorni di lavoro: un campo undefined che passava silenziosamente attraverso 4 componenti React prima di rompere tutto. Da quel giorno, TypeScript è diventato obbligatorio su ogni progetto i3k. Ecco perché non torneremmo mai indietro.
Il Bug Che Ha Cambiato Tutto: Da JavaScript a TypeScript
Era un venerdì pomeriggio — ovviamente. Un cliente di CRM81 ci segnala che la lista dei deal non carica più. Apriamo la console: "Cannot read property 'amount' of undefined". Il problema? Un endpoint API aveva cambiato la struttura della risposta: il campo deals era diventato deals_list, e nessuno aveva aggiornato il frontend. In JavaScript, il codice non si lamenta se accedi a un campo che non esiste — restituisce semplicemente undefined e va avanti. Quell'undefined ha attraversato quattro componenti React prima di causare il crash nel componente che provava a fare .toFixed(2) su undefined. Con TypeScript, quel bug non sarebbe mai arrivato in produzione. Il tipo dell'oggetto risposta avrebbe generato un errore in fase di compilazione nel momento esatto in cui qualcuno avesse cambiato l'interfaccia API. Non serviva nemmeno un test — il compilatore avrebbe bloccato il deploy. La migrazione è iniziata il lunedì successivo. Abbiamo deciso di non fare il big bang (rinominare tutti i .js in .ts in una volta), ma di adottare un approccio incrementale: ogni nuovo file doveva essere .tsx/.ts, e ogni file toccato per bugfix o feature veniva convertito. In 4 mesi, l'80% del codebase di CRM81 era TypeScript. Oggi siamo al 100% su tutti i progetti.
Type Safety nel Mondo Reale: Pattern Che Usiamo Ogni Giorno
Il valore di TypeScript non sta solo nel catturare undefined. Ecco i pattern che ci hanno fatto risparmiare più tempo in i3k. Primo: discriminated unions per gli stati dell'applicazione. In LetsAI, un job AI può essere in stato "pending", "processing", "completed" o "failed". Con TypeScript, ogni stato ha il suo tipo con campi diversi — un job completed ha un campo result, un job failed ha un campo error, e il compilatore ti obbliga a gestire tutti i casi. Niente più "result is undefined because the job actually failed". Secondo: strict mode senza compromessi. Nel nostro tsconfig.json abbiamo strict: true, noUncheckedIndexedAccess: true, e exactOptionalPropertyTypes: true. È severo? Sì. Ti costringe a gestire ogni possibile null e undefined? Sì. Ma dal giorno in cui l'abbiamo attivato, i bug legati a valori nulli in produzione sono calati dell'85%. Un numero che giustifica qualsiasi lamentela sulle annotazioni di tipo in più. Terzo: generics per le API. Abbiamo un wrapper fetch tipizzato: apiClient.get<DealResponse>('/api/deals'). Il tipo di ritorno è automaticamente DealResponse, e se l'endpoint cambia struttura, il compilatore segnala ogni punto del codice che usa quella risposta. In un progetto con 200+ chiamate API, questo ha eliminato un'intera classe di bug. Quarto: i tipi come documentazione vivente. Le interfacce TypeScript sono la documentazione più aggiornata che abbiamo. Quando un nuovo sviluppatore entra nel team, non deve chiedere "che campi ha un Deal?" — guarda l'interfaccia e sa tutto. Interfacce che si aggiornano automaticamente con il codice, al contrario dei commenti che invecchiano.
L'Impatto su DX e Produttività: I Numeri Reali
Dopo la migrazione completa a TypeScript su tutti i progetti i3k (i3k.eu, CRM81, LetsAI, RAG Enterprise PRO frontend), abbiamo misurato l'impatto sulla produttività del team. I risultati hanno superato le aspettative. Bug in produzione legati a tipi/null/undefined: da 12 al mese a meno di 2. Tempo medio di onboarding per nuovi sviluppatori: da 3 settimane a 10 giorni, perché i tipi guidano la comprensione del codice. Tempo di code review: ridotto del 30%, perché il compilatore cattura i problemi banali prima che arrivino alla review. Velocità di refactoring: 3x più veloce. Rinominare una prop React o cambiare la struttura di un oggetto? Il compilatore ti mostra istantaneamente tutti i punti da aggiornare. L'unico costo reale è il tempo di compilazione. Il nostro progetto più grande (CRM81, ~800 file TypeScript) impiega 18 secondi per un type-check completo. Ma con l'incremental compilation attiva, i check durante lo sviluppo sono sotto i 2 secondi. Un prezzo irrisorio per la sicurezza che offre. Il consiglio che diamo a chi sta valutando la migrazione: iniziate con strict: false e attivate le opzioni strict una alla volta. Iniziate dai file più critici (API layer, modelli dati, componenti condivisi) e lasciate per ultimi i file meno importanti. In 3-4 mesi sarete full TypeScript senza mai bloccare lo sviluppo di feature.
Servizi Correlati
Scopri come applichiamo queste tecnologie nei nostri progetti enterprise.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu