Software Development

Cos’è una closure in JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter viene eseguita una volta, restituisce una funzione, e la sua chiamata finisce lì: lo stack frame non esiste più. Eppure ogni chiamata a counter() legge e aggiorna count, una variabile dichiarata dentro una funzione già terminata. count non torna a 0, e non viene copiata. È la stessa variabile, ancora viva, tre chiamate dopo. ...

Un test scritto dopo il codice tende a verificare quello che il codice fa, non quello che doveva fare. Il test-driven development risolve il problema invertendo l’ordine: scrivi il test, guardalo fallire, poi scrivi il minimo codice che lo fa passare. Dato che il test esiste prima del codice che controlla, non può confermare silenziosamente qualunque cosa il codice restituisca. Kent Beck ha formalizzato questo ciclo come red, green, refactor nel suo libro del 2002 Test-Driven Development: By Example. Il nome è rimasto. ...

Disconnetti un utente da un’app basata su sessione e il server lo dimentica alla richiesta successiva. Disconnettilo da un’app basata su JWT e, a meno che tu non abbia costruito un meccanismo apposito, il token che ha in mano resta valido finché non scade. Questa è la vera decisione dietro “JWT vs sessione”. Il resto ne consegue. Cosa memorizza davvero una sessione Una sessione mantiene lo stato dell’utente sul server e al browser passa solo una chiave di lookup. ...

Avvolgi una chiamata fetch() in un try/catch, chiama un endpoint che risponde con un 404, e il blocco catch non si attiva mai. La promise si risolve. res.json() analizza qualunque corpo il server abbia restituito, spesso un payload di errore come {"error": "user not found"}, e il resto della funzione lo tratta come il record che aveva richiesto. Nessuna eccezione, nessun avviso in console. Il dato sbagliato continua a propagarsi finché qualcos’altro non va in errore per colpa sua. ...

Una funzione che richiama se stessa ha una profondità massima, ed è più piccola di quanto la maggior parte delle persone si aspetti: 1.000 chiamate in CPython di default, circa 10.000-15.000 in Node e nei motori dei browser, a seconda di quanto pesa ogni frame. Superarla non significa che il programma rallenta: crasha. Python solleva RecursionError: maximum recursion depth exceeded; JavaScript solleva RangeError: Maximum call stack size exceeded. Entrambi gli errori hanno la stessa causa, e una volta vista capisci subito quando la ricorsione è lo strumento giusto e quando diventa un rischio. ...

Stai costruendo una dashboard: un header, una sidebar, un’area di contenuto principale, un footer. Scegli Flexbox perché è lo strumento di layout che conosci, e venti minuti dopo ti ritrovi con tre container display: flex annidati, una sidebar che non mantiene la sua larghezza senza un numero magico, e un footer che fluttua a metà pagina quando il contenuto è poco. Niente di tutto questo è un bug di Flexbox. Stai usando uno strumento monodimensionale su un problema bidimensionale. ...

Metti go davanti a una chiamata di funzione e quella funzione parte in concorrenza col resto del programma, gestita dal runtime di Go invece che dal sistema operativo. Avviarla è la parte facile. La parte difficile è far passare un risultato tra due goroutine senza che si pestino i piedi a vicenda sullo stato condiviso, e quel lavoro lo fanno i channel. Cos’è una goroutine? Una goroutine è una funzione che corre in modo indipendente da quella che l’ha avviata, gestita dal runtime di Go e non dal sistema operativo. Un thread del sistema operativo riserva un megabyte o più di stack e costa al kernel tempo reale per essere pianificato. Una goroutine parte con uno stack di circa 2KB che cresce secondo necessità, e il runtime moltiplexa molte goroutine su una manciata di thread del sistema operativo. Avviarne a migliaia è normale. ...

Una classe che salva un utente nel database, gli manda un’email di benvenuto e formatta una ricevuta è a una modifica di distanza dal rompere due funzionalità con cui non ha niente a che fare. Tocchi il template dell’email e rischi la scrittura sul database. Tocchi il layout della ricevuta e rischi l’email. SOLID sono cinque regole che attaccano questo tipo di groviglio da angolazioni diverse, e condividono un’idea sola: una classe deve cambiare per un solo motivo, e il resto del codice deve dipendere da cosa qualcosa promette di fare, non da come lo fa. ...

Due richieste arrivano sullo stesso endpoint “preleva 100€” a mezzo millisecondo di distanza. Il conto ha 150€. Entrambe le richieste leggono quel saldo, entrambe vedono fondi sufficienti, entrambe approvano, entrambe sottraggono 100€. Il conto finisce a -50€, e nessun ramo del codice avrebbe dovuto permetterlo. Questa è una race condition: il risultato dipende da quale operazione finisce prima, e quel “prima” non lo decide il codice. Cosa causa una race condition? Servono due ingredienti insieme: stato condiviso mutabile, e più di un percorso di esecuzione che lo tocca senza coordinarsi. I percorsi possono essere thread, task async, processi, o due server che colpiscono la stessa riga di database. Togli uno dei due ingredienti e il bug scompare. Un singolo thread non può entrare in race con se stesso, e uno stato immutabile non si corrompe anche se viene letto più volte. ...

Una casella di ricerca che lancia una richiesta a ogni tasto premuto manda cinque richieste per “redis”, e quattro arrivano scadute prima che torni la risposta. Un handler di scroll che ricalcola il layout gira centinaia di volte al secondo e fa scattare la pagina. Stesso problema in entrambi i casi: l’evento del DOM si attiva molto più spesso di quanto serva alla funzione. Debounce e throttle lo risolvono in due modi diversi. ...