Gli strumenti di sviluppo web che contano davvero
Gli elenchi di strumenti invecchiano in fretta e raramente aiutano chi commissiona un sito. Ciò che dura è l'insieme di *categorie* che un progetto competente usa, e cosa dice la loro assenza su come andrà il progetto.
Questa guida copre le categorie che contano, cosa previene ciascuna, e le domande che rivelano se chi sviluppa lavora così.
Le categorie non negoziabili#
Non sono preferenze. Un progetto che ne fa a meno accumula un rischio che emerge nel momento peggiore, di solito quando qualcosa si rompe e nessuno sa dire cosa sia cambiato.
| Categoria | Cosa previene | Chiedi |
|---|---|---|
| Controllo di versione | Lavoro perso, cambiamenti inspiegabili, impossibilità di tornare indietro | «In quale repository sta il codice e posso avere accesso?» |
| Ambiente di preproduzione | Collaudare in produzione | «Dove revisiono prima che vada online?» |
| Rilascio automatizzato | Una persona che copia file a mano il venerdì alle 18 | «Come arriva una modifica in produzione?» |
| Backup | Perdita totale | «Ogni quanto, dove, e quando ne avete ripristinato uno l'ultima volta?» |
| Monitoraggio degli errori | Guasti silenziosi che nessuno nota per settimane | «Come venite a sapere che qualcosa si è rotto?» |
| Monitoraggio della disponibilità | Saperlo da un cliente | «Chi viene avvisato quando il sito cade?» |
| Aggiornamento delle dipendenze | Vulnerabilità note lasciate lì | «Come vengono applicati gli aggiornamenti di sicurezza?» |
Il segnale più forte è la risposta a «come arriva una modifica in produzione?». Se comporta il trascinare file in un client FTP, probabilmente manca anche tutto il resto di questo elenco.
Strumenti di build e front-end#
Qui la moda si muove più in fretta ed è quello che meno ti riguarda come cliente. Ciò che conta è il risultato, non lo strumento che l'ha prodotto.
- Un passo di build che minifica, raggruppa e ottimizza le risorse: il peso di pagina è un problema di conversione, non di purezza.
- Una catena per le immagini che produce automaticamente formati moderni e più dimensioni. Le immagini esportate a mano non restano mai aggiornate.
- Un approccio al CSS con un sistema — variabili, token, comunque si chiami — anziché un accumulo di regole estemporanee.
- Solo il JavaScript che serve alla pagina. Un framework è una scelta legittima per un'applicazione e di solito un peso inutile per un sito vetrina.
- Supporto browser definito per iscritto. «I browser moderni» non è una specifica.
Strumenti di collaudo e qualità#
Suite di test automatici complete si giustificano raramente su un sito di marketing. Un po' di automazione sui percorsi che portano denaro si giustifica quasi sempre.
- Verifiche automatiche solo sui percorsi critici: checkout, registrazione, modulo di contatto principale.
- Un budget di prestazione verificato automaticamente: un numero che fa fallire una build, non una speranza.
- Analisi automatica di accessibilità nella catena, sapendo che individua circa un terzo dei problemi.
- Verifiche tra browser su quelli che le tue statistiche mostrano davvero, non su un elenco di tutto.
- Un set di contenuti di preproduzione che rispecchi lunghezze reali, comprese quelle scomode.
Un budget di prestazione è l'automazione più redditizia per un sito editoriale: senza, il peso di pagina sale in silenzio ogni mese e nessuno ne risponde.
A cosa dovresti avere accesso#
Indipendentemente dagli strumenti preferiti da chi sviluppa, questi account dovrebbero essere a tuo nome dal primo giorno. È molto più facile sistemarlo all'avvio che dopo la fine di una collaborazione.
- Il registrar del dominio, a nome della tua organizzazione, con i tuoi dati di fatturazione.
- L'account di hosting, con chi sviluppa aggiunto come utente anziché come proprietario.
- Il repository del codice, con la tua organizzazione come proprietaria.
- Le proprietà di statistiche e Search Console.
- Ogni servizio di terze parti da cui dipende il sito: pagamenti, e-mail, CDN, monitoraggio errori.
- Un elenco scritto di tutto questo, conservato dove il tuo team possa trovarlo.
Domande frequenti
Devo capire questi strumenti?
No, ma dovresti chiedere se esistono e chi vi ha accesso. Le domande della tabella qui sopra ottengono una risposta di una frase ciascuna da chiunque sia competente, e un'esitazione su rilascio e backup è un segnale vero anziché una questione di stile.
Serve un framework JavaScript?
Per un'applicazione web, di solito sì. Per un sito di marketing o editoriale, di solito no, e spesso costa prestazioni senza beneficio, perché il browser deve scaricare ed eseguire un framework prima di mostrare testo che poteva stare nell'HTML. La domanda giusta è quale problema risolva sul tuo sito, e «è quello che usiamo» non è una risposta.
Cos'è un budget di prestazione?
Un limite concordato — per esempio meno di 200 KB di JavaScript e un Largest Contentful Paint sotto 2,5 secondi sui template principali — verificato automaticamente e che fa fallire la build quando viene superato. Funziona perché trasforma la prestazione da qualcosa che tutti dicono importante in qualcosa che blocca un rilascio.
Come faccio a sapere se il sito viene mantenuto?
Chiedi una nota mensile: cosa è stato aggiornato, cosa è stato corretto, quale è stata la disponibilità, e quali errori sono emersi. Se un canone di manutenzione non produce alcun rapporto, è difficile distinguere una manutenzione accurata dall'assenza di manutenzione, e di solito lo si scopre durante un incidente.
strumenti sviluppo webstack sviluppo webcontrollo di versioneambiente di preproduzionebudget di prestazionecatena di rilascio
