Principio DRY: come evitare duplicazioni nel codice

Immagina di lavorare su una piattaforma che permette la registrazione solo agli utenti maggiorenni.

Il frontend controlla che l’età sia almeno 18 anni. Il backend fa la stessa verifica. Un vecchio script di importazione contiene ancora quel valore. Da qualche parte esiste probabilmente anche un test scritto durante il Paleolitico del repository.

Poi arriva il nuovo requisito: la soglia cambia.

Aggiorni il frontend, modifichi il backend e mandi tutto in produzione. Lo script, naturalmente, rimane a 18.

Congratulazioni: il sistema ora possiede due versioni della realtà.

È esattamente il tipo di problema affrontato dal principio DRY.

Cosa significa DRY

DRY sta per Don’t Repeat Yourself.

La formulazione originale arriva da The Pragmatic Programmer: ogni conoscenza rilevante dovrebbe avere una rappresentazione unica, chiara e autorevole all’interno del sistema.

La parola importante è conoscenza.

Dentro un software, la conoscenza può essere:

• una regola di business;
• una formula;
• una soglia;
• il formato di un dato;
• un contratto API;
• una configurazione;
• una procedura di validazione.

Quando la stessa informazione viene mantenuta manualmente in più punti, ogni modifica diventa un piccolo esercizio di memoria distribuita.

E la memoria umana, come dependency di produzione, ha SLA discutibili.

La duplicazione va cercata nel significato

Il copia e incolla è il caso più evidente. Basta una ricerca nel repository e spesso salta fuori.

La duplicazione più interessante si nasconde dietro codice scritto in modi diversi.

Il frontend potrebbe contenere:

Il backend:

Lo script di importazione:

Le righe hanno forme diverse. Tutte esprimono la stessa decisione: quale età permette la registrazione.

Una possibile fonte potrebbe vivere nel dominio:

Il backend continua a validare la richiesta. Il frontend può ricevere la soglia tramite API e offrire un feedback immediato. Ogni livello conserva la propria responsabilità, mentre la regola ha un’origine riconoscibile.

Il prossimo cambiamento richiede un intervento preciso, senza trasformare Ctrl + Shift + F in una strategia architetturale.

Dare un nome alle cose aiuta

DRY produce un altro effetto utile: costringe a nominare le decisioni.

Questo codice:

ci dice che esiste un limite. Fine delle informazioni disponibili.

Questo:

spiega subito quale comportamento dipende da quel valore.

Un’astrazione utile conserva il significato e lo rende più visibile. Sei mesi dopo, chi apre il file capisce se 100 rappresenta euro, punti fedeltà o gli HP del boss finale.

Qui si vede la differenza tra spostare del codice e modellare una regola.

Attenzione alle astrazioni create troppo presto

DRY può diventare pericoloso quando viene applicato a qualsiasi somiglianza.

Consideriamo due funzioni:

Oggi contengono la stessa verifica.

Tra qualche mese, i pagamenti potrebbero accettare una data passata per gestire una riconciliazione contabile. Le scadenze dei task potrebbero mantenere la regola attuale.

Un generico DeadlineManager legherebbe due concetti con cause di cambiamento differenti. La relazione nasce da poche righe simili e finisce con una classe piena di flag:

A quel punto il repository sta cercando di comunicarci qualcosa.

Prima di estrarre codice, chiediti:

1. Questi punti rappresentano la stessa regola?
2. Cambiano per lo stesso motivo?
3. Esiste un termine di dominio che li descrive entrambi?
4. L’astrazione rende il codice più facile da capire?

Quattro “sì” sono un buon segnale. Con risposte vaghe, qualche riga duplicata può aspettare il prossimo refactoring.

DRY tra frontend, backend e API

Nei sistemi reali, una funzione condivisa non può raggiungere ogni componente.

Frontend e backend possono usare linguaggi diversi. Un’app mobile deve supportare versioni precedenti delle API. I servizi possono essere distribuiti in momenti separati.

In questi casi, la fonte autorevole può essere un contratto.

Una specifica OpenAPI, per esempio, può descrivere l’interfaccia di un servizio e alimentare documentazione, client, server e strumenti di test. Le rappresentazioni generate sono molte, mentre la definizione da mantenere rimane una.

Lo stesso approccio funziona con:

• JSON Schema;
• tipi generati;
• configurazioni versionate;
• definizioni dei messaggi;
• modelli condivisi tra servizi.

DRY riguarda il percorso della conoscenza: una fonte, più utilizzi coerenti.

E con il codice generato dall’AI?

Un coding agent può individuare una policy già presente nel repository e riutilizzarla.

Può anche trovare tre implementazioni della stessa regola e aggiungerne una quarta con grande sicurezza, test verdi e naming convincente.

Gli strumenti AI amplificano la struttura che incontrano. Un repository ordinato offre punti di riferimento chiari. Un repository ambiguo produce ambiguità a velocità maggiore.

File come AGENTS.md o le custom instructions di GitHub Copilot possono indicare criteri precisi:

Queste istruzioni aiutano l’agente, ma anche il junior developer che sta cercando di capire dove vive una regola.

Un buon contesto è documentazione eseguibile per umani e macchine.

La domanda giusta da portarsi dietro

Applicare DRY richiede di riconoscere quali informazioni devono restare coerenti mentre il software cambia.

Quando trovi due blocchi simili, osserva il significato. Quando trovi la stessa decisione in più punti, cerca una fonte autorevole. Quando l’astrazione inizia ad accumulare eccezioni, controlla di non aver unito concetti destinati a prendere strade diverse.

Il vantaggio emerge durante il prossimo requisito “veloce veloce”.

Con una fonte chiara cambi una regola. Con quattro copie inizi una side quest.

Poi scegli tu!