# Buone pratiche di sviluppo web: le dieci che pagano Dieci pratiche di sviluppo web con un ritorno misurabile: commit piccoli, test sul comportamento, lint in CI, soglie di performance e riuso invece di riscrittura. Con i riferimenti normativi. > Pagina: https://ui.eneawork.it/blog/buone-pratiche-sviluppo-web > Markdown: https://ui.eneawork.it/blog/buone-pratiche-sviluppo-web.md *2026-11-01* Le web development best practices che pagano sono quelle che un controllo automatico può far rispettare: commit piccoli, test sul comportamento, lint in CI, soglie di performance e riuso di componenti. Le altre restano buone intenzioni finché non c'è un comando che fallisce. Il catalogo EneUI conta 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, misurati e letti da /api/stats il 1 novembre 2026. Il conteggio dei blocchi viene da backend/blocks.js, interrogato lo stesso giorno. La query «web development best practices» cresce del 950% nell'export Google Trends worldwide del 1 novembre 2026: una variazione su indice relativo, non un numero di ricerche. ## Le dieci pratiche, in ordine di ritorno Commit piccoli e messaggi leggibili. Un commit che fa una cosa si può annullare senza perdere il resto. Il formato Conventional Commits è una convenzione, non una legge: serve a generare il changelog e a rendere la storia leggibile.,Revisione del codice prima del merge. Chi scrive non vede i propri errori. Una revisione da venti minuti su una modifica piccola trova più difetti di una revisione da due ore su un ramo enorme.,Tipi o validazione ai confini. TypeScript aiuta dentro il progetto; ai confini serve una validazione a runtime, perché il JSON che arriva da una API non ha tipi. Zod è la scelta più diffusa nel 2026, con licenza MIT.,Test sul comportamento. Un test che cerca un testo o un ruolo ARIA sopravvive al cambio di componenti. Un test che cerca una classe CSS va riscritto a ogni restyling.,Lint e formattazione in CI. Prettier e ESLint tolgono le discussioni di stile dalla revisione e rendono il diff leggibile. La configurazione va versionata con il codice.,Semantica HTML prima dell'ARIA. Un button è accessibile per costruzione; un div con un click handler non lo è. La norma tecnica di riferimento è WCAG 2.2, raccomandazione W3C del 5 ottobre 2023.,Budget di performance. Fissare un limite di peso per rotta, per esempio 200 KB di JavaScript compresso, impedisce che il bundle cresca senza che nessuno se ne accorga.,Gestione degli errori visibile. Un errore silenzioso in console è un errore che l'utente vede come pagina bianca. Ogni confine di errore deve mostrare un messaggio e registrare il contesto.,Segreti fuori dal repository. Chiavi e token stanno in variabili d'ambiente, mai in un file committato. Un segreto nel repository resta nella storia anche dopo la cancellazione.,Documentazione breve e datata. Un file di decisioni con data, contesto e alternativa scartata vale più di un wiki fermo. Chi arriva dopo capisce perché, non solo cosa. ## Come farle rispettare senza riunioni La differenza tra una pratica e un'opinione è il comando che la verifica. Metti lint e Lighthouse CI nella pipeline: il primo blocca lo stile, il secondo blocca il regresso di performance. Se il controllo è lento, fallo partire solo sui file cambiati, ma non toglierlo. npx eslint . --max-warnings=0 npx @lhci/cli autorun --collect.url=https://example.com Le soglie non vanno inventate: LCP sotto 2,5 secondi, CLS sotto 0,1 e INP sotto 200 ms sono i valori che Google usa per classificare una pagina. Come impostarli in un workflow è in soglie Lighthouse CI. ## Sicurezza e privacy: due riferimenti da conoscere Il regolamento (UE) 2016/679, del 27 aprile 2016, articolo 25, chiede protezione dei dati fin dalla progettazione e per impostazione predefinita: significa raccogliere solo i campi necessari e cancellarli quando non servono. L'articolo 32 chiede misure adeguate al rischio, fra cui cifratura e controllo degli accessi. Non è un tema solo legale: un modulo che invia dati personali in chiaro è un difetto tecnico, non una scelta di prodotto. Per l'accessibilità il riferimento resta WCAG 2.2, e per la pubblica amministrazione italiana la legge 9 gennaio 2004, n. 4, articolo 3. ## La pratica che nessuno cita: scrivere meno codice Ogni riga scritta va letta, testata e mantenuta. Riusare un blocco già provato costa una configurazione; riscriverlo costa una funzionalità e un difetto futuro. I componenti form coprono validazione e stati di errore, le tabelle coprono ordinamento e paginazione, e una libreria consolidata come shadcn/ui porta il comportamento accessibile senza inventarlo. Il confronto tra Tailwind e Bootstrap aiuta a scegliere il livello giusto di astrazione. ## Dove queste pratiche non bastano Su un progetto legacy senza test, introdurre una pipeline completa in un giorno blocca il rilascio. In un team di una persona, la revisione tra pari non esiste e va sostituita da controlli automatici più severi. E nessuna pratica sostituisce la conoscenza del dominio: un test verde su una funzione che risolve il problema sbagliato resta un test verde inutile. ## Da dove partire questa settimana Aggiungi lint e formattazione alla CI: è la modifica più rapida e la meno discussa.,Scrivi un test sul percorso principale, non dieci test sulle funzioni interne.,Fissa un budget di peso per la pagina più visitata e collegalo a Lighthouse CI.,Sostituisci un componente scritto a mano con uno già accessibile, partendo dai componenti form.,Leggi che cos'è lo sviluppo web se devi spiegare il mestiere a chi decide, e come fare un audit di accessibilità prima del prossimo rilascio. ## FAQ ### Qual è la pratica di sviluppo web più importante? La revisione del codice su modifiche piccole: intercetta difetti che nessun tool vede e diffonde conoscenza nel team. Va accompagnata da lint e test automatici, altrimenti dipende dalla disponibilità delle persone. ### Quanti test servono per un sito web? Non esiste un numero giusto. Servono test sui percorsi che generano valore, come login, pagamento e invio di un modulo, e un test di fumo che dica in trenta secondi se il sito è rotto. ### TypeScript è obbligatorio? No, ma riduce gli errori nei progetti che crescono e durano. Su uno script di poche righe il costo di configurazione può superare il beneficio. ### Che differenza c'è tra lint e test? Il lint analizza il codice senza eseguirlo e trova pattern rischiosi o incoerenti. Il test esegue il comportamento e verifica il risultato. Servono entrambi perché vedono problemi diversi. ### La performance è una pratica di sviluppo o un lavoro finale? È una pratica continua. Fissare un budget e misurarlo a ogni modifica costa poco; ottimizzare tutto alla fine costa molto e spesso richiede di riscrivere componenti.