Nel campo del dibattito accademico sullo sviluppo e la progettazione del software, quello degli antipattern è sicuramente uno dei campi che attualmente vanta le più vivaci discussioni e anche le applicazioni più concrete. In questo articolo, vedremo quali sono gli antipattern più comuni e come riconoscerli (ed evitarli) nell'ambito dello sviluppo e progettazione di software

Cos'è un anti-pattern

Ma cosa intendiamo come "antipattern"?

Utilizzando il metodo socratico, potremmo innanzitutto chiederci che cosa è un pattern.

Utilizzando la definizione data dalla Treccani potremmo rispondere:

“un sistema consolidato di convinzioni, comportamenti, valori”

in definitiva una serie di regole che ci siamo dati e che riteniamo vantaggiose per svolgere un determinato compito.

Per opposizione, quindi, un anti-pattern è una “regola” di progettazione o scrittura del codice che riteniamo vantaggiosa, ma che all’atto pratico genera frequenti problemi applicativi, peggiora l’usabilità del software e ne rende il ciclo di vita di difficile gestione.

Citando il ricercatore inglese Martin Fowler:

“Chiunque può scrivere codice che un computer può comprendere, un buon programmatore scrive codice che un essere umano può comprendere"

La ricerca sugli antipattern

La ricerca sugli antipattern si è sviluppata a partire dagli anni ’90, quando il software ha iniziato a diventare uno strumento indispensabile nella vita di tutti i giorni, le codebase hanno iniziato a ingrandirsi e il numero di persone che collaborano su di esse ha iniziato a diventare importante e il personale suddiviso in sedi diverse anche geograficamente.

A partire da questo momento storico, si è reso necessario identificare le “worst practices” che avvengono normalmente nella fase di sviluppo di un applicativo e codificare una serie di best practices per rendere il codice prodotto elegante, fruibile da tutti gli sviluppatori e robusto.

Esempi di antipattern

Gli antipattern individuati sono un gran numero e spaziano su tutto lo spettro del management e dell’ingegnerizzazione del software: si va dagli antipattern sullo stile di management del progetto, sulla produzione del software, sulla gestione del personale, e ovviamente sullo sviluppo del codice, parte sulla quale forniremo alcuni esempi

Antipattern nello sviluppo software

Magic Number/Strings

L'antipattern "Magic Number" (o "Magic Strings") identifica la pratica di inserire numeri o stringhe nel codice senza una rappresentazione mnemonica o senza essere identificato correttamente.

Ad esempio, la riga x = y / 0.9144 ci risulterebbe piuttosto incomprensibile se non commentata, mentre invece dichiarare una costante CNST_YARDS = 0.9144 e scrivere x = y / CNST_YARDS ci aiuterebbe a capire che sta avvenendo una conversione dal sistema metrico a quello imperiale.

Copypaste programming

Il "Copypaste programming" fa riferimento alla pratica di copiare più volte codice con poche o addirittura nessuna modifica all’interno del programma.

All'opposto, la best practice è quella di ispirarsi al principio OOO (Once and Only Once) e creare una funzione per ogni metodo che è necessario riutilizzare.

Cargo cult programming

Cugino del precedente, l'antipattern noto come "Cargo cult programming" è la pratica di copiare codice da fonti varie (es. StackOverflow, ChatGPT…) senza comprendere realmente cosa faccia. Inevitabilmente, ogni modifica o verifica su questo codice è impossibile.

Una curiosità: il termine "Cargo cult" deriva dalle religioni aborigene cresciute nel Pacifico meridionale dopo la seconda guerra mondiale, dove alcune popolazioni locali avevano sviluppato pratiche rituali legate alla costruzione di simulacri di aerei e piste di atterraggio nella speranza di evocare come esseri divini gli aerei militari e i loro carichi arrivati durante la guerra.

Più precisamente, la metafora della "Cargo Cult Science" in riferimento alle pseudoscienze è stata popolarizzata dal fisico e divulgatore scientifico Richard Feynman nel suo commencement address al California Institute of Technology nel 1974:

“In the South Seas there is a Cargo Cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas - he’s the controller - and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land.”
(fonte: Caltech’s 1974 commencement address)

Input kludge

Letteralmente “accrocchio in ingresso”, l'antipattern "Input Kludge" è la pratica di non validare correttamente gli input in base a quanto presente nelle specifiche.

Specialmente nei sistemi con molti utenti, la validazione degli input è una pratica vitale, perché gli utenti troveranno sempre il modo di “rompere” gli applicativi in modi non previsti; per evitarlo, è bene sempre controllare e "sanificare" gli input del programma.

Coding by exception

La pratica di "codificare per eccezioni" è particolarmente insidiosa perché se tutto diventa un‘eccezione, nulla è un’eccezione.

Il risultato dà l’idea di un software robusto, che è sempre up and running, ma è in realtà prono a errori e malfunzionamenti spesso indecifrabili, in quanto in un mare di eccezioni risulta estremamente difficile capire quale sia quella che ha causato il problema.

Error hiding

Il termine "Error hiding" indica la pratica di non mostrare un messaggio adeguato all’utente quando avviene un errore o di non mostrarne alcuno.

Questo è tipicamente fonte di frustrazione per l’utente, che genererà contatti in assistenza in quanto non ha idea di quale sia l’operazione errata che ha compiuto, ma anche per lo sviluppatore, che non ha idea di dove iniziare a cercare il problema.

Not invented here & Reinventing the wheel

L'antipattern "Not invented here" identifica la pratica di riscrivere una soluzione esistente solo perché non fatta in-house.

Un parente stretto è "Reinventing the wheel", ovvero la pratica di riscrivere da zero una soluzione esistente e testata pensando di poter fare di meglio. Oltretutto, ottenendo invece molto spesso risultati peggiori, caso in cui si parla di "reinventing the square wheel"

God object

Il cosiddetto "God object" è un costrutto globale con troppe responsabilità e troppa visibilità all’interno del programma.

Apparentemente comodo, alla lunga diventa pervasivo, e ogni modifica si ripercuote anche in punti che dovrebbero essere non correlati, senza contare che il codice diventa interamente dipendente da un oggetto solo.

Gli effetti negativi degli antipattern

È essenziale riconoscere ed evitare gli antipattern nello sviluppo di un applicativo perché possono portare a diverse conseguenze negative sul prodotto finale e non solo, come per esempio:

• Adozione di soluzioni inefficienti o inefficaci ai problemi
• Aumento della complessità e dei costi di manutenzione
• Diminuzione della leggibilità e della comprensibilità del codice
• Diminuzione della produttività e del morale del team

Per approfondire

Per concludere la prima parte di questa trattazione, possiamo suggerire tre letture per approfondire il tema:

• AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (W. Brown, R. Malveau, S. McCormick, T. Mowbray, 1998)
• Refactoring: Improving the Design of Existing Code, Second Edition (M. Fowler, K. Beck, 2018)
• Antipatterns: Identification, Refactoring and Management (P. Laplante, C. Neill, 2005)

‍