Anti-Pattern

Un anti-pattern ( dall'inglese , tradotto come anti-pattern ) è un termine generico per i modelli di comportamento che sono trasferibili soprattutto nello sviluppo del software e per lo più generali alle organizzazioni . Gli approcci a una soluzione che sono sfavorevoli o dannosi per il successo di un progetto o di un'organizzazione sono indicati come anti-pattern. Costituiscono la controparte di Pattern ( modello inglese ) che rappresenta approcci di risoluzione dei problemi validi e comprovati.

Il concetto di pattern era meglio conosciuto attraverso i design patterns del libro del 1994 con lo stesso nome . Ciascuno di essi include una descrizione di una situazione problematica prototipo, inclusa una soluzione proposta. Dopo che i modelli sono stati utilizzati con sempre maggior successo nello sviluppo del software, sono stati discussi anche esempi negativi per identificare e documentare errori ricorrenti e indicare le misure da adottare per porvi rimedio. Proprio come i pattern non si limitano alla progettazione del software e ci sono anche cataloghi per pattern di analisi , pattern architetturali o pattern organizzativi , anche gli anti-pattern non si limitano al codice sorgente e all'architettura del software , ma spesso si concentrano sulla gestione del progetto e sull'azienda processi.

Di norma, gli anti-pattern derivano da una mancanza di esperienza o da una mancanza di qualifiche. Si può anche osservare l'uso consapevole di anti-pattern al fine di raggiungere uno scopo specifico che si discosta dall'effettivo obiettivo del progetto a proprio vantaggio.

categorizzazione

Nel frattempo, le occorrenze di anti-pattern si differenziano sempre più finemente. Si estendono dalla pura programmazione software (questo è anche chiamato code odors , che possono essere rimossi mediante refactoring se esistono e vengono identificati ), passano all'architettura e al design , lavorano nella gestione dei progetti e nei processi e nell'organizzazione aziendale oltre che in Gestione. Inoltre, i cosiddetti meta-pattern possono essere identificati più frequentemente nella pratica. Questi combinano modelli individuali in nuovi modelli più astratti o introducono ulteriori dimensioni o categorizzazioni più astratte.

Anti-pattern di gestione del progetto

Ingombrare

Il lavoro di abbagliamento (inglese Smoke and mirrors ) denota funzioni non finite, che vengono simulate come finite.

Software gonfio

Il software gonfio descrive il software che è gonfio di funzioni aggiuntive non necessarie o risorse sprecate e quindi migliora poco o per niente l'applicazione effettiva.

Caratteristica strisciante Feature

Feature creep ( funzionalità di inizio creep ) lo chiamava quando si tiene la quantità di funzionalità da sviluppare in un piano di progetto , ma viene continuamente ampliata.

Dopo aver creato il piano di progetto, il cliente cerca di incorporare ulteriori funzionalità nella versione. Questo porta a problemi se la versione in corso non ha la progettazione necessaria, le scadenze non possono essere rispettate o i costi reali crescono oltre i costi pianificati.

Questo è molto pericoloso nei processi pesanti . Con processi leggeri come Extreme Programming (XP), le conseguenze devono essere chiare a tutte le persone coinvolte. La gestione dei requisiti sistematici e la gestione delle modifiche sono obbligatorie. Certe modifiche al piano di progetto durante lo sviluppo sono difficili da evitare in progetti più grandi, perché elaborare le specifiche fino all'ultimo dettaglio di solito richiede più tempo rispetto alla pianificazione di una piccola riserva. I requisiti possono anche essere scoperti solo durante lo sviluppo.

L'uso estremo, doloso e gravemente negligente di questo modello può essere motivato dal fatto che il cliente, che richiede sempre nuove funzionalità, vuole boicottare il prodotto e cerca di impedirne il completamento, o ha deliberatamente soppresso la funzionalità effettivamente richiesta nella progettazione per trovarne uno più economico Per ricevere un'offerta.

Un gioco di parole, il cui contenuto include il passaggio da creatura strisciante a creatura palpitante , esprime il fatto che i requisiti e le implementazioni sono diventati inutili o non rientrano nel concetto generale.

Ambito strisciante

Lo scope creep ( creep in ulteriori aree di applicazione ) è simile al feature creep , ma non relativo alla funzionalità, bensì all'area di applicazione. Anche qui il cliente si caratterizza per il fatto di voler ampliare la portata del software in modo intelligente e nascosto senza ammetterlo esplicitamente. Esempio: aree di applicazione che non vengono discusse sono improvvisamente molto importanti o la mancanza di un'area viene addirittura presentata come un errore che deve essere urgentemente corretto.

Legge di Brooks

La legge Brooks'sche afferma che un progetto di herhinkendes in ritardo sul programma richiede più tempo quando vengono assunti nuovi dipendenti perché i nuovi dipendenti avranno bisogno di tempo per imparare le basi e lei frena i colleghi affermati.

Sprint della morte

Con un Death Sprint ( Piano di progetto surriscaldato ), il software viene distribuito in modo iterativo . La disposizione avviene in un periodo di tempo troppo breve. Dall'esterno, il progetto sembra inizialmente molto riuscito, poiché vengono sempre completate nuove versioni con nuove proprietà. Tuttavia, la qualità del prodotto soffre sia esternamente che tecnicamente, cosa che però solo lo sviluppatore riconosce. La qualità diminuisce ad ogni nuova iterazione "riuscito". Il Death Sprint è la controparte della Death March .

Marcia della morte

Un Deathmarch ( Todesmarsch ; occasionalmente Himmelfahrtskommando ) è la controparte di un Death Sprint ( Superheated project plan ; s o..). Un progetto di marcia della morte si trascina per sempre.

In un caso ottimale, vengono fornite versioni anticipate, ma sono di scarsa qualità. Il fallimento è oggettivamente visibile. Non possono essere mantenute pietre miliari o non ne esistono. Nel peggiore dei casi, una conseguenza di ciò può essere che il progetto non è più un progetto, ma solo una sequenza di attività che non si completa in tempo. Non ci sono impegni specifici per date e consegna degli immobili.

Un progetto di marcia della morte può anche essere consapevolmente accettato per distogliere l'attenzione da carenze organizzative e ritardarne gli sviluppi, i. H. sviluppare qualcosa fino a quando una proprietà non specificata funziona soggettivamente in qualche forma. Se entrambe le gestione dei requisiti e la gestione del cambiamento sono non è a posto e il progetto è non è più un progetto, evoluzione del prodotto dondola intorno disorientato e la sua qualità diminuisce costantemente.

Un progetto di marcia della morte può anche essere combinato con un piano di progetto surriscaldato (vedi sopra) per distrarre dalla mancanza di pianificazione e deficit di organizzazione e tecnologia. La funzionalità viene quindi presentata come nuova, già esistente da tempo, oppure non esiste un'istanza di controllo che valuti la necessità, la pertinenza, la forma, la correttezza e l'importanza della funzionalità fornita.

esempio

Le nuove richieste di ieri sono ( non : include!) I bug di domani.

Un progetto di marcia della morte spesso si verifica quando non ci sono parti interessate interessate al prodotto, o quando lo sforzo che va nel prodotto o anche l'intero prodotto alla fine non ha significato / importanza. In questo caso, l'azienda o il dipartimento di sviluppo spesso si occupa (di) se stesso.

Architettura o design anti-pattern

Grande palla di fango

Il software che non ha un'architettura software identificabile è come una grande palla di fango ( chiamati grandi grumi di fango ).

Fabbrica del gas

Come impianto di gas ( fabbrica di gas inglese ) sono noti progetti di sistemi sprezzanti e inutilmente complessi per problemi relativamente semplici.

Dio oggetto

I termini god object (inglese god object ), God class ( God class ) e Blob descrivono un oggetto che sa troppo o sa troppo. La divisione in responsabilità, l'incapsulamento e l'aderenza ai modelli di progettazione aiutano a contrastare questo modello.

Effetto piattaforma interna

L' effetto piattaforma interna ( effetto piattaforma interna inglese ) si verifica quando un sistema ha opzioni di configurazione così ampie da diventare alla fine una copia debole della piattaforma per mezzo della quale è stato costruito. Un esempio sono i modelli di dati che rinunciano a tabelle di database specifiche (relative all'applicazione) e utilizzano invece tabelle generali per implementare un livello di gestione separato per la struttura dei dati con l'obiettivo effettivo di aumentare la flessibilità. Tuttavia, tali sistemi sono in genere difficili da padroneggiare e spesso soffrono di ulteriori problemi di prestazioni.

Codice spaghetti

Spaghetticode è una struttura di sistema molto compatta, caratterizzata da comandi di salto il cui flusso di controllo è simile ad una pentola di spaghetti. Il codice assomiglia a un blocco monolitico ed è particolarmente povero di manutenibilità e riutilizzabilità.

matrimonio sumo

Come matrimonio sumo (inglese Sumo Marriage ), viene indicato come un cliente grasso innaturalmente fortemente dipendente dal database .

Molta logica è posizionata nel database sotto forma di linguaggio di programmazione proprio del database . Ad esempio in Oracle con il linguaggio di programmazione PL/SQL . Di conseguenza, l'intera architettura è molto inflessibile.

Se l'applicazione deve essere migrata su un'applicazione Internet o se il database deve essere modificato, molte aree devono essere riqualificate su entrambi i livelli ( client e gestione dati ). I sistemi non sono disaccoppiati .

Database di integrazione

Un database di integrazione è un database utilizzato direttamente da diverse applicazioni per garantire la sincronizzazione tra le applicazioni.

L'alternativa a un database di integrazione è un database condiviso . Questo è un database a cui si accede da un singolo servizio web. Il servizio web fornisce le funzionalità del database sotto forma di interfaccia REST o SOAP e può essere utilizzato da varie applicazioni.

Programmazione anti-pattern

Blocco ricontrollato

Sviluppatori inesperti spesso implementano come difettose essere considerato ricontrollato bloccaggio (inglese ricontrollato blocco ). Questo è considerato un anti-pattern.

cipolla

Quando onion (inglese Onion ) si riferisce al codice del programma in cui è prevista la nuova funzionalità (o superiore) alla vecchia.

Spesso, le cipolle sorgono quando a uno sviluppatore viene chiesto di aggiungere a un programma che non ha scritto. Lo sviluppatore non vuole o non può comprendere appieno la soluzione esistente e semplicemente sovrappone la sua nuova soluzione. Con una moltitudine di versioni e sviluppatori diversi, questo porta a un sistema a cipolla nel corso degli anni.

Copia e incolla

Programmazione per mezzo di copiare e incollare (inglese copia ed incolla di programmazione ) descrive quando il programmatore non si sviluppa il codice da zero, ma usi attuali testi di origine da cui copia passaggi.

C'è un rischio molto alto che copi anche errori o che la copia non sia pronta in modo ottimale per l'uso nella nuova area. Lo sviluppatore riflette meno sul suo programma che se sviluppasse personalmente ogni linea. Questa è una procedura soggetta a errori se lo sviluppatore non sa cosa sta effettivamente facendo. La manutenibilità del codice è ridotta se (quasi) lo stesso codice di programma si verifica in più punti. Invece di copiare, dovrebbe essere prevista una funzione comune.

Flusso di lava

Un flusso di lava (in inglese Lava flow o Dead Code ) descrive il fatto che in un'applicazione è presente sempre più "codice sorgente morto". Questo non è più utilizzato. Invece di eliminarlo, nel programma vengono integrati sempre più rami che girano attorno a detto testo sorgente o si basano su di esso. Il codice ridondante è il termine generico per codice morto. Contiene oltre al dead code ( English dead code ) (codice eseguito, il risultato non viene mai utilizzato) anche unreachable code ( English unreachable code ), ovvero codice che a causa del controllo di sequenza mai eseguito raggiunto in qualsiasi possibile esecuzione del intero programma e quindi può essere. Il termine codice morto è spesso usato come sinonimo di codice ridondante.

Valori magici

In Magic values (in inglese Magic Values ) è, ai dati ( letterali ) con un significato speciale. Essi sono hardcoded (inglese hardcoded ) e devono essere considerati con particolare conoscenza dell'uso specifico. Tali valori dovrebbero essere definiti centralmente come una costante o una variabile, idealmente come un oggetto indipendente dai tipi .

public class Bar {
    public static void main(String[] args) {
        Bar bar = new Bar();
        bar.go(7); // hart codierter Wert
    }
    public void go(int param){
        switch(param) {
            case 1:  System.out.println("a"); break;
            case 3:  System.out.println("b"); break;
            case 7:  System.out.println("c"); break;
            case 12: System.out.println("d"); break;
            default: System.out.println("x"); break;
        }
    }
}

Parole riservate

L'uso di parole riservate, come nelle istruzioni SQL , può portare a errori difficili da trovare. La sostituzione del database di un produttore con un altro prodotto può comportare la necessità di considerare riservati ulteriori nomi. Ciò può essere contrastato fornendo costantemente identificatori e stringhe di caratteri con i corrispondenti indicatori di inizio e fine (ad esempio virgolette).

Complessità non intenzionale

Poiché la complessità non intenzionale ( complessità accidentale inglese ) è chiamata una soluzione programmata che è più complessa di quanto sarebbe necessaria per essere risolta e appropriata per questo. Questo anti-modello è legato alla fabbrica del gas .

Anti-pattern organizzativi, gestionali e di processo

Arma miracolosa

Un arma miracolosa (inglese d'oro martello ) è una soluzione preferita, che è considerato universalmente applicabile.

Reinventare la ruota

Con reinventare la ruota (inglese reinventare la ruota o non inventato qui la sindrome ) è la ricostruzione costante di software - senza soluzioni o esistente framework per l'uso - chiamato. Poiché non c'è riutilizzo, lo sforzo di sviluppo aumenta, il che porta a software immaturo e più costoso (rispetto all'utilizzo del software esistente).

Reinventa la ruota quadrata

Con il quadrato reinventa la ruota (in inglese Reinventing the square wheel ) si intende la fornitura di una soluzione scadente quando esiste già una buona soluzione.

Mongolfiera

Nel body ballooning , il supervisore agisce esclusivamente per lo sforzo di espandere la sua posizione di potere, che è definita o dalla struttura aziendale o puramente soggettivamente dal numero dei dipendenti. Ciò può portare il supervisore a preferire consapevolmente soluzioni e tecniche di lavoro più laboriose a quelle efficienti.

Edificio dell'impero

Una singola persona cerca di espandere o mantenere il proprio potere mediante misure di fatto incomprensibili e costruttive. Questo può essere body ballooning , ma anche il continuo biasimo degli altri, soprattutto di chi non lavora più per l'azienda, l'esecuzione di politiche patologiche, discredito , bullismo e altre sfaccettature che mirano solo a rafforzare la propria posizione o a mantenere la propria stato. Questo modello è caratterizzato anche dal fatto che la persona evita di assumersi responsabilità e sa prevenire prove scritte di incidenti e decisioni. Pertanto, non deve essere misurato da questi, il che rende anche più facile delegare semplicemente la responsabilità del fallimento di un progetto a un'altra persona. Qui si preferisce scegliere qualcuno che abbia effettivamente attuato solo le decisioni (come un programmatore che implementa le decisioni del supervisore o un project manager che implementa i requisiti del cliente).

cadavere caldo

Un cadavere caldo (in inglese hot body ) si riferisce a una persona che fornisce un contributo dubbio o nullo a un progetto.

Unico responsabile della conoscenza

Un singolo responsabile della conoscenza è un individuo che è l'unico a conoscere un software, uno strumento o un altro mezzo utilizzato in tutta l'azienda. Questo spesso mostra una mancanza di gestione della conoscenza , una mancanza di scambio tra colleghi o carenze nell'organizzazione, ma può anche essere stato consapevolmente perseguito dall'individuo.

Quando l'individuo lascia l'azienda, metaforicamente parlando, porta con sé la conoscenza, il che è molto pericoloso per l'azienda. L'azienda sta sanguinando metaforicamente da ( sanguinando ).

Il modello può essere prevenuto adottando misure appropriate. Ad esempio, attraverso lo sviluppo dopo XP ed eventi di team building insieme alla fidelizzazione dei dipendenti, alla motivazione e alla promozione dell'identificazione con l'azienda al fine di ridurre al minimo le fluttuazioni. Una documentazione adeguata, a cui hanno accesso tutti i dipendenti interessati, impedisce un singolo responsabile della conoscenza .

Gestione dei funghi

Con la gestione dei funghi , i dipendenti vengono tenuti disinformati e piccoli. Il seguente principio si applica di conseguenza:

Lo sviluppo e l'autorealizzazione difficilmente avvengono nella gestione dei funghi . L'analogia della forza lavoro con un campo di funghi è caratterizzata dal fatto che i dipendenti sono visivamente ricoperti di sterco e tenuti al buio e, se sono diventati troppo grandi (troppa esperienza, prestazioni troppo buone, ecc.), ridotti , messo sotto pressione o addirittura licenziato. Questa associazione include anche il fatto che la direzione prende decisioni senza consultare gli specialisti o non informa la forza lavoro di queste decisioni. Spesso si può anche osservare che il management non conosce le capacità individuali, i punti di forza, i punti deboli e i ruoli dei membri del team e talvolta non vuole nemmeno conoscerli (le persone sono messe in riga: ammettere che qualcuno può fare più degli altri li rende più potenti, cosa che deve essere evitata).

Un altro incontro lo risolverà

Un altro incontro lo risolverà ( Yet Another Meeting Will Solve It ) è quando viene convocato un incontro in un progetto in ritardo (cioè un progetto con un ritardo), che aumenta solo il ritardo.

Programmatore di produzione negativa netta

Un programmatore che produce un netto negativo è uno sviluppatore poco performante e improduttivo. Rimuovere questo da un team può fare di più per aumentare la produttività del progetto rispetto all'aggiunta di un buon sviluppatore e lasciare quello improduttivo.

Gestione per numeri

Management by Numbers (in inglese management by numbers ) è un'allusione alla pittura per numeri . Nella gestione dei numeri, c'è un'enfasi eccessiva sulla gestione quantitativa. Soprattutto quando l'attenzione è rivolta al costo mentre altri fattori come la qualità vengono trascurati.

In questo modello, i programmatori saranno felici come una "merce" (la merce inglese vista) e considerata intercambiabile. Questo è un modo di pensare a brevissimo termine che non tiene conto del fatto che una mancanza di motivazione o fluttuazione dei dipendenti può comportare costi significativamente più elevati per l'azienda nel medio-lungo termine rispetto a un investimento a breve termine in questi.

È qui da citare anche il termine software factory , il tentativo di automatizzare lo sviluppo del software e di considerare il programmatore come un fattore produttivo intercambiabile . Tuttavia, ciò non tiene sufficientemente conto del fatto che lo sviluppo del software è in larga misura un processo creativo e artistico che richiede libertà e, idealmente, un alto grado di potenziale di sviluppo e motivazione (idealmente intrinseca ) da parte dello sviluppatore. Va inoltre tenuto presente che i dipendenti acquisiscono molta esperienza lavorando su un prodotto nel tempo, che l'azienda perde in larga misura se la persona lascia l'azienda.

Paura del successo

La paura del successo (inglese Fear Of Success ) e l' atmosfera di paura si riferiscono ad essa quando la gestione di un'atmosfera spaventata e difensiva. È come una squadra di calcio che difende solo la propria porta senza cercare di segnare da sola.

In una cultura piena di paure, difficilmente può nascere qualcosa di costruttivo. Anche le persone che creano qualcosa di buono interrompono il loro progetto perché presumono che perderanno comunque o che la buona soluzione non sarà ricompensata o presentata come cattiva.

Le aziende timorose appaiono paralizzate e non riescono ad avvicinarsi attivamente a nuovi mercati e soluzioni. Intere aziende, dipartimenti o individui perdono la loro competitività . La paura di attirare l'attenzione attraverso i successi e quindi di attirare il sospetto dei colleghi o del management impedisce anche a dipendenti e aziende di raggiungere il loro pieno potenziale. Non è raro che i cattivi manager vedano un pericolo in ottimi dipendenti, poiché sono in competizione per la loro posizione.

Dichiarazione tipica: “Lo faccio in segreto. È la soluzione migliore, ma non voglio che il capo lo sappia".

Architetto di sistema sbagliato

Un falso architetto di sistema ( Faux System Architects ) può sorgere quando la direzione si rende conto che ci sono grandi differenze nelle competenze del programmatore. La direzione sceglie una persona che ha abilità apparentemente travolgenti, ad esempio nello sviluppo di software e nel trattare con le persone, specialmente con persone le cui qualifiche sono al di sotto della media.

La persona è schierata con alte aspettative dal management ed è spesso un architetto , ma spesso anche un altro professionista superiore. Gli specialisti interni non sono chiamati a fare la selezione, ma la direzione decide da sola, anche se è difficile decidere da sola se qualcuno è un buon sviluppatore di software.

Per molto tempo, anche questo funziona abbastanza bene, poiché il presunto esperto può vendersi abbastanza bene e sa anche esprimersi verbalmente molto abilmente. Col tempo, però, diventa sempre più evidente che le aspettative riposte sull'architetto erano troppo alte. Da un lato a causa del mancato miglioramento del software o della qualità costantemente scadente dei cattivi programmatori, dall'altro a causa dell'insoddisfazione dei buoni programmatori. Non può soddisfare le sue aspettative fiorite, quasi cieche. Quando si valuta l'architetto del sistema, è particolarmente importante considerare il progetto nel suo insieme. La qualità costantemente scadente dei cattivi programmatori può benissimo essere dovuta a circostanze che anche un buon architetto di sistema non può prevedibilmente influenzare. A seconda della loro posizione, i buoni architetti di sistema possono anche essere vittime di body ballooning o di costruzione di imperi (vedi sopra). Un buon architetto di sistema, ad es. Ad esempio, non cercare per settimane o mesi di migliorare la qualità dei cattivi programmatori se non c'è un potenziale prevedibile per loro. Condizioni quadro irrealistiche imposte da una cattiva gestione degradano, tra l'altro, anche il miglior architetto di sistema. Se tali circostanze sono note, ma l'architetto di sistema non mostra ancora segni di voler lasciare l'azienda, potrebbe effettivamente essere un cattivo architetto di sistema.

Gestione del coccodrillo

Con la gestione del coccodrillo , il project manager è solo parzialmente presente nel progetto e si occupa solo dei dettagli che il dipendente del progetto non ha affrontato. Per quanto riguarda il comportamento di un coccodrillo, quello del project manager è caratterizzato da:

1. Apparire
2. Apri la bocca
3. immergere

Interruzione del programmatore

Un'interruzione del programmatore si verifica quando il programmatore viene interrotto mentre sta lavorando. Ciò include dichiarazioni di colleghi, e-mail, riunioni imminenti e simili. Gli studi hanno dimostrato che un programmatore ha bisogno da 10 a 15 minuti dopo un'interruzione per poter continuare a lavorare in modo efficace, ma gli viene data l'opportunità di lavorare per più di due ore senza interruzione circa una volta al giorno. L'interruzione è tanto più grave quanto maggiore è lo sforzo mentale del programmatore durante la sua attività.

Le interruzioni sono particolarmente problematiche qui

• mentre si modificano più sezioni di codice contemporaneamente,
• durante le attività di ricerca per problemi di programmazione,
• mentre si pensa attraverso il flusso del programma; soprattutto con il codice parallelo,
• attraverso il quale lo sviluppatore perde di vista l' ambiente di sviluppo integrato .

Gli sviluppatori in genere cercano di contrastare possibili interruzioni con le cuffie , chiudendo il programma di posta elettronica e talvolta spegnendo il cellulare . Inoltre, gli sviluppatori utilizzano metodi per poter familiarizzare di nuovo il più rapidamente possibile, inclusi elenchi di cose da fare , errori di compilazione deliberatamente causati ( ad esempio attraverso test di moduli ) e note adesive .

Tuttavia, è possibile osservare interruzioni nel flusso di lavoro non solo con gli sviluppatori, ma con tutti gli impiegati.

Ulteriore

• Lascia marcire il software

Meta-modello

Aggregazione dell'esperienza del programmatore

I programmatori inesperti di solito sono disposti a lavorare per un'azienda per uno stipendio relativamente basso (ad esempio per ignoranza o per acquisire esperienza lì). In tali aziende, i programmatori spesso non sono valutati dal management (soprattutto nelle aziende in cui predomina la gestione numerica ). Ci sono cattive condizioni di lavoro. I programmatori inesperti non possono sviluppare ulteriormente.

Specialisti esperti vedono cosa sta succedendo e possono valutarlo in modo obiettivo e critico. Cambieranno lavoro per affrontare una sfida che comprende meglio la programmazione e riconosce un buon lavoro. Ciò produce un effetto di raggruppamento in cui i programmatori inesperti si raggruppano o rimangono in azienda e le persone esperte si raggruppano altrove. C'è un elevato turnover, con sempre più brave persone che lasciano l'azienda.

Senza la guida di colleghi esperti, inesperti sviluppatori o neo-assunti rookies non possono migliorare. Si crea un circolo vizioso, rafforzato anche dal fatto che il datore di lavoro invia i suoi dipendenti (presumibilmente meno fedeli) a una formazione sempre minore, perché teme che le persone lascino comunque l'azienda e che i soldi vengano investiti male. Ad un certo punto nessuno in azienda sa che aspetto ha uno sviluppatore esperto e bravo o manca il benchmark : gli sviluppatori inesperti notano sempre meno che in realtà sono inesperti.

Il raggruppamento dell'esperienza del programmatore non è limitato ai programmatori, ma possono essere interessati anche i reparti non IT. Un derivato dell'anti-modello è che le persone buone restano in azienda per comodità o altri motivi personali, ma riducono le loro enormi prestazioni in modo che siano solo un po' migliori dei cattivi dipendenti. Poiché questo è sufficiente per distinguersi e garantire la posizione, i buoni dipendenti non stanno di gran lunga esaurindo il loro potenziale. In definitiva, questo è molto preoccupante per tutti i soggetti coinvolti, ma soprattutto per l'azienda.

decomposizione

Una decomposizione (inglese Corrosion ) descrive l'uso intenzionale o non intenzionale di una moltitudine di anti-pattern provenienti da tutte le aree. Ciò va di pari passo con una coerente difesa della procedura, perlopiù irrilevante, brutale e senza discussione. Si arriva inevitabilmente alla conclusione che l'utente vorrebbe danneggiare l'azienda o il prodotto software per negligenza grave o impedirne l'introduzione efficace e poco costosa. Ciò può anche essere motivato dal fatto che l'utente vuole danneggiare un'altra parte coinvolta.

letteratura

• Frederick P. Brooks: Il mito del mese dell'uomo: Saggi sull'ingegneria del software . mitp, Bonn 2003, ISBN 3-8266-1355-4 . 
• William J. Brown et al.: Anti-pattern. Refactoring di software, architettura e progetti in crisi . John Wiley & Sons, New York 1998, ISBN 0-471-19713-0 . 
• Martin Fowler: Refactoring: migliorare la progettazione del codice esistente . Addison-Wesley, Reading / Massachusetts 1999, ISBN 0-201-48567-2 . 
• Joshua Kerievsky: Refactoring ai modelli . Addison-Wesley, Boston 2004, ISBN 0-321-21335-1 . 
• Bruce A. Tate: Bitter Java . Manning, Greenwich / Connecticut 2002, ISBN 1-930110-43-X . 
• Bruce A. Tate et al.: Bitter EJB . Manning, Greenwich / Connecticut 2003, ISBN 1-930110-95-2 . 
• Gerald M. Weinberg: Psicologia del programmatore . mitp, Bonn 2004, ISBN 3-8266-1465-8 . 

Guarda anche

• zucchero sintattico e sale
• colpa tecnica

• Controesempio - parola con significato simile, anche in altre aree specialistiche

link internet

• Definizione anti-pattern, Portland Pattern Repository (inglese)
• Catalogo anti-pattern, repository di pattern Portland (inglese)
• Bruce Eckel: Programmer Experience Clumping and Faux System Architects (inglese) ( Memento del 4 febbraio 2010 in Internet Archive )

Evidenze individuali

1. ↑ Frederick P. Brooks, Jr.: The Mythical Man-Month . Addison-Wesley, 1995 [1975].
2. ↑ Guido Stepken: Anti-Pattern nello sviluppo del software . (PDF; 315 kB)
3. ↑ ^{a b} Michael T. Nygard: Rilascialo! Progetta e distribuisci software pronto per la produzione . O'Reilly, 2007, ISBN 978-0-9787392-1-8 , Dipendenze tra sistemi: database (inglese, 326 pagine). 
4. ↑ AW Appel: implementazione moderna del compilatore in Java . Cambridge University Press, 1998
5. ↑ La Psicologia della Scienza: una ricognizione ; Inglese; di Abraham H. Maslow , pubblicato per la prima volta nel 1966 ( prima edizione, gennaio 1966 ) tramite HarperCollins- Verlag; 168 pagine; ISBN 0060341459 ( ISBN -10), ISBN 978-0060341459 (ISBN-13), vedi anche su Amazon.com (consultato il 31 gennaio 2020)
6. ↑ gestione di funghi. In: Dizionario Urbano . Estratto il 31 gennaio 2013 . 
7. ↑ Ancora un altro incontro lo risolverà. In: wiki.c2.com. 17 aprile 2011, consultato il 7 gennaio 2018 . 
8. ↑ Harold S. Geneen: Il caso della gestione dei numeri . Ed.: Fortuna. nastro 110 , n. 7 , 1984, pp. 78-81 . 
9. ↑ Programmatore interrotto. Ninlabs Research, 19 gennaio 2013, consultato l'8 febbraio 2013 . 
10. ↑ Chris Parnin, Spencer Rugaber: Strategie di ripresa per attività di programmazione interrotte. (PDF; 407 kB) 10 agosto 2010, consultato il 6 aprile 2016 (inglese). 
11. ↑ Shamsi T. Iqbal, Xianjun Sam Zheng, Brian P. Bailey: risposta pupillare evocata dal compito al carico di lavoro mentale nell'interazione uomo-computer. 2004, consultato l'8 febbraio 2013 . 
12. ↑ James Fogarty, Andrew J. Ko, Htet Htet Aung, Elspeth Golden, Karen P. Tang, Scott E. Hudson: esame dell'impegno del compito in modelli statistici basati su sensori di interrompibilità umana. 2005, consultato l'8 febbraio 2013 . 
13. ^ Il costo nascosto dell'interruzione dei knowledge worker. 5 ottobre 2009, accesso 8 febbraio 2013 .