Anti pattern
Upcoming SlideShare
Loading in...5
×
 

Anti pattern

on

  • 385 views

Gli anti-pattern sono errori comuni commessi nella programmazione o progettazione del software, spesso visti in chiave ironica. Come i più noti design pattern, hanno nomi evocativi che ben descrivono ...

Gli anti-pattern sono errori comuni commessi nella programmazione o progettazione del software, spesso visti in chiave ironica. Come i più noti design pattern, hanno nomi evocativi che ben descrivono con pochi termini il problema.

Statistics

Views

Total Views
385
Views on SlideShare
384
Embed Views
1

Actions

Likes
2
Downloads
6
Comments
0

1 Embed 1

https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Anti pattern Anti pattern Presentation Transcript

  • Gianni ValdambriniAnti-pattern: mito o realtà?Firenze, 27 Settembre 2012
  • Vade retro, Satana!A chi NON è rivolto questo talk: • A chi crede che la tecnologia migliore nellinformatica sia il copia-incolla • A quelli per cui “così funge” • A quelli che “il cane mi ha mangiato i compiti” Gianni Valdambrini – aleister@develer.com
  • Io non ne ho mai visti...Gianni Valdambrini – aleister@develer.com
  • Anti patternCome 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 nellaprogettazione 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 oinsidiosi anti-pattern, capaci di colpire anche (o soprattutto?) ipiù esperti... 4 / 37 Gianni Valdambrini – aleister@develer.com
  • Analysis ParalysisGianni Valdambrini – aleister@develer.com
  • Analysis ParalysisE una (quasi) diretta implicazione del modello Waterfall.Avviene ogni volta che viene speso troppo tempo per fare unanalisiperfetta. → Questo blocca lintero processo di sviluppo, e non produce nessun valore per il cliente.Soluzione: effettuare lanalisi dei componenti principali per delinearela struttura del progetto e iniziare limplementazione partendo daicomponenti “più importanti”. Usare test automatici per aiutare ilrefactoring nei casi di analisi con lacune. 6 / 37 Gianni Valdambrini – aleister@develer.com
  • Death By PlanningGianni Valdambrini – aleister@develer.com
  • 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 delprogetto 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 valoreper il cliente o che rappresentano i componenti chiave per costruirle. 8 / 37 Gianni Valdambrini – aleister@develer.com
  • Dead EndGianni Valdambrini – aleister@develer.com
  • Dead EndSi 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 ediffusi o isolare le modifiche in un layer apposito (dp adapter). 10 / 37 Gianni Valdambrini – aleister@develer.com
  • Reinventing the wheelGianni Valdambrini – aleister@develer.com
  • Reinventing the wheelAvviene quando un programmatore piuttosto che adottare unasoluzione 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à risoltoil problema in un modo “compatibile” con le nostre esigenze. 12 / 37 Gianni Valdambrini – aleister@develer.com
  • Spaghetti CodeGianni Valdambrini – aleister@develer.com
  • Spaghetti CodeE un termine dispregiativo che identifica un codice mal strutturato,che ha subito una serie di modifiche per coprire i casi non copertidal 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 Gianni Valdambrini – aleister@develer.com
  • OverengineeringGianni Valdambrini – aleister@develer.com
  • OverengineeringSi 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 Gianni Valdambrini – aleister@develer.com
  • Circular DependencyGianni Valdambrini – aleister@develer.com
  • Circular DependencySi 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 Gianni Valdambrini – aleister@develer.com
  • Cargo Cult ProgrammingGianni Valdambrini – aleister@develer.com
  • Cargo Cult ProgrammingSuccede quando vengono utilizzati metodologie, design patterno codice senza averne compreso appieno le motivazioni e ilfunzionamento. → 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 uninterpretazione letterale delle regole.Soluzione: è necessario comprendere appieno le soluzioniproposte da altri, adattandole se necessario al caso in questione. 20 / 37 Gianni Valdambrini – aleister@develer.com
  • Error HidingGianni Valdambrini – aleister@develer.com
  • Error HidingSi riferisce al nascondere un errore o uneccezione semplificandolerrore o nascondendolo del tutto per celare la complessità delsistema allutente. → lutente del sistema non può comunicare quale sia con esattezza lerrore che diventa quindi molto difficile da individuare e correggere.Soluzione: mostrare un errore semplificato allutente riportandolerrore completo in un file di log o inviandolo via mail. 22 / 37 Gianni Valdambrini – aleister@develer.com
  • Yo-yo problemGianni Valdambrini – aleister@develer.com
  • Yo-yo problemE legato in particolare alla programmazione ad oggetti.Succede quando si deve comprendere del codice con una gerarchiadi classi così complicata che è necessario spostarsi continuamentefra 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 composizioneallereditarietà “selvaggia”. 24 / 37 Gianni Valdambrini – aleister@develer.com
  • Abstraction InversionGianni Valdambrini – aleister@develer.com
  • Abstraction InversionAvviene quando dobbiamo sviluppare delle funzionalità di alto livelloed avendo già unimplementazione più generica e complessadecidiamo di costruire lastrazione 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 Gianni Valdambrini – aleister@develer.com
  • Gold PlatingGianni Valdambrini – aleister@develer.com
  • Gold PlatingSi riferisce alla pratica di continuare a lavorare su un progetto otask 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 unaltra funzionalità.Soluzione: eseguire i task fino al loro compimento seguendo lapriorità data dal project manager / cliente. 28 / 37 Gianni Valdambrini – aleister@develer.com
  • God ObjectGianni Valdambrini – aleister@develer.com
  • God ObjectDovuto spesso ad un abuso dellereditarietà, è 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 delloggetto.Soluzione: limitare lutilizzo dellereditarietà e suddividere leresponsabilità secondo criteri logici. 30 / 37 Gianni Valdambrini – aleister@develer.com
  • Blind FaithGianni Valdambrini – aleister@develer.com
  • Blind FaithSi riferisce alla tendenza dei programmatori di non testare lacorretta implementazione di bugfix o di una modifica in generale,per pigrizia o per una infrastruttura in cui il testing è troppooneroso. → 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 ingenerale. 32 / 37 Gianni Valdambrini – aleister@develer.com
  • Copy & Paste ProgrammingGianni Valdambrini – aleister@develer.com
  • Copy & Paste ProgrammingSi 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 Gianni Valdambrini – aleister@develer.com
  • Photo & Artworks CreditsKassandra IgolkaDavide BellocchioJason ChanJustin HolzworthEllie PhillipsBen BohaneHenrik Moses
  • Lets Talkoffice+39 055 3984627e-mailaleister@develer.comwebwww.develer.com
  • LicenseCreative Commons Attribution 3.0 Unported