Antipattern nello sviluppo software: altri errori da evitare

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.

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.

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.

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.

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.

‍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.

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.

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.

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.

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.

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: