Anti pattern

Gianni Valdambrini

Anti-pattern: mito o realtà?

Firenze, 27 Settembre 2012

Gianni Valdambrini – aleister@develer.com

Vade retro, Satana!

A chi NON è rivolto questo talk:

• A chi crede che la tecnologia migliore nell'informatica siail copia-incolla

• A quelli per cui “così funge”

• A quelli che “il cane mi ha mangiato i compiti”

Io non ne ho mai visti...

Anti pattern

Come ogni mostro che si rispetti, gli anti-pattern si nascondonoalla vista dei più, che non credono alla loro esistenza..

Il termine anti-pattern si riferisce a problemi ricorrenti nella progettazione del software.

Possono riguardare ogni aspetto dello sviluppo: manageriale, architetturale e sviluppo del codice vero e proprio.

In questo talk verrà presentata una selezione dei più comuni o insidiosi anti-pattern, capaci di colpire anche (o soprattutto?) i più esperti...

4 / 37

Analysis Paralysis

E' una (quasi) diretta implicazione del modello Waterfall.Avviene ogni volta che viene speso troppo tempo per fare un'analisiperfetta.

→ Questo blocca l'intero processo di sviluppo, e non produce nessun valore per il cliente.

Soluzione: effettuare l'analisi dei componenti principali per delineare la struttura del progetto e iniziare l'implementazione partendo daicomponenti “più importanti”. Usare test automatici per aiutare il refactoring nei casi di analisi con lacune.

6 / 37

Death By Planning

Death by Planning

“Abbiamo un piano: se lo seguiamo e non ci allontaniamo da essonon avremo problemi”

Avviene quando la pianificazione coinvolge anche i dettagli del progetto e, nei casi peggiori, “il piano” viene aggiornato durante losviluppo per riflettere i cambiamenti.

→ I costi della pianificazione diventano eccessivi e possono produrre ritardi nello sviluppo senza produrre alcun valore.

Soluzione: limitare la pianificazione alle parti che hanno un valore per il cliente o che rappresentano i componenti chiave per costruirle.

8 / 37

Dead End

Si ha quando un componente esterno al progetto viene modificato,e le modifiche non vengono integrate nel componente ma risultanoin carico agli sviluppatori del progetto.

→ la manutenzione delle modifiche richiede del lavoro extra necessario ad ogni nuova versione del progetto e del componente.

Soluzione: adottare componenti per quanto possibile standard e diffusi o isolare le modifiche in un layer apposito (dp adapter).

10 / 37

Reinventing the wheel

Avviene quando un programmatore piuttosto che adottare una soluzione già esistente decide di crearne una propria.

Due casi:• quando si riprende il lavoro fatto da altri.

• quando il lavoro a noi richiesto è già realizzato da una libreria esterna.

→ Nel primo caso la soluzione nuova potrà facilmente diventare sempre più simile alla vecchia. Nel secondo, la soluzione fatta in casa ci porterà via molto tempo e sarà peggiore della soluzione esterna.

Soluzione: valutare con attenzione se qualcuno ha già risolto il problema in un modo “compatibile” con le nostre esigenze.

12 / 37

Spaghetti Code

E' un termine dispregiativo che identifica un codice mal strutturato, che ha subito una serie di modifiche per coprire i casi non coperti dal codice o per gestire “eccezioni”.

→ il degradamento del codice porta a una maggiore lentezza negli sviluppi, ad una minore leggibilità del codice e a difficoltà di debugging.

Soluzione: effettuare refactoring per rendere la struttura del codicechiara e facilmente espandibile.

14 / 37

Overengineering

Si ha quando un programma viene realizzato più robusto e complessodel necessario, o con più funzionalità di quanto previsto.

→ il sovra-dimensionamento comporta una maggiore lentezza nello sviluppo, difficoltà nel debugging e in generale costi maggiori del progetto.

Soluzione: “KISS principle”, mantenere le cose più semplici possibili.

16 / 37

Circular Dependency

Si riferisce alla creazione di dipendenze circolari fra oggetti omoduli/librerie.

→ causa un alto accoppiamento fra le entità che non potranno più essere utilizzate in modo indipendente. Si può inoltre verificare un effetto domino in cui modifiche minori in una entità scatenano altri cambiamenti.

Soluzione: spezzare la dipendenza circolare quando possibile, usando meccanismi di notifica (dp observer).

18 / 37

Cargo Cult Programming

Succede quando vengono utilizzati metodologie, design patterno codice senza averne compreso appieno le motivazioni e il funzionamento.

→ il fraintendimento può causare difficoltà nel modificare il codice (che a sua volta può portare a bug) o nel caso delle metodologie al fallimento dovuto ad un'interpretazione letterale delle regole.

Soluzione: è necessario comprendere appieno le soluzioni proposte da altri, adattandole se necessario al caso in questione.

20 / 37

Error Hiding

Si riferisce al nascondere un errore o un'eccezione semplificandol'errore o nascondendolo del tutto per celare la complessità del sistema all'utente.

→ l'utente del sistema non può comunicare quale sia con esattezza l'errore che diventa quindi molto difficile da individuare e correggere.

Soluzione: mostrare un errore semplificato all'utente riportandol'errore completo in un file di log o inviandolo via mail.

22 / 37

Yo-yo problem

E' legato in particolare alla programmazione ad oggetti.

Succede quando si deve comprendere del codice con una gerarchia di classi così complicata che è necessario spostarsi continuamente fra le classi per seguire il flusso del programma.

→ la frammentazione del codice rende difficile comprendere il flusso del codice, specialmente nel caso di metodi virtuali, e questo può a sua volta essere fonte di errori.

Soluzione: limitare la gerarchia fra classi e preferire la composizione all'ereditarietà “selvaggia”.

24 / 37

Abstraction Inversion

Avviene quando dobbiamo sviluppare delle funzionalità di alto livello ed avendo già un'implementazione più generica e complessa decidiamo di costruire l'astrazione sopra di essa.

→ la complessità derivante dal sistema sottostante rende difficile il debugging e lo sviluppo di nuove funzionalità.

Soluzione: scegliere con attenzione il modo di riutilizzare codice, evitando complessità accidentale.

26 / 37

Gold Plating

Si riferisce alla pratica di continuare a lavorare su un progetto o task dopo che esso ha tutte le funzionalità richieste dal cliente.

→ nella quasi totalità dei casi il cliente (e di sicuro il project manager) avrebbe preferito che venisse sviluppata un'altra

funzionalità.

Soluzione: eseguire i task fino al loro compimento seguendo lapriorità data dal project manager / cliente.

28 / 37

God Object

Dovuto spesso ad un abuso dell'ereditarietà, è abbastanzafrequente nelle classi base di framework di grandi dimensioni.

Consiste nel caricare di troppe funzionalità o responsabilità (ancheetereogenee tra loro) un oggetto, che diventa quindi il “cuore” delsoftware.

→ comporta difficoltà di debugging, manutenzione e di utilizzo dell'oggetto.

Soluzione: limitare l'utilizzo dell'ereditarietà e suddividere le responsabilità secondo criteri logici.

30 / 37

Blind Faith

Si riferisce alla tendenza dei programmatori di non testare la corretta implementazione di bugfix o di una modifica in generale, per pigrizia o per una infrastruttura in cui il testing è troppo oneroso.

→ oltre a non realizzare la funzionalità richiesta, si possono verificare altri bug più o meno gravi generati dalla modifica.

Soluzione: utilizzare pratiche come il TDD o lo unit testing in generale.

32 / 37

Copy & Paste Programming

Si riferisce alla tendenza dei programmatori di copiare del codiceesistente per implementare una nuova funzionalità più velocementerispetto al creare nuovo codice da zero.

→ Oltre alle classiche sviste, il codice duplicato sarà più difficile da sviluppare ulteriormente e eventuali bug si ritroveranno quindi in più parti.

Soluzione: generalizzare il codice mediante refactoring ed evitarele duplicazioni (DRY principle).

34 / 37

Photo & Artworks Credits

Davide Bellocchio

Kassandra Igolka

Jason Chan

Justin Holzworth

Ellie Phillips

Ben Bohane

Henrik Moses

Let's Talk

e-mail

office+39 055 3984627

aleister@develer.com

www.develer.com

License

Creative Commons Attribution 3.0 Unported

Anti pattern

Documents

Transcript of Anti pattern

PATTERN SCACCHISTICI

RIABITA IL COTTO - hub.grupporomanispa.com · 1047041 Inserto Pattern Grey S/4 Mq 40x40 . 16"x16" 1047118 Inserto Pattern Beige S/4 Pz 1047040 Inserto Pattern Beige S/4 Mq ... Variations

Pattern aqccurnersdorf 2015

A pattern language, per la scuola

Introduzione ai design pattern

Corso di servlet jsp e pattern

Design Patterns - MathUniPDlocalconte/lezioni/Pattern(1e2).pdf · 2009-01-07 · Descrizione di un Design Pattern (2) Applicability What are the situations in which the design pattern

Pattern Armonici

Free Tatting Pattern

Esercizi Design pattern

Un framework per il pattern MVC

SFC Pattern Languagesweb.sfc.keio.ac.jp/~iba/tmp/SFCPL2011-DoublePages.pdfSFC「パターンランゲージ」グループワーク成果集 Social Innovation pattern language 野中

Design Pattern - 3. Decorator pattern

Elementary Pattern, Anti Elementary Pattern e GRASP Pattern

Design Pattern Comportamentali

Officinarkitettura® PATTERN DESIGN

Press Release · - Nanotenologia anti-ma hia e anti-età protetion - anti-impronta - anti-graffio - anti- orrosione (grazie all’aiaio AISI 304, il migliore sul mer ato) ARATTERISTIHE

Macrame d'amare Pattern Per Bracciale

Design Pattern - Unicamcomputerscience.unicam.it/culmone/?download=Pattern.pdf · Design pattern nella libreria Java I pattern sono utilizzati abbondantemente dalle classi standard

FREE PATTERN Pancerito Lindo