Ho lavorato come Shopify developer presso Making Science per circa un anno e mezzo, tra il 2023 e il 2024. Era la mia prima esposizione seria a un ambiente di sviluppo e-commerce su scala B2C e B2B con clienti reali, scadenze reali e code in produzione che doveva funzionare senza intoppi. Ho imparato moltissimo — ma quasi niente da corsi o tutorial.
Il problema con i tutorial su Liquid
La documentazione di Shopify è buona. I tutorial su YouTube e i corsi online sono mediocri, non perché spieghino le cose in modo sbagliato, ma perché spiegano le cose in un ambiente controllato. Ti mostrano come creare una sezione, come usare i filtri, come accedere agli oggetti del tema. Non ti mostrano cosa succede quando erediti un tema scritto male da qualcuno tre anni fa, con snippet annidati a quattro livelli e variabili globali usate in modo inconsistente.
Il primo progetto su cui ho messo mano era esattamente così. Ho passato i primi tre giorni solo a capire la struttura — cosa sovrascriveva cosa, dove stava la logica di rendering, perché certi prodotti si comportavano diversamente dagli altri.
In produzione, il 70% del lavoro di un developer Shopify è leggere e capire codice scritto da qualcun altro. Il 30% è scrivere il tuo. Preparati alla prima parte.
L'architettura che funziona davvero
Dopo i primi mesi ho iniziato a capire i pattern che rendono un tema mantenibile nel tempo. Le cose più importanti che ho imparato sull'organizzazione del codice:
- Snippet con un solo scopo: ogni snippet dovrebbe fare una cosa sola e ricevere tutti i dati di cui ha bisogno come parametri espliciti, non prendere variabili dall'ambiente globale. Sembra ovvio, ma quasi nessun tema lo fa.
- Sezioni come componenti autonomi: una sezione dovrebbe funzionare anche se spostata in un altro contesto. Le dipendenze implicite tra sezioni sono la principale fonte di bug difficili da tracciare.
- Schema JSON pulito: il blocco
schemadi una sezione è l'interfaccia che il merchant vedrà nel customizer. Più è chiaro e organizzato, meno richieste di supporto arriveranno.
Il tracking: il punto più sottovalutato
In Making Science lavoravo a stretto contatto con il team marketing, che aveva bisogno di dati precisi su ogni evento di conversione. Questo mi ha portato a fare qualcosa che molti developer Shopify ignorano completamente: capire davvero come funziona il tracking degli eventi in un e-commerce.
Shopify ha la sua infrastruttura di analytics (Shopify Analytics, poi Customer Events), che si sovrappone a GA4, al Pixel di Meta e a qualsiasi altro sistema di tracciamento il cliente voglia usare. La sfida è evitare deduplicazioni sbagliate, eventi doppi e discrepanze tra piattaforme. Ho imparato a testare ogni implementazione con il browser network inspector aperto e a non dare mai per scontato che un evento stesse arrivando correttamente.
Performance: quello che paga davvero
Shopify gestisce la maggior parte dell'infrastruttura, quindi molte ottimizzazioni lato server non sono nelle mani dello sviluppatore. Quello che puoi controllare è il front-end: javascript caricato in modo bloccante, immagini non ottimizzate, CSS non usato, font che bloccano il rendering.
Il guadagno più grande che ho visto su un singolo store è stato rimuovere tre app non utilizzate
che continuavano a iniettare script nel head di ogni pagina. LCP migliorato di
oltre un secondo. A volte il lavoro migliore non è scrivere codice, ma rimuoverlo.
Cosa farei diversamente se ricominciassi
Impianterei un ambiente di staging serio fin dal primo giorno. In fretta si tende a lavorare direttamente sul tema attivo — e si paga un prezzo quando un errore va in produzione mentre qualcuno sta comprando. Shopify ha i temi in preview proprio per evitarlo, ma richiede disciplina usarli sistematicamente.
E documenterei molto di più. Le scelte non ovvie — perché quel componente funziona in quel modo, perché quella condizione esiste — le dimentichi in tre settimane. Il tuo sé futuro (o il developer che eredita il codice dopo di te) te ne sarà grato.