Emanuel Pinto, sviluppatore full-stack: «Il codice si impara in fretta, le basi no»

Emanuel Pinto è uno sviluppatore full-stack a partita IVA, specializzato in Node.js, React e Laravel, che firma RiverDevStudio lavorando spesso «dietro le quinte» per agenzie di comunicazione sui progetti dei loro clienti. Tra i lavori più complessi che ha affrontato, un motore di prenotazione capace di reggere duemila utenti simultanei senza mai assegnare due volte lo stesso posto — risolto con Redis e uno script Lua atomico, con un percorso di riserva su SQL in caso di necessità — e il backend di un sistema IoT già in produzione, con più di diecimila dispositivi connessi.

Lo abbiamo intervistato per la rubrica Vita da freelance perché il suo è un percorso che mette al centro l’ingegneria dietro il codice, non solo la scrittura del codice in sé. Pinto racconta come decide lo stack giusto per un progetto, cosa cambia nel lavorare dietro le quinte per un’agenzia rispetto al rapporto diretto con il cliente, quali errori vede più spesso in chi affida un progetto senza le competenze tecniche per valutarlo, e cosa direbbe a chi oggi vuole iniziare come sviluppatore freelance.

Il motore di prenotazione che hai costruito ha retto 2.000 utenti simultanei senza mai assegnare due volte lo stesso posto: cosa rende davvero difficile evitare quel tipo di errore, e come l’hai risolto?

La difficoltà sta tutta nel racing tra le richieste: due persone cliccano sullo stesso posto nello stesso istante e il sistema deve dire sì a una sola. È una cosa molto complessa da testare e da identificare, perché in locale non si manifesta quasi mai e sotto carico sì, e per questo richiede molta cura. L’ho risolto con Redis e uno script Lua atomico, così controllo e prenotazione del posto avvengono in un’unica operazione.

Se Redis non è disponibile c’è un percorso di riserva su SQL con lock di riga, e una riconciliazione periodica riallinea i contatori con il database. Il tutto verificato con test di carico a 2.000 utenti per un’ora: zero errori e zero posti assegnati due volte, controllati con una query diretta sul database.

Lavori con Node.js, React e Laravel: come scegli lo stack giusto quando parti da zero su un progetto nuovo, e capita di doverne cambiare uno a lavoro già avviato?

Tendo sempre a definire prima le specifiche, quindi non mi è mai capitato di dover cambiare stack a lavoro già iniziato. Quando il cliente racconta i suoi bisogni, cosa deve fare l’applicazione, chi la userà e con cosa deve parlare, diventa spesso facile inquadrare anche lo stack di cui ha bisogno: la tecnologia viene dopo il problema, non prima. Node.js, React e Laravel sono strumenti diversi per esigenze diverse, e la scelta nasce da lì, non dalla preferenza del momento. Se le specifiche sono chiare dall’inizio, la domanda del cambio in corsa in pratica non si pone.

Spesso lavori «dietro le quinte» per altre agenzie, senza un rapporto diretto con il cliente finale: cosa cambia davvero nel modo di lavorare rispetto a un incarico diretto?

Cambia sicuramente il modo di porsi e di lavorare. Dietro un’agenzia è più semplice: spesso ha già raccolto tutte le informazioni che servono per il progetto, il brief arriva definito e io posso concentrarmi sulla parte tecnica. Con il cliente diretto devo anche capire le sue necessità, e a volte aiutarlo a metterle a fuoco, perché non sempre un bisogno arriva già tradotto in requisiti. In pratica nel primo caso faccio lo sviluppatore, nel secondo faccio anche un pezzo di analisi prima di scrivere una riga di codice.

Qual è il progetto più complesso che hai affrontato come freelance, e cosa ti ha lasciato?

Sicuramente quello di gestione IoT: il backend di un sistema già in produzione, con più di 10.000 dispositivi connessi, che fa da ponte tra i dati dei dispositivi e le app degli utenti. Non era un progetto da costruire da zero ma un sistema vivo, con dispositivi reali e utenti reali, su cui ogni nuova funzionalità doveva entrare senza fermare o rompere quello che già funzionava.

Mi ha lasciato soprattutto l’abitudine a ragionare prima su cosa può rompersi e solo dopo su cosa aggiungere, che è il modo per rilasciare su un sistema in produzione senza regressioni.

Quali sono gli errori più comuni che vedi in chi affida un progetto a uno sviluppatore esterno senza avere le competenze tecniche per valutarne il lavoro?

L’errore più comune è giudicare il lavoro da come appare. Si finisce facilmente ad avere un applicativo che sembra bellissimo quando lo apri la prima volta, ma che inizia a cadere a pezzi man mano che lo usi: dati che si perdono, lentezze appena crescono gli utenti, funzioni che si rompono a ogni modifica.

Senza contare la sicurezza, dell’applicativo e degli utenti, che da fuori non si vede per niente e spesso viene scoperta solo quando è troppo tardi. Chi non ha competenze tecniche tende a valutare l’interfaccia, mentre il valore vero sta in quello che c’è sotto: struttura, test, gestione dei dati e degli accessi.

Cosa diresti a chi vuole iniziare oggi come sviluppatore freelance, partendo da zero?

Direi di studiare molta ingegneria. Oggi non si è più semplici scrittori di codice: bisogna ingegnerizzare sistemi, cioè capire come stanno in piedi, come reggono il carico, come si evolvono nel tempo. Quindi studiate bene algoritmi, analisi, fisica se vi interessa il gaming, e tutte quelle cose che all’inizio sembrano noiose e lontane dal lavoro vero.

Vi torneranno utili, e spesso saranno proprio quelle a fare la differenza tra chi scrive una funzione che gira e chi costruisce qualcosa che regge. Il codice si impara in fretta, le basi no, e sono le basi che restano quando cambiano linguaggi e framework.