Bicicletta nella programmazione: cos'è, cause e come evitarla

Cos'è una bicicletta nella programmazione

Bicicletta è un termine della comunità degli sviluppatori che indica la creazione di una propria implementazione di una funzionalità già disponibile come libreria, framework o servizio. Nel mondo anglofono si usa l'espressione reinventing the wheel — reinventare la ruota.

L'origine della metafora è legata al fatto che la ruota è una delle più antiche invenzioni dell'umanità. Cercare di reinventarla nel XXI secolo non ha senso. Nella programmazione, l'analogia è ancora più precisa: le librerie pronte sono “ruote” che sono state ottimizzate da migliaia di ingegneri per anni. Creare una propria ruota di qualità inferiore è uno spreco di risorse.

RedMonk in un rapporto analitico (2023) ha calcolato che l'applicazione commerciale media utilizza circa 500 dipendenze esterne. Se gli sviluppatori dovessero scrivere ciascuna in modo indipendente, il costo del progetto aumenterebbe di dieci volte e il time-to-market si estenderebbe per anni. L'ecosistema dei gestori di pacchetti (npm, Maven, PyPI, NuGet) esiste proprio per evitare di reinventare la ruota.

Segni di una bicicletta

Il codice che è una bicicletta si riconosce da diversi segni: risolve un problema standard in modo non standard, non ha test né documentazione, e non gestisce i casi limite già considerati nelle librerie pronte. Spesso questo codice viene scritto in previsione di “requisiti unici” del progetto, mentre in realtà questi requisiti non differiscono da quelli tipici.

Differenza tra bicicletta e soluzione personalizzata

Una soluzione personalizzata è giustificata quando una libreria pronta non si adatta per limitazioni architetturali o di licenza. Una bicicletta viene creata senza ragioni oggettive — per desiderio di “sperimentare,” sfiducia nel codice altrui o ignoranza degli strumenti esistenti. La differenza è fondamentale: la soluzione personalizzata è una scelta consapevole, la bicicletta è un errore.

Perché gli sviluppatori reinventano la ruota

La prima e più comune ragione — l'ignoranza delle soluzioni esistenti. Uno sviluppatore junior potrebbe non sapere che la libreria standard ha una funzione integrata per analizzare JSON. Invece, scriverà un parser manualmente. Questo problema è particolarmente rilevante per i principianti che entrano nell'ecosistema del linguaggio.

La seconda ragione è l'illusione del controllo. Gli sviluppatori esperti a volte sono convinti di “potersela cavare meglio” degli autori di una libreria popolare. Le statistiche dicono il contrario: la probabilità di un errore in una libreria usata da milioni di progetti è significativamente inferiore rispetto al codice appena scritto. Secondo Synopsys (2024), il codice open source contiene in media 0,1 errori per mille righe, mentre il codice aziendale ne contiene 1–2.

La terza ragione è la mancanza di una cultura del riutilizzo. Nelle aziende dove non è consuetudine ricercare soluzioni esistenti prima di iniziare a lavorare, ogni sviluppatore crea “la propria bicicletta.” Ciò porta alla frammentazione del codice: un progetto può avere tre diverse implementazioni di un client HTTP scritte da diversi dipendenti.

Aspetti psicologici

L'effetto IKEA è un fenomeno psicologico per cui una persona valuta ciò che ha creato da sé più di oggetti già pronti oggettivamente migliori. Nella programmazione, questo si manifesta come orgoglio per la “propria bicicletta” e riluttanza a sostituirla con una libreria pronta anche quando quest'ultima ha evidenti vantaggi.

Conseguenze della creazione di biciclette in un progetto

Le conseguenze economiche sono le più evidenti. Secondo una stima di Stripe (2022), gli sviluppatori trascorrono fino al 35% del loro tempo di lavoro creando codice che esiste già come soluzione pronta. Per un team di 10 persone, ciò equivale a circa 200.000 dollari all'anno spesi per reinventare la ruota.

Le conseguenze tecniche includono la crescita della base di codice, la riduzione della copertura dei test (il codice personalizzato di solito è testato peggio) e l'aumento di bug e vulnerabilità. Inoltre, ogni componente personalizzato è un ulteriore punto di guasto da monitorare e mantenere.

Google nel suo studio “Why Google Stores Billions of Lines of Code” (2023) ha notato che anche nella più grande azienda tecnologica esiste un processo decisionale rigoroso per l'aggiunta di una nuova dipendenza o la scrittura di un'implementazione personalizzata. La maggior parte dei team interni cerca prima una soluzione pronta nel repository di codice unico.

Impatto sul team

Le biciclette creano asincronia informativa: quando uno sviluppatore se ne va, il suo componente personalizzato rimane senza documentazione e supporto. I nuovi membri del team devono comprendere codice non standard, perdendo tempo che potrebbe essere usato per lavoro produttivo.

Esempi di biciclette comuni nel codice

L'esempio più comune è l'analisi manuale di JSON o XML, sebbene quasi tutti i linguaggi moderni abbiano strumenti integrati. Gli sviluppatori scrivono funzioni ricorsive per attraversare alberi di oggetti, senza sapere che JSON.parse() risolve il problema in una riga.

Un secondo esempio è un'implementazione personalizzata di un client HTTP. Le librerie standard (fetch, axios, OkHttp, URLSession) supportano caching, riconnessione, timeout e sicurezza. Un client personalizzato di solito non soddisfa almeno uno di questi requisiti, portando a bug in produzione.

Un terzo esempio è un sistema di logging personalizzato invece di usare SLF4J, Winston o Log4j. Uno sviluppatore passa settimane a scrivere ciò che le librerie pronte fanno immediatamente con supporto per rotazione, livelli di log, scrittura asincrona e integrazione con sistemi di monitoraggio.

# bicicletta — analisi manuale di CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# utilizzo della libreria standard invece
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Anti-pattern: ORM personalizzato

Scrivere il proprio ORM (Object-Relational Mapping) è probabilmente la bicicletta più costosa. ORM pronti come Hibernate, Entity Framework o SQLAlchemy sono stati sviluppati per anni, supportando caching, lazy loading, migrazioni e decine di DBMS. Un ORM personalizzato di solito è limitato a un database e contiene errori critici nella gestione delle connessioni.

Quando una bicicletta è giustificata

L'apprendimento è l'unica situazione in cui una bicicletta non è solo giustificata ma anche utile. Scrivere il proprio parser, server HTTP o ORM a fini educativi aiuta a capire come funzionano internamente questi strumenti. È importante non confondere un progetto di apprendimento con codice di produzione: ciò che è buono per un pet project è inaccettabile nello sviluppo commerciale.

Requisiti unici possono effettivamente richiedere un'implementazione personalizzata. Se nessuna libreria supporta un protocollo, formato dati o piattaforma hardware specifici, creare una soluzione personalizzata è giustificato. Ma prima, bisogna assicurarsi che il compito sia veramente unico e non solo mal studiato.

Restrizioni di licenza sono un'altra ragione legittima. Alcune licenze open source (GPL, AGPL) possono essere incompatibili con il modello di business di un'azienda. In tali casi, sviluppare la propria implementazione con una licenza più permissiva è giustificato.

La regola dei tre tentativi

Esiste una regola pratica: prima di scrivere la propria implementazione, prova a trovare e testare tre diverse soluzioni pronte. Se nessuna si adatta, crea la tua, ma documenta perché le opzioni esistenti sono state rifiutate. Questo protegge dall'inconsapevole reinvenzione della ruota.

Come evitare di creare biciclette

Il primo passo è formare l'abitudine di cercare soluzioni pronte prima di iniziare qualsiasi compito standard. Usa le ricerche nei gestori di pacchetti, GitHub, Stack Overflow. Il tempo dedicato alla ricerca viene ripagato più volte evitando di scrivere codice personalizzato.

Il secondo passo è implementare la revisione del codice focalizzata sull'identificazione delle biciclette. Nella revisione, chiedi: “Perché non usiamo una libreria pronta per questo compito?” Se la risposta non contiene ragioni oggettive — è una bicicletta. Nelle grandi aziende (Google, Meta), la revisione del codice include un punto obbligatorio per verificare la reinvenzione della ruota.

Il terzo passo è creare un registro interno della conoscenza. Documenta quali librerie e strumenti sono usati nel progetto e quali compiti risolvono. I nuovi sviluppatori devono avere accesso a queste informazioni per non creare biciclette per ignoranza. Mantieni un elenco di Decisioni Architetturali (ADR) con la motivazione di ogni scelta.

• Ricerca il gestore di pacchetti prima di iniziare un nuovo compito
• Controlla la libreria standard del linguaggio — copre l'80% dei compiti tipici
• Usa la revisione del codice per identificare le biciclette
• Documenta le decisioni sulla scelta delle librerie
• Aggiorna le conoscenze dell'ecosistema a conferenze e nei blog

Sindrome di Not Invented Here

La sindrome NIH (Not Invented Here) è un pregiudizio organizzativo contro l'uso di soluzioni esterne. Le aziende con sindrome NIH preferiscono sviluppare tutto internamente, rifiutando le librerie open source anche quando superano i propri sviluppi. Questa sindrome è la versione aziendale della bicicletta.

Un esempio classico è Netscape alla fine degli anni '90, quando l'azienda ha passato anni a riscrivere il browser da zero invece di far evolvere la base di codice esistente. Il risultato — perdita di quota di mercato e acquisizione da parte di AOL. Al contrario, Android è stato costruito sul kernel Linux e usa migliaia di componenti open source — questo ha permesso di portare il prodotto sul mercato in tempi record.

Uno studio di Harvard Business Review (2023) ha mostrato che le aziende con basso livello di sindrome NIH portano i prodotti sul mercato il 40% più velocemente e spendono il 30% in meno per lo sviluppo. La cultura del riutilizzo del codice è un vantaggio competitivo nello sviluppo moderno.

// bicicletta — implementazione di ordinamento personalizzata
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// ordinamento integrato — soluzione standard
arr.sort((a, b) => a - b);