TypeScript è il mio linguaggio principale e, con il tempo, ha smesso di essere una semplice scelta tecnica per diventare un insieme di valori. Non regole da una guida di stile, ma abitudini che determinano se una codebase sarà ancora piacevole da modificare dopo due anni e tre nuovi sviluppatori.
L’onestà viene prima della comodità. La modalità strict è attiva dal primo commit. any è una segnalazione di bug, non un tipo; se davvero non conosco la forma dei dati, uso unknown e restringo il tipo. Un tipo che mente — un cast as per zittire il compilatore — è peggio di nessun tipo, perché tutti i componenti a valle si fidano. Quando il compilatore si lamenta, di solito ha ragione: la correzione è nei dati, non nell’annotazione.
Rendi impossibili gli stati impossibili. Invece di tre flag, isLoading, isError e data, che possono contraddirsi, uso una union discriminata: idle, loading, success con i dati, error con una causa. Lo stesso vale nel dominio: un ordine pagato ha un paymentId, uno non pagato no. Uno switch con controllo esaustivo tramite never trasforma il caso dimenticato — potenziale incidente in produzione — in una riga rossa nell’editor.
Fidati all’interno, verifica ai confini. I tipi scompaiono a runtime: ogni dato che attraversa un confine — body HTTP, webhook, form, localStorage o risposta di un LLM — viene analizzato con Zod o uno schema simile, dal quale si inferisce il tipo. Una sola fonte di verità evita discrepanze tra ciò che convalidiamo e ciò che crediamo. Dentro l’app, i dati tipizzati fluiscono senza controlli difensivi a ogni riga.
Condividi contratti, non supposizioni. In un prodotto full-stack i tipi API vengono generati o condivisi da OpenAPI, GraphQL Codegen, Prisma o un pacchetto comune. Così rinominare un campo interrompe la build, non il checkout. La leggibilità vale più dell’astuzia: una semplice interface comprensibile in dieci secondi a un nuovo collega conta più di un conditional type a cinque livelli che dimostra che ho letto il manuale. I generics servono al riuso, non a mettersi in mostra.
I tipi non sostituiscono test, review o ragionamento: rendono tutti e tre meno costosi. Questo è il vero valore di uno sviluppatore TypeScript: non conoscere ogni utility type, ma lasciare codice che la persona successiva può modificare con fiducia. Se la tua codebase è piena di any e il team teme il refactoring, mandami il modulo che nessuno vuole toccare. Ti spiegherò come lo tipizzerei e quali problemi verrebbero intercettati.
Dai al prossimo prodotto qualcuno che resti.
Pronto a iniziare? Scrivimi: posso cominciare subito e restare. Collaborazioni a lungo termine, non passaggi di consegne dopo due settimane. Parliamo del progetto, dei requisiti e del modo migliore per procedere.