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)