Anti-pattern: differenze tra le versioni

Versione delle 16:58, 5 giu 2024

Versione attuale delle 09:27, 5 gen 2025

(3 versioni intermedie di 3 utenti non mostrate)

Riga 1:

In [[informatica]], in particolare nell'[[ingegneria del software]], gli '''anti-pattern''' (o antipattern) sono dei ''[[design pattern]]'', o, più in generale, delle procedure o modi di fare, usati durante il processo di sviluppo del software che, pur essendo lecitamente utilizzabili, si rivelano successivamente inadatti o controproduttivi nella pratica<ref>{{Cita libro|autore=Ambler, Scott W.|titolo=Process patterns: building large-scale systems using object technology|anno=1998|p=4|citazione=...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns.|ISBN=ISBN 0-521-64568-9}}</ref><ref>{{Cita libro|autore=Budgen, D.|titolo=Software design|url=https://books.google.com/books?id=bnY3vb606bAC&q=%22anti-pattern%22+date:1990-2003&pg=PA225|anno=2003|p=225|citazione=As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'.|ISBN=0-201-72219-4}}</ref>. Il termine fu coniato nel 1995 da Andrew Koenig, ispirato dal libro ''[[Design Patterns|Design Patterns: Elementi per il riuso di software ad oggetti]]'' scritto dalla [[Gang of Four (scrittori)|Gang of Four]] (la banda dei quattro), i quali svilupparono il concetto di pattern nel campo del software.

Fu, tuttavia, il libro ''AntiPatterns'' del 1998 a rendere popolare l'idea e ad ampliarne l'ambito oltre il campo del design del software, includendo anche l'architettura software e la gestione dei progetti<ref name=":0">{{Cita libro|nome=Colin J.|cognome=Neill|nome2=Phillip A.|cognome2=Laplante|nome3=Joanna F.|cognome3=DeFranco|titolo=Antipatterns: managing software organizations and people|edizione=2nd ed (Online-Ausg.)|collana=Applied software engineering series|data=2012|editore=CRC Press/Auerbach Publications|pp=4-5-6|ISBN=978-1-4398-6216-2}}</ref>. Successivamente, altri autori hanno ulteriormente esteso il concetto per abbracciare antipattern ambientali, organizzativi e culturali<ref name=":0" />.

Secondo l'autore, devono presentarsi almeno due elementi chiave per poter distinguere un anti-pattern da un semplice errore logico o cattiva pratica:

== Definizione ==

Secondo l'autoregli autori, devono presentarsi almeno due elementi chiave per poter distinguere un anti-pattern da un semplice errore logico o cattiva praticaabitudine:

* Qualche schema ricorrente di azioni, processi o strutture che inizialmente appaiono essere di beneficio, ma successivamente producono più problemi che benefici.

* L'esistenza di una soluzione alternativa che è chiaramente documentata, collaudata nella pratica e ripetibile, ma che non viene adottata.

Molti anti-pattern sono poco più che errori, problemi irrisolvibili o cattive pratiche da evitare quando possibile. A volte chiamati "pitfalls" (tranelli) o ''[[dark pattern]]'' (modelli oscuri) se invece sono volutamente ingannevoli, si riferiscono a classi di soluzioni di problemi reinventate in modo sbagliato.

Una guida comunemente utilizzata è la "regola del tre," simile a quella per i pattern: per essere considerato un antipattern, deve essere stato osservato almeno tre volte.<ref name=":0" />

== Uso ==

Per prevenire errori che tendono a ripetersi, si può individuare la frequenza con la quale questi si ripetono, e imparare come altre persone hanno rimediato a questi cattivi pattern.

Documentare gli antipattern può essere un metodo efficace per analizzare un ambito problematico e raccogliere conoscenze esperte.<ref>{{Cita pubblicazione|autore=Edward Jimenez|anno=2006|mese=04|titolo=AntiPatterns|url=http://antipatterns.com/EdJs_Paper/Antipatterns.html}}</ref>

Sebbene alcune descrizioni di antipattern si limitino a documentare le conseguenze negative del pattern, una buona documentazione di un antipattern fornisce anche un'alternativa o un modo per attenuarlo.

== Gli anti-pattern più comuni ==

Riga 13 ⟶ 23:

'''Organizzativi'''

* Progettazione orientata alla commissione (''(Designdesign by committee''): presenza di molte persone che contribuiscono a una progettazione, ma mancanza di una visione globale condivisa

* Corpi tiepidi (''warm bodies''): aggiungere a un progetto nuovi programmatori che non riusciranno a fare quasi nulla per mancanza di esperienza su di esso

* Paralisi da analisi (''analysis paralysis''): progetto fermo nella fase di analisi, ad esempio perché si sta vagliando un ventaglio di soluzioni troppo ampio senza riuscire a sceglierne una, o perché la si sta dettagliando eccessivamente

Riga 55 ⟶ 65:

* Punto di vista ambiguo (''ambiguous viewpoint''): diagramma che indica solo le parti, ma non cosa compongono, ad esempio senza distinguere tra parti di interfaccia e di implementazione

* [[Reinventare la ruota]] (''reinventing the wheel''): reimplementare un metodo che è già stato implementato, testato e ottimizzato da qualcun altro

* Reinventare la ruota quadrata (''Reinventingreinventing the Square Wheel''): come ''reinventing the wheel'', ma il risultato della reimplementazione è peggiore del metodo esistente

* Saltare il primo (''Fencepost'' o anche ''off-by-one error''): partire dall'indice iniziale sbagliato in un loop (ad esempio in Java iniziare il loop su un array partendo da 1 invece che da 0, o contare un intervallo di valori escludendo il primo, tipicamente il numero di giorni di validità compreso fra due date dimenticando che il primo giorno va considerato)

* [[Software bloat|Software che ingrassa]] (''software bloat''): tendenza di un'applicazione ad avere programmi di installazione che crescono a dismisura

Riga 65 ⟶ 75:

== Bibliografia ==

* William J. Brown, Raphael C. Malveau, Hays W. McCormick III, e Thomas J. Mowbray. 1998. ''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis''. [[John Wiley & Sons]] ISBN 0-471-19713-0.

== Note ==

<references />

== Altri progetti ==

{{interprogetto|preposizione=sull'}}

== Collegamenti esterni ==