Smettetela subito di pensare che il vostro futuro lavoro sia al sicuro grazie a quel plugin di auto-completamento che vi suggerisce la prossima riga di Python.

Recentemente è circolata una riflessione (che su Hacker News ha fatto saltare sulla sedia i puristi del clean code) secondo cui, visto che gli LLM possono generare quantità industriali di codice in pochi secondi, perché dovremmo ancora preoccuparci di principi sacri come il DRY (Don’t Repeat Yourself)? L’idea, in soldoni, è: «Perché perdere tempo a rendere il codice elegante e modulare se posso semplicemente chiedere all’AI di sputare fuori un altro mille righe di codice duplicato e inefficiente? Tanto, se qualcosa si rompe, basta rigenerare tutto».

Sì, avete letto bene. È il manifesto del programmatore pigro che ha deciso di delegare la propria dignità professionale a un modello statistico.

Per chi non mastica abbastanza il gergo, il DRY non è solo una regola per evitare di scrivere la stessa funzione dieci volte. È la base della manutenibilità. Scrivere codice come se fosse destinato a essere letto da un essere umano (che un domani, speriamo, sarà ancora voi o un vostro collega che non ha ancora mollato la professione per andare a vendere avocado in California) significa prevedere l’evoluzione del software. Se invece abbracciamo questa filosofia del «codice usa e getta», ci ritroveremo immersi in un mare di spaghetti digitali dove ogni minima modifica richiederà un rituale esorcistico e ore di debugging su funzioni che sembrano scritte in un linguaggio alieno.

Certo, l’entusiasmo per le capacità di coding delle AI è giustificato; sono strumenti potentissimi, dei veri e propri acceleratori di produttività che possono liberarci dai task più noiosi. Ma c’è un limite sottile tra usare l’AI come copilota e usarla come pilota automatico mentre noi stiamo a guardare il paesaggio senza un minimo di controllo sulla rotta.

Il rischio non è solo tecnico, è strutturale. Se smettiamo di applicare la logica e la struttura, stiamo creando un debito tecnico che nessuna AI potrà mai ripagare. E non dimentichiamoci che, nonostante i grandi annunci che leggiamo sui blog delle big tech americane, qui in Italia (e nel resto del mondo che non vive in una bolla di marketing) siamo quelli che poi devono gestire i sistemi quando le cose esplodono. Non abbiamo una foresta di server pronti a ricompilare tutto ogni cinque minuti.

In conclusione: usate pure l’AI per generare boilerplate o unit test, ma non permettete che trasformi il vostro modo di pensare in un processo di copia-incolla senza cervello. Scrivete codice che un essere umano possa mantenere. Perché il giorno in cui l’AI farà un errore logico sottile e impercettibile, sarete voi l’unico essere umano rimasto a cercare di capire perché quel modulo sta bruciando tutto il database.

Source: Write code like a human will maintain it

Quante volte vi è capitato di trovarvi a fissare uno snippet di codice che sembra un puzzle di Escher, dove ogni riga di logica è legata a un parametro assurdo che serve solo a gestire un’eccezione scoperta tre mesi fa?

Se la risposta è ‘troppo spesso’, allora siete nel club giusto. Oggi parliamo di un concetto che farebbe inorridire qualsiasi guru del ‘Clean Code’ scritto da un manager che non ha mai visto un terminale: preferire la duplicazione rispetto alla ‘wrong abstraction’.

Il pattern è tragico, quasi cinematografico, tipo un film horror dove il protagonista ignora i segnali d’allarme. Tutto inizia con un programmatore (chiamiamolo Dev A) che vede due pezzi di codice simili e, con l’entusiasmo di chi ha appena scoperto l’open source, decide di estrarre una funzione. ‘Ecco fatto, codice pulito, elegante, DRY (Don’t Repeat Yourself)!’, pensa Dev A mentre va a prendersi un caffè.

Poi passa il tempo. Arriva un nuovo requisito. Il programmatore B deve usare quella funzione, ma il nuovo caso d’uso è ‘quasi’ identico, ma non proprio. E allora cosa fa? Aggiunge un parametro. E un altro `if`. E una variabile booleana che controlla un flag che a sua volta dipende da una configurazione globale. In breve: trasforma un’astrazione elegante in un mostro di condizini incatenate che nessuno riesce più a debuggare senza piangere.

Qui scatta la trappola del ‘sunk cost fallacy’, ovvero la tendenza a non voler buttare via il lavoro già fatto perché ‘è troppo complesso per essere sbagliato’. È lo stesso ragionamento che usiamo quando continuiamo a guardare un film pessimo solo perché abbiamo già pagato il biglietto.

La soluzione di Sandi Metz, che è pura genialità tattica, è brutale: tornate indietro. Se l’astrazione è diventata un incubo di parametri e switch, smontatela. Inlineate il codice, riportatelo dove serve, duplicate la logica e cancellate le parti inutili. Non è una ritirata, è una manovra di riposizionamento strategico.

Sì, avrete codice duplicato. Sì, i vostri colleghi più puristi potrebbero guardarvi male. Ma avrete un codice che è facile da leggere, facile da modificare e, soprattutto, non esploderà alla prossima pull request. A volte, per andare avanti, l’unica strada è fare un passo indietro e accettare un po’ di ‘wasted effort’ pur di non finire intrappolati in un labirinto di astrazioni fallimentari.

E per chi vuole approfondire il design senza troppi drammi, è uscita la seconda edizione di ’99 Bottles of OOP’, disponibile ora in vari linguaggi tra cui JS, PHP e Ruby. Un piccolo consiglio per chi vuole smettere di creare mostri e iniziare a scrivere codice che non richieda un esorcista.

Source: Prefer duplication over the wrong abstraction (2016)

Quanto spesso vi è capitato di guardare un pezzo di codice HTML, magari un maledetto legacy scrap di un progetto iniziato tre anni fa, e sentirvi come davanti a un ammasso di spaghetti senza fine?

Siamo onesti: la maggior parte di noi, quando deve tirare su una pagina veloce per mostrare il nuovo prototipo di una CNC o un log di un esperimento con l’IA, usa i `