Nel nostro precedente articolo "Antipattern nello sviluppo software", abbiamo già dato definito cosa sia un antipattern, ovvero:

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 ancora una volta 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”.

Altri esempi di antipattern nello sviluppo software

Il numero di antipattern identificati dalla ricerca accademica sul settore è molto ampio e alcuni sono già stati affrontati nella prima parte; siccome la trattazione non è stata ovviamente esaustiva, ci sono altri antipattern molto frequenti che vale la pena esplorare.

Hard coding

L'espressione "hard coding" indica la pratica di inserire variabili ed elementi di configurazione direttamente all’interno del codice.

Apparentemente comodo, ma ogni modifica richiede di ricompilare e rilasciare nuovamente l’applicativo.

Best practice ovviamente è inserire tali variabili in un database o in un file di configurazione.

Poltergeist class

Le "classi poltergeist" sono classi che esistono unicamente per richiamare altre classi.

Possono essere il risultato di una fase di design fatta in maniera non ottimale, di una mancanza di direzionalità di un progetto, oppure di un refactoring non completo.

La best practice è di eliminare queste classi superflue.

Spaghetti code & Ravioli code

Proprio come un piatto di spaghetti impiattato male, il "codice spaghetti" è codice scritto in maniera frammentaria e confusionaria, a causa di mancanza di linee guida, modifiche senza progettazione adeguata, frequenti modifiche dovute a patch veloci, mancata comunicazione all’interno del team di sviluppo…

Il risultato è codice di difficile comprensione, che in caso di riscrittura viene spesso inserito in un wrapper.

Rimanendo nella metafora gastronomica, la versione OOP di questo antipattern si dice "Ravioli code", ovvero un codice frammentato in troppe classi senza struttura precisa.

Lava flow

‍Il "flusso di lava" è un codice non completo o non correttamente testato che viene immesso in produzione prima del dovuto.

Questo codice tende poi a diventare la base per altro codice o altri servizi, causando un’instabilità di base della piattaforma che è difficile andare a correggere.

Come best practice, progettazione adeguata e refactoring frequente aiutano a evitare questo antipattern.

Dependency hell

Il termine "Dependency hell" indica un progetto che ha chiari problemi di dipendenze (dipendenze circolari, catene di dipendenze troppo lunghe, …), le quali rendono difficile risalire ai problemi quando si manifestano; in ambiente Windows si parla anche di DLHell.

L’utilizzo di package manager per risolvere le dipendenze e la scomposizione in microservizi possono alleviare questo problema.

Broken windows

Simile alla teoria sociologia della finestra rotta, questo antipattern è riferito all’incuria nella scrittura del codice, comprende ad esempio gli errori di spelling delle variabili, nomi non pertinenti di funzioni, indentazioni errate, muri di commenti e così via.

Esattamente come le finestre rotte in una casa denotano abbandono e permettono di far entrare qualsiasi tipo di intemperia, questo codice denota poca cura del progetto e genera un rapido degrado dell’applicativo.

Analysis paralysis

La situazione di "Analysis paralysis" si verifica in software la cui fase di progettazione rimane in un limbo da cui non si esce mai veramente.

Le cause sono molte, da una progettazione troppo attenta ai requisiti alla mancanza di una project leadership ben definita.

Spesso porta a definire deadline arbitrarie per i rilasci che degenerano in crunch del team di sviluppo e in ultima analisi creano disservizi agli utenti.

Chiaramente, la soluzione è adottare un approccio realistico e iterativo alla progettazione.

Walking through a minefield

Camminare attraverso un campo minato è letteralmente il risultato finale di tutto quanto è stato citato: il software sembrerà un campo minato a sviluppatori e utenti, dove un passo falso può portare a esiti molto spiacevoli.

La summa di tutti gli antipattern precedenti è che i project manager non vorranno apportare cambiamenti, gli sviluppatori avranno timore nel fare modifiche, gli utenti non saranno incentivati a utilizzare il software a causa dei frequenti problemi.

Per approfondire

Quelli presentati sono solo alcuni degli antipattern più frequenti, ma la trattazione può sicuramente essere approfondita. Per concludere questa breve carrellata suggerisco altri tre libri per ulteriori spunti sull’argomento:

• Antipatterns: Managing Software Organizations and People, Second Edition (C. Neill, P. Laplante, J. DeFranco, 2011)
• AntiPatterns in Project Management (W. Brown, S. McCormick, S. Thomas, 2000)
• Software Development Patterns and Antipatterns (C. Jones, 2021)

‍