{"id":34614,"date":"2025-12-01T13:46:05","date_gmt":"2025-12-01T12:46:05","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=34614"},"modified":"2025-12-01T13:46:07","modified_gmt":"2025-12-01T12:46:07","slug":"un-grande-programmatore-toglie-non-aggiunge","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/un-grande-programmatore-toglie-non-aggiunge\/","title":{"rendered":"Un grande programmatore toglie, non aggiunge"},"content":{"rendered":"\n

Scrivere software \u00e8 un atto che, in apparenza, chiunque pu\u00f2 compiere. Ci si siede, si accende un computer, si apre un IDE, un editor, VI se hai il cuore puro o qualsiasi altra cosa (s\u00ec, vale anche Notepad) e si inizia a digitare.<\/p>\n\n\n\n

Non servono nemmeno specifiche dettagliate: a cosa servono quando hai tutto in testa? A volte basta un’idea e la voglia di raggiungere un risultato. E qualcosa, inevitabilmente, accade.<\/p>\n\n\n\n

Il primo “Hello World” \u00e8 sempre un momento magico, ma \u00e8 solo l’inizio.<\/p>\n\n\n\n

Superato il primo ostacolo, si scopre che scrivere software \u00e8 un processo continuo di apprendimento e adattamento. Anche se all’inizio \u00e8 complicato, con il tempo si imparano i rudimenti: framework, librerie, design pattern. Si capisce come strutturare il codice, come modularizzarlo, come testarlo. E alla fine, dopo giorni o settimane di lavoro, si ottiene qualcosa che funziona\u2014magari non esattamente come l’avevamo in testa, ma funziona: e in quel momento \u00e8 un’esplosione di adrenalina e soddisfazione.<\/p>\n\n\n\n

Anche i pi\u00f9 pessimisti, quelli che fanno fatica a chiedere persino alla madre un bicchier d’acqua, dopo ore, giorni e settimane trovano sempre una soluzione.<\/p>\n\n\n\n

Un tempo c’erano gli amici, poi sono arrivati i forum. Oggi possiamo persino affidarci a un’intelligenza artificiale o a un agente: scriviamo la nostra idea, anche sgrammaticata, e inizia la magia.<\/p>\n\n\n\n

Ma oggi non voglio parlare di questo. Lasciamo stare per una volta l’aspetto romantico della programmazione, la credenza popolare che basti mettere le mani su una tastiera per fare cose incredibili, e non parliamo di come si costruisce il software o di come si arriva a un risultato\u2014il mondo \u00e8 pieno di corsi e manuali.<\/p>\n\n\n\n

Quello di cui vorrei parlare oggi \u00e8 uno degli aspetti pi\u00f9 complessi e meno discussi della programmazione: il coraggio di rimuovere del codice.<\/p>\n\n\n\n

La vera sfida non \u00e8 un programma che funziona<\/h2>\n\n\n\n

Il risultato \u00e8 solo il primo gradino della costruzione di un software. Qualsiasi programmatore, pi\u00f9 o meno convinto dei propri mezzi, dir\u00e0 sempre di poterci riuscire. Magari mentir\u00e0 un po’ sui tempi o sugli obiettivi reali, ma la sua risposta sar\u00e0 sempre: “Ce la faccio”. (Escludo da questo gruppo i pessimisti cronici che partono dicendo “\u00e8 impossibile”; quelli li scarteremo per praticit\u00e0).<\/p>\n\n\n\n

La vera sfida non \u00e8 quindi consegnare un programma funzionante. La vera sfida \u00e8 non farsi sopraffare dal proprio software: non perderne il controllo, non trasformare un banale servizio REST di 10 righe in un mostro mangia-disco (e parlo per esperienza personale).<\/p>\n\n\n

La crescita del software \u00e8 entropia e il lavoro del programmatore esperto \u00e8 combattere questa entropia.<\/code><\/span><\/pre>\n\n\n
Spesso il codice viene paragonato a un asset, quando in realt\u00e0 \u00e8 una liability. Se ragioniamo pensando che il codice che scriviamo sia un patrimonio, perdiamo l’aspetto pi\u00f9 fondamentale di tutto il processo di creazione: quando scriviamo del codice stiamo creando un debito. Ogni riga di codice deve essere letta, capita, mantenuta, testata e, un giorno, aggiornata o rimossa.<\/p>\n\n\n\n
Meno codice c’\u00e8, minore \u00e8 la superficie di attacco per i bug e minore \u00e8 il costo di manutenzione.<\/p>\n\n\n\n
Questa cosa viene spesso sottovalutata, specialmente in contesti aziendali dove il focus \u00e8 sul “consegnare funzionalit\u00e0” piuttosto che sul “mantenere un codice sano e gestibile”.<\/p>\n\n\n\n
Chi invece lavora per aziende di prodotto illuminate dovrebbe sapere quanto \u00e8 importante anche la manutenzione, la rimozione del codice obsoleto, la gestione delle dipendenze. Perch\u00e9 un software non \u00e8 mai “finito”. \u00c8 un organismo vivente che evolve, cresce, a volte si ammala. Quando manca questa visione, manca una progettualit\u00e0 che prima o poi porter\u00e0 inevitabilmente al collasso.<\/p>\n\n\n\n
Ho avuto la fortuna\/sfortuna di seguire entrambe le tipologie di progetti. Alcuni dove c’era un solo obiettivo: consegnare, e che col tempo sono implosi in tonnellate di codice scoordinato; altri in cui era normale fare refactoring continuo, rimuovere codice obsoleto e mantenere una base di codice pulita e mantenibile. La differenza tra i due mondi \u00e8 abissale.<\/p>\n\n\n\n
Siamo tutti accumulatori seriali<\/h2>\n\n\n\n
Avete presente il programma “Sepolti in casa”? Persone che accumulano oggetti inutili, riempiendo le loro case fino a renderle invivibili. Il software soffre della stessa patologia.<\/p>\n\n\n\n
Che lo scriviamo noi o, peggio, che lo faccia un’IA, il codice inizia ad aumentare di volume. Prima poche classi, poche funzioni e pochi script, ma col tempo ci troviamo inondati non solo di codice nostro, ma anche di dipendenze esterne, librerie, moduli, plugin. Ammetto che anche io sono finito pi\u00f9 volte in questo gorgo, dato che mi impongo che ogni repository che creo sia self-contained, con tutte le dipendenze necessarie per funzionare\u2014ho visto progetti bloccarsi per la mancanza di una singola libreria.<\/p>\n\n\n\n
I VibeCoder che mi leggeranno forse non mi capiranno ancora, ma col tempo si accorgeranno che le IA hanno un obiettivo solo: produrre codice funzionante e, se non lo \u00e8, autoconvincersi che lo sia.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
L’ultimo obiettivo di un’IA \u00e8 quello di ottimizzare il codice o ridurne la complessit\u00e0: questo aspetto non \u00e8 importante per loro ed \u00e8, ad ora, delegato completamente a noi umani. Se gli “umani” non si preoccupano del problema, men che meno se ne preoccuperanno le IA per noi.<\/p>\n\n\n\n
\u00c8 qui che il nostro ruolo cambia radicalmente. Le IA generative sono potenti “fabbriche di aggiunte”, capaci di scrivere migliaia di righe in pochi secondi. Questo sposta il ruolo dell’umano da “scrittore” a “editore” o “curatore”. La nostra abilit\u00e0 pi\u00f9 importante diventer\u00e0 la capacit\u00e0 di validare, semplificare e rifiutare il codice generato dall’IA, non solo di produrlo. Per questo \u00e8 importante dare una guida agli strumenti basati sul vibe: non basta dire “genera un CRM”, dobbiamo avere in testa l’architettura, le dipendenze, la manutenzione futura e di conseguenza spezzare tutto dando un boccone alla volta in pasto all’IA.<\/p>\n\n\n\n
Se volete rendervi conto se siete sul bordo del burrone o in caduta ormai libera, fate una prova: ispezionate la cartella node_modules<\/code> di un vostro progetto, o quelle create da Maven o NuGet. In un mio progetto abbastanza semplice ho 1 MB di codice mio e 20 MB di node_modules. La sensazione che mi sia scappato di mano \u00e8 molto alta e sono appena all’inizio del progetto.<\/p>\n\n\n\n
Vi siete mai chiesti: “Perch\u00e9 il mio ‘Hello World’ da tre righe richiede 200 MB di dipendenze?”? Se non l’avete mai fatto, fatelo. Scoprirete un mondo nuovo, spesso sottovalutato, che pu\u00f2 trasformare un progetto semplice in un incubo di manutenzione.<\/p>\n\n\n\n
Chattando con altri programmatori sento spesso frasi come questa:<\/p>\n\n\n
Non sono passato da Vue 2 a Vue 3 perch\u00e9 ho 18 dipendenze che non posso aggiornare senza riscrivere met\u00e0 del progetto.<\/code><\/span><\/pre>\n\n\n
Sembra una scusa, ma \u00e8 una realt\u00e0 con cui molti sviluppatori si confrontano quotidianamente.<\/p>\n\n\n\n
Le dipendenze spesso vengono prese sottogamba: accumuliamo una montagna di funzionalit\u00e0 senza una vera ragione. Si aggiunge, si aggiunge, e poi si aggiunge ancora. \u00c8 facile aggiungere una funzionalit\u00e0, specialmente se la richiesta arriva da un cliente o da un product manager. Ma raramente ci si ferma a chiedere: “\u00c8 davvero necessaria questa funzionalit\u00e0?” e soprattutto non si torna mai indietro.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Questo fenomeno ha un nome: feature creep.<\/p>\n\n\n\n
Feature Creep: il nemico silenzioso<\/h2>\n\n\n\n
La domanda che dobbiamo farci ogni giorno, quando vediamo una riga di codice ferma da anni, \u00e8: “\u00c8 davvero necessaria?”<\/p>\n\n\n\n
La risposta spesso \u00e8 “no”. Ma agire di fronte a quel “no” \u00e8 costoso. Spiegarlo a un cliente o a un product manager richiede una giustificazione tecnica e verbale solida, che pochi hanno il coraggio, o la forza, di sostenere.<\/p>\n\n\n\n
Il “feature creep” non \u00e8 solo un problema di codice, ma di prodotto. Un’interfaccia utente con troppi bottoni, opzioni e configurazioni soffre dello stesso problema. Il coraggio di “togliere” si applica anche al Product Manager che dice “no” a una nuova funzionalit\u00e0 per mantenere il prodotto focalizzato e semplice.<\/p>\n\n\n\n
Diffidate poi da chi vi dice:<\/p>\n\n\n
Il problema \u00e8 il tuo fat client, non le dipendenze che usi.<\/code><\/span><\/pre>\n\n\n
Questo \u00e8 solo un modo per distogliere l’attenzione dal vero problema: l’accumulo incontrollato di codice e dipendenze. Non \u00e8 che un’architettura abbia un vantaggio su un’altra\u2014il problema dell’accumulo seriale rimane lo stesso.<\/p>\n\n\n\n
Volendo proprio essere pignoli, un fat client potrebbe avere dei vantaggi rispetto a un thin client sezionato in N servizi, dato che rappresenta un unico punto di controllo, rispetto a verificare servizi che sono, virtualmente, utilizzati da un numero incontrollato di client\u2014ma questo \u00e8 un altro discorso.<\/p>\n\n\n\n
Le funzionalit\u00e0 superflue e le dipendenze fuori controllo complicano tutto. Il software diventa fragile, lento, difficile da mantenere. Il debito tecnico cresce in modo invisibile, finch\u00e9 non diventa impossibile ignorarlo.<\/p>\n\n\n\n
L’incubo della manutenzione<\/h2>\n\n\n\n
Finch\u00e9 siamo “con la testa sul progetto” e lavoriamo quotidianamente a feature e refactoring, abbiamo qualche probabilit\u00e0 aggiuntiva di riuscire a gestire il caos. Ma inevitabilmente, se quel progetto viene messo da parte e dopo mesi viene ripreso, o se il team varia molto, l’inevitabile deriva \u00e8 il caos e l’aumento del debito tecnico.<\/p>\n\n\n\n
Pi\u00f9 alto \u00e8 il numero di dipendenze importate, maggiore \u00e8 il problema dell’obsolescenza trasversale.<\/p>\n\n\n\n
Ma con “dipendenze” non pensiamo solo alla libreria X o Y che usiamo per fare il parsing di un file JSON. Pensiamo a tutto l’ecosistema: versioni di linguaggio, librerie, framework, toolchain, sistemi di build, ambienti di esecuzione e via dicendo.<\/p>\n\n\n\n
A volte si finisce in un cul-de-sac tecnico: l’aggiornamento che ci serve va in conflitto con un’altra libreria fondamentale, che non \u00e8 ancora stata aggiornata o il cui manutentore \u00e8 sparito nel nulla. Poco importa se \u00e8 open source\u2014anche questo \u00e8 un concetto sopravvalutato nello sviluppo software.<\/p>\n\n\n\n
A quel punto le scelte sono poche: riscrivere parti del software, accettare il buco di sicurezza, o lasciare tutto com’\u00e8, sperando che non crolli.<\/p>\n\n\n\n
\u00c8 facile dire “il mio software \u00e8 perfetto”. Pu\u00f2 essere vero per le righe che hai scritto tu\u2014anche se spesso sono solo bias\u2014ma non lo \u00e8 per l’ecosistema di componenti esterne su cui poggia.<\/p>\n\n\n\n
Perch\u00e9 non togliamo?<\/h2>\n\n\n\n
Ma perch\u00e9 non togliamo? Perch\u00e9 abbiamo paura. Paura di rompere qualcosa (“E se questo codice serviva a quel caso X che non ho testato?”).<\/p>\n\n\n\n
Per togliere con coraggio servono due cose fondamentali: sicurezza tecnica e psicologica, ma soprattutto la volont\u00e0 di farlo.<\/p>\n\n\n\n
Serve anche una cultura aziendale che premi la sottrazione.<\/p>\n\n\n\n
In molte aziende, la produttivit\u00e0 \u00e8 misurata in “funzionalit\u00e0 consegnate” o “ticket chiusi”. Ma quante volte un programmatore viene lodato per aver rimosso 1000 righe di codice obsoleto? Una “Pull Request” con -1000 righe dovrebbe essere celebrata. Serve una cultura che veda il refactoring e la pulizia non come “lavori di casa”, ma come parte integrante e nobile del processo di sviluppo.<\/p>\n\n\n\n
Il coraggio di togliere<\/h2>\n\n\n\n
I veri programmatori sono quelli capaci di ridurre.<\/p>\n\n\n\n
Ken Thompson, co-creatore di Unix e del linguaggio C, disse una volta:<\/p>\n\n\n
Uno dei miei giorni pi\u00f9 produttivi \u00e8 stato eliminare 1000 righe di codice.<\/code><\/span><\/pre>\n\n\n
Non so quanto questa affermazione sia vera, ma il concetto \u00e8 potente. La vera maestria non sta nell’aggiungere, ma nel saper togliere senza perdere funzionalit\u00e0.<\/p>\n\n\n\n
C’\u00e8 anche una frase famosa di Tony Hoare, l’inventore di Quicksort:<\/p>\n\n\n
Ci sono due modi per progettare software: uno \u00e8 renderlo cos\u00ec semplice che non ci siano palesemente difetti, l'altro \u00e8 renderlo cos\u00ec complicato che non ci siano palesi difetti. Il primo metodo \u00e8 molto pi\u00f9 difficile.<\/code><\/span><\/pre>\n\n\n
Come dargli torto? Del resto, la sua laurea in lettere, precedente alla carriera informatica, gli dava forse una marcia in pi\u00f9 nel comprendere l’eleganza della semplicit\u00e0.<\/p>\n\n\n\n
Ma visto che non esistono rose senza spine, oltre a questa perla, Hoare ci ha lasciato anche una delle pi\u00f9 grandi tragedie dell’informatica moderna: il concetto di “NULL POINTER”. Se vi ha mai rovinato una giornata, ora sapete chi ringraziare.<\/p>\n\n\n\n
Only the brave remove stuff<\/h2>\n\n\n\n
Ma torniamo a noi. Come si fa, concretamente, a togliere?<\/p>\n\n\n\n
Il primo passo \u00e8 rimuovere il codice inutile. Sembra facile, ma \u00e8 qui che scattano le resistenze, sia strutturali che umane. Per vincere questa battaglia servono armi adeguate:<\/p>\n\n\n\n