Le best practice sono un ottimo punto di partenza. Rappresentano l'esperienza distillata di migliaia di sviluppatori che hanno incontrato gli stessi problemi e trovato soluzioni che funzionavano per loro — nel loro contesto, con i loro vincoli. Questo è genuinamente prezioso.
Ma ecco dove va storto: gli sviluppatori si fermano a «è una best practice» e non chiedono mai «è la migliore pratica per noi?» Trattano le best practice come regole invece di quello che sono realmente — raccomandazioni di persone che non conoscono la tua codebase, il tuo team, i tuoi utenti o i tuoi vincoli.
La fallacia dell'appello all'autorità
Quando discuto di architettura o implementazione con gli engineer, sento regolarmente: «Dovremmo farlo così perché è una best practice.» Non è un argomento. In logica formale si chiama appello all'autorità — l'idea che qualcosa sia corretto perché un'autorità l'ha detto, piuttosto che per il ragionamento dietro.
Le best practice non sono nient'altro che esperienza di altri sviluppatori che hanno espresso ciò che aveva senso per loro nel loro contesto. La maggior parte delle volte, il loro contesto si sovrapporrà al tuo. Ma non sempre. E quando non lo fa, seguirle ciecamente non è ingegneria — è cargo culting.
La soluzione è semplice: ogni volta che qualcuno dice «best practice», chiedi «perché?» Se la risposta è «perché lo dice la documentazione» o «perché tutti fanno così», è un campanello d'allarme. Se la risposta è una ragione tecnica concreta che si applica alla tua situazione, ottimo — ora hai un argomento reale, non un appello all'autorità.
Il disastro del carrello Next.js
L'ho visto succedere presso un grande retailer svizzero. Quando mi sono unito, il team stava costruendo applicazioni e-commerce e aveva adottato Next.js con un approccio rigoroso «server-first» — perché è quello che la documentazione Next.js raccomandava. Renderizzare tutto sul server. Usare Server Component ovunque. Minimizzare il JavaScript lato client.
Il problema? Hanno applicato questo all'intero flusso del carrello e checkout. Ogni azione del carrello — aggiungere un articolo, cambiare quantità, applicare un coupon — innescava un round-trip al server. L'intero checkout era renderizzato lato server.
Sulla carta, questo seguiva le «best practice». In pratica, era un adattamento pessimo. Servivamo solo il mercato svizzero. Ogni carrello è unico per ogni utente — non c'è alcun beneficio nel fare caching lato server dello stato del carrello. L'approccio server-first aggiungeva latenza a ogni interazione senza darci nulla in cambio. Nessun beneficio SEO (Google non indicizza il tuo carrello). Nessun beneficio di caching (ogni carrello è diverso). Solo UX più lenta senza motivo.
Era difficile convincere il team all'inizio. «Ma la documentazione Next.js dice che i server component sono il default» era un argomento reale che ho sentito più volte. L'appello all'autorità era profondamente radicato. Ma quando abbiamo spostato il carrello e il checkout interamente sul client, l'esperienza utente è migliorata drasticamente. Le interazioni sono diventate istantanee. Il codice è diventato più semplice. E non abbiamo perso nessun vantaggio che il rendering lato server presumibilmente ci dava.
Adattalo al tuo contesto
La lezione non è «ignora le best practice». La lezione è: trattale come punto di partenza, poi adattale al tuo contesto specifico. Chiediti:
Quale problema risolve questa pratica? Il mio progetto ha effettivamente quel problema? Quali sono i trade-off nella mia situazione specifica? La raccomandazione si basa su assunzioni che non valgono per noi?
Il rendering lato server è eccellente quando hai bisogno di SEO, quando servi contenuto uguale per molti utenti, quando vuoi caricamenti iniziali veloci su connessioni lente. È overhead inutile quando renderizzi contenuto personalizzato e interattivo dietro autenticazione che nessun motore di ricerca vedrà mai.
Il team Next.js non ha torto. La loro raccomandazione è solida per la maggior parte dei casi d'uso per cui è stata progettata. Ma non sanno che il tuo checkout è solo svizzero, che il tuo carrello è sempre unico, e che i tuoi utenti sono su connessioni internet svizzere veloci. Solo tu conosci il tuo contesto. E solo tu puoi decidere quale pratica si adatta davvero.
Alcune pratiche sono quasi universali
Non tutte le best practice hanno bisogno di forte contestualizzazione. Alcune sono così fondamentali che si applicano quasi ovunque. YAGNI rispetto a DRY — non astrarre finché non è necessario — è una che non ho mai visto fallire in nessun contesto. La separazione tra smart e dumb component — tenere la logica di business fuori dai componenti UI — funziona sia che tu stia costruendo un'app bancaria o un sito e-commerce.
La differenza? Queste pratiche sono radicate in principi fondamentali di design del software — separazione delle responsabilità, evitare l'astrazione prematura — non in raccomandazioni specifiche di un framework. Più una «best practice» è legata a uno strumento o framework specifico, più è probabile che debba essere adattata al tuo contesto.
Costruisci il tuo playbook
I migliori team che ho guidato non seguono le best practice — hanno le proprie pratiche, informate dalle best practice ma adattate alla loro realtà. Si sono presi il tempo di capire perché una raccomandazione esiste, testare se si applica, e documentare cosa funziona realmente per loro.
Questo intendo con «inventa le tue». Non che dovresti ignorare la saggezza collettiva del settore. Ma che dovresti elaborarla attraverso il tuo giudizio ingegneristico invece di accettarla come vangelo. Leggi la documentazione. Comprendi il ragionamento. Poi decidi — con argomenti, non con l'autorità — se si adatta.
Gli engineer che fanno questo costruiscono software migliore. Non perché sono più intelligenti, ma perché pensano invece di seguire.