Per molti programmatori veder funzionare la propria applicazione rappresenta l'epilogo di ore e ore di lavoro. L'esecuzione del programma sembra diventare la parte essenziale del proprio operato. Eppure il funzionamento di un software dovrebbe considerarsi scontato, sarebbe come vedere una casa automobilistica esultare per ogni auto realizzata che riesce a mettersi in moto.
Nessuno acquisterebbe mai un sistema "difettoso" e di sicuro esso non sarebbe vendibile. Potremmo allora chiederci se il funzionamento di un programma rappresenti realmente l'obbiettivo principale di un programmatore, o se sia un motivo sufficiente per dichiarare il proprio lavoro completo.
Un buon programmatore dovrebbe pretendere che la sua applicazione non solo funzioni, ma che sia costruita su codice di qualità. Definire il concetto di qualità per un software non è cosa semplice, per ogni fase del ciclo di vita di un programma questo requisito diventa fondamentale e tra queste, sicuramente, vi è la parte relativa alla scrittura. Un codice di qualità significa ottenere un'implementazione più leggibile e comprensibile, più facile da modificare ed aggiornare, più semplice da testare, significa ridurre i tempi e i costi di testing (spesso lunghissimi e costosi).
I nemici della qualità
I principali "nemici" di un codice di qualità (ma non gli unici) sono:
Cloned code (codice clonato): sono porzioni di codice che si ripetono all'interno del programma ma che non fanno altro che servire i medesimi scopi. Tale errore nasce dalla tentazione di un programmatore di ricorrere al famoso "copia e incolla", oppure da una cattiva documentazione del codice che non permette di accorgersi che ciò che si sta scrivendo, in realtà, è già presente e può essere riutilizzato con metodi appropriati (es. ereditarietà).
Bug: sono errori presenti nel programma che possono pregiudicarne la corretta esecuzione eo la sicurezza. Tali errori sono legati a molte cause: dalla complessità del software da realizzare, all'esperienza e preparazione degli sviluppatori, alla fase di progettazione etc
Cattivo codice: sono porzioni di codice potenzialmente dannose, diversamente dai bug, quasi mai impediscono il corretto funzionamento del programma, ma ne pregiudicano fortemente la qualità e le performance. Sono principalmente legate all'inesperienza del programmatore e ad una errato approccio alla scrittura del codice.
Antipattern
Ciascuna delle classi sopra menzionate meriterebbe uno scrupoloso studio. In modo particolare negli ultimi anni l'attenzione dei "puristi" del codice si è focalizzata sull'individuazione ed eliminazione del cattivo codice a cui si fa riferimento utilizzando l'appellativo Antipattern (termine introdotto per la prima volta nel libro Design Patterns: Elementi per il riuso di software ad oggetti, 1995, Christopher Alexander).
L'espressione antipattern indica in senso generale una cattiva soluzione di progettazione ed implementazione che (purtroppo) può essere introdotta in ogni singola fase del ciclo di vita del software. In riferimento alla scrittura del codice, un antipattern è una trappola logica in cui un programmatore può incorrere. Esso rappresenta una vera e propria "zavorra" per il codice, non sempre semplice da individuare e da eliminare.
Com'è facilmente intuibile gli antipattern rappresentano i pericoli maggiori e più frequenti per la qualità del codice. È bene sottolineare, ancora, che gli antipattern non sono problematiche relative alla sola codifica ma anche ad altre importanti fasi: progetto, definizione dell'architettura e sviluppo
Antipattern nel Project management
Nello sviluppo di un software un ruolo essenziale è sicuramente d'attribuire alla comunicazione. La capacità di dialogo è fondamentale per la riuscita di qualsiasi progetto, basti pensare a quanto questa sia importante nella raccolta e analisi dei requisiti di un sistema. Le figure coinvolte in questa fase sono molteplici e riguardano ogni singolo aspetto dello sviluppo.
Un tipico antipattern relativo al project management è la "morte da pianificazione", essa si ha quando si segue in maniera maniacale un progetto iniziale partendo dal presupposto che sia perfetto ed indiscutibile, considerando superflui ulteriori confronti. Tale assenza di dialogo produce una errata visione del lavoro, sottovalutando eventuali rischi in cui si può incorrere o eventuali migliorie che invece sarebbe possibile inserire. Spesso questo antipattern porta a notevoli rallentamenti del lavoro o addirittura al suo arresto.
Antipattern nell'architettura del software
«L'architettura software è l'organizzazione che sta alla base di un sistema, delineata dai suoi componenti, dalle relazioni tra di loro e con l'ambiente, e i principi che ne guidano il progetto e l'evoluzione» (def. IEEE/ANSI 1471–2000).
Un tipico antipattern è il "reinventare la ruota", si ha quando su componente viene riprogettato da zero anche quando una sua realizzazione è già presente in un altro software precedentemente sviluppato. Questo comporta un aumento della mole di lavoro e un incremento dei tempi e dei costi di sviluppo.
Questo antipattern è spesso legato all'assenza di un progetto che ne delinei le caratteristiche, portando a pensare che esso sia unico, ma anche da una mancanza di volontà nell'analizzare e confrontare progetti già esistenti.
Antipattern nello sviluppo del software
È la parte che più da vicino interessa il programmatore poiché è relativa alla scrittura del codice. In questa fase è facile inserire involontariamente antipattern: un esempio tipico è il "blob". Esso non è altro che una classe con troppi compiti, sovraccarica di responsabilità, comunemente chiamata anche "classe di Dio".
Si incorre in questo antipattern quando vi è poca padronanza dei paradigmi della programmazione object-oriented e quando si crede, erroneamente, che quella particolare classe debba essere il cuore dell'intera applicazione. Le conseguenze sono quelle di creare un collo di bottiglia e realizzare del codice difficile da modificare e testare.
Definire gli antipattern
Vi sono diversi antipattern, per ognuno di essi le caratteristiche sono:
| Caratteristica | Descrizione |
|---|---|
| Nome | identificativo che permette di classificarlo |
| Descrizione | caratteristiche principali |
| Sintomi | elementi che permettono di riconoscerlo. Sebbene la loro identificazione non sia sempre facile e immediata, fortunatamente esistono delle "sentinelle" che ne permettono l'individuazione |
| Causa | fattori che ne comportano l'introduzione. Gli antipattern sono frutto, come già detto, di un errata soluzione a un problema, quindi la loro costruzione è legata a fattori ben precisi, che se analizzati correttamente permettono di arginare "l'inquinamento del codice" |
| Soluzioni | tecniche che ne permettono l'eliminazione. Lo studio verso questa particolare problematica relativa alla qualità del codice ha permesso l'introduzione di diverse tecniche atte all'eliminazione di antipattern. |
Tuttavia, per alcuni antipattern sono ammesse, più precisamente tollerate, delle eccezioni: situazioni in cui sembra inevitabile accettare una scomoda convivenza tra codice di qualità e cattivo codice.
Quindi per ogni antipattern analizzeremo il contesto, i sintomi, le cause, le conseguenze, i possibili rimedi e le eccezioni. In relazione alle eccezioni, cercheremo di soffermarci solo su quelle di natura tecnica e non su quelle di carattere economico, infatti, nel caso in cui l'eliminazione di un antipattern si rivelasse particolarmente onerosa, tale da non giustificare gli eventuali benefici di una sua rimozione, la decisione su come operare diventerebbe strettamente "soggettiva", svincolata da motivazioni tecniche.