Sviluppo web
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.
In sintesi
- Una pratica è utile solo se produce un controllo automatico: senza CI diventa una raccomandazione che nessuno segue.
- Test sul comportamento sopravvivono ai refactor; test sull'implementazione vanno riscritti a ogni cambio di struttura.
- Il riuso di componenti e blocchi riduce il codice nuovo, che è la prima fonte di difetti.
- Il regolamento (UE) 2016/679, articolo 25, chiede privacy e sicurezza già nella progettazione, non dopo il primo incidente.
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.
Le dieci pratiche, in ordine di ritorno
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.comLe 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
Domande frequenti
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.