Antiminta

A számítógép-programozásban egy antiminta válasz egy visszatérő problémára, de nem hatékony és kontraproduktív.^[1][2] Újra és újra előforduló, nyilvánvaló, de rossz megoldások. Az elnevezést Andrew Koenig alkotta egy 1995-ben megjelent írásában. A kifejezést a Design Patterns könyv ihlette, ami gyakori jó, azaz hatékony, átlátható, megbízható megoldásokat mutat be.

Három évvel később megjelent az AntiPatterns könyv, ami kiterjesztette a jelentést, és általánosabban minden gyakran előforduló, de rossz megoldásra vonatkoztatta. Erre példák az analízisparalízis, cargo cult programozás, halálmenet, csoportgondolkodás és terjesztőtől való függés.

A Design Patterns szerzői szerint legalább két kulcsfontosságú jellemző különbözteti meg az antimintát a rossz ötlettől, szokástól vagy gyakorlattól:

• Akciók gyakran használt folyamata, szerkezete vagy mintája, ami több rossz, mint jó következménnyel jár annak ellenére, hogy kezdetben megfelelő és hatékony válasz egy problémára.
• Létezik más dokumentált, bizonyítottan hatékony és ismételhető megoldás.

Mivel az antiminták fogalmát nemcsak a programtervezésben használják, azért a továbbiakban több más területről is bemutatunk példákat.

• Analízisparalízis: Az elemzés szakaszban elakad a projekt, mivel egyik potenciális megközelítés vagy terv sem nyer elegendő támogatást.
• Trivialitás törvénye: Triviális ügyeknek aránytalanul nagy fontosságot tulajdonítanak.
• Vérző él: Új, még kiforratlan technológiák használata, ami megnöveli a költségeket, gyengébb performanciát okoz, és lehetetlenné teszi a határidők betartását.
• Járókelő-effektus: Emberek kevésbé hajlamosak segíteni, ha más is segíthetne.
• Aranytojást tojó tyúk: Jövedelmező már meglevő termék, ami idegenkedést okoz vagy túlzott elvárásokat támaszt az új termékekkel szemben.
• Bizottság általi tervezés: Sokan vesznek részt a tervezésben, és az eredménynek nincs egységes koncepciója.
• Merevség: Hibásnak bizonyult döntés megtartása.
• Csoportgondolkodás: A csapat tagjai ugyanúgy kezdenek el gondolkodni, és mindenki igazodik a közös véleményhez, akár tudattalanul is.
• Eredményalapú menedzsment: Kizárólag számadatokra, mennyiségi kritériumokra támaszkodó menedzsment, amikor vannak más fontosabb tényezők is, vagy túl sokba kerül az adatok megszerzése.
• Mikromenedzsment: A vezetés túl sokat foglalkozik a beosztottak munkájának megfigyelésével és ellenőrzésével, ezzel rontja annak hatékonyságát.
• Morális hazárd: A döntéshozók elszigetelése döntésük következményeitől.
• Gomba menedzsment: Csak azokat az információkat közlik a beosztottakkal, amiket szükségesnek látnak, elszigetelve őket a megrendelőtől. Megfogalmazások szerint sötétben tartani és trágyázni; avagy hagyni főni a levest, és végül palackozni.
• Peter-elv: Jól teljesítő munkavállalók előléptetése egy olyan szintre, aminek már nem tudnak megfelelni, és határozatlan ideig megtartani abban a pozícióban.^[3]
• Sirály menedzsment: A vezetők csak akkor lépnek kapcsolatba a beosztottakkal, ha valami probléma adódik. Ekkor berepülnek, zajt csapnak, mindenkire rápiszkítanak, nem oldják meg a problémát, és kirepülnek.
• Kályhacső szerkezet: Korlátozzák a kommunikációt, ennek következtében inkább a hierarchia szerint felfelé illetve lefelé mozognak az információk, és nem közvetlenül oda kerülnek, ahova szánták őket.
• Beskatulyázás: A beosztottakat pontosan definiált, szűkre szabott megjósolt szerepekre korlátozzák múltbéli teljesítményük, és nem a bennük levő potenciál alapján.
• Terjesztőtől való függés: A rendszer kizárólagosan függ egy külső komponenstől, aminek helyettesítése sok munkát igényel.

• Kocsi a ló elé: Túl sok erőforrást fordítanak a projekt egy olyan részére, ami még nincs soron.
• Halálmenet: A vezetés tagadja, hogy a projekt bukni fog, amit a csapat már előre lát. Erőforrásokat fektet bele a projektbe, és elvárja, hogy tovább dolgozzanak rajta, akár plusz munka befektetéssel is.^[4]
• Kilencven-kilencven szabály: A projekt befejezéséhez szükséges idő alábecslése, amikor a projekt már majdnem kész.
• Túltervezés: Sokkal több erőforrás befektetése, amitől a termék robosztusabb és komplexebb lesz, mint amilyennek lennie kellene.
• Túlterjeszkedés: Miután elfogadták az eredeti követelményeket, ellenőrizetlen változásokat és új képességeket vezetnek be.
• Füst és tükrök: Még nem megvalósított funkciók késznek mutatása.
• Brooks-törvény: Több erőforrás adása egy olyan projektnek, ami a koordináció miatt lassult le.

• Absztrakció megfordítása: A kliensnek szüksége lenne egy olyan függvényre, ami már meg van valósítva az objektumban, de nem nyilvános vagy nem szerepel az interfészben. Így a kliens arra kényszerül, hogy ő is megvalósítsa a függvényt.
• Nem egyértelmű nézőpont: A modell bemutatásából hiányzik a nézőpont meghatározása.
• Nagy sárlabda: Egy nagy, felismerhető szerkezet nélküli rendszer.
• Adatbázis mint IPC: A folyamatok közötti kommunikációt egy adatbázis közvetíti, amikor lenne lehetőség könnyebb mechanizmusra.
• Az arany aranyozása: Tovább dolgozni egy olyan feladaton vagy projekten, amikor a munkabefektetés már nem jár további érték hozzáadásával.
• Belsőplatform-hatás: A rendszer olyan konfigurálhatóvá válik, mint egy keretrendszer szegényes másolata.
• Maszatos bemenet: A jó és rossz bemenet megkülönböztetésének hiánya, miközben a program nem tud minden bemenetre megfelelő választ adni.
• Interfész felfúvódása: Egy interfészt annyira elbonyolítanak, hogy nehéz lesz implementálni.
• Mágikus gomb: Kérdőív, grafikus felület dinamikus validáció vagy bemeneti segédlet, például lenyíló menük és súgók nélkül.
• Hazárdfutam: Különböző, egymásra ható események következményeinek fel nem mérése.
• Kályhacső rendszer: Tisztázatlan módon összetartozó komponensek nehezen fenntartható halmaza.

• Vérszegény tárgyköri modell: A tárgyköri modell nem tartalmaz üzleti logikát. A tárgyköri objektumok sosem tudják garantálni korrektségüket, mivel érvényességük és változásuk logikája máshol van elhelyezve, általában több helyen. Martin Fowler ezt antimintának tekinti, bár van, aki ezt vitatja.^[5] Mindenesetre szembemegy az objektumorientációval.
• Felfelé hívás: Megkövetelni a leszármazottaktól, hogy hívják meg az alaposztály valamelyik metódusát, amit ők felüldefiniáltak.
• Kör-ellipszis probléma: Matematikailag a kör az egy speciális ellipszis. Ha azonban ez alapján készülnek az osztályok, akkor gond adódhat, ha az ellipszis tengelyei változhatnak. Mi lesz, ha csak az egyik tengelyt változtatják meg?
• Körkörös függőség: Szükségtelen közvetlen vagy közvetett függőségek bevezetése objektumok vagy modulok között.
• Konstans interfész: Interfész, aminek egyetlen feladata, hogy konstansokat definiáljon.
• Isten osztály: Mindenható vagy mindentudó osztály. Ez végzi az összes működést, vagy ez tud mindent, és az objektumok minden adatot tőle kérnek le.
• Kifogyó objektumkészlet: A készletből olyan objektumok kerülnek elő, melyeknek állapota nem megfelelő.
• Objektumtobzódás: Az objektumok korlátlan hozzáférést engednek tartalmukhoz.
• Kopogószellem: Egyetlen feladata az információátadás.
• Szekvenciális csatolás: Egy osztály metódusait csak adott sorrendben lehet hívni, különben a program nem az elvárt módon viselkedik.
• Jojó probléma: A szem jojózik ez erős töredezettség miatt.

• Pótlólagos bonyolultság: Jobb eszközökkel kiküszöbölhető feladatok megoldása.
• Távoli akció: A rendszer egyes távoli részei között nem várt kapcsolatok jönnek létre.
• Hajóhorgony, féregnyúlvány: Megtartani olyan részeket, amelyek már semmire sem valók.
• Busy waiting: Ciklikusan újra és újra rákérdezni, hogy egy esemény bekövetkezett-e, ahelyett, hogy üzenetre várnánk.
• Cachelési hiba: A cache-ek ki nem ürítése, emiatt a cache-ekben megőrződhetnek korábban már javított hibákra vonatkozó üzenetek.
• Cargo cult programozás: Módszerek és minták használata azok megértése nélkül.
• Programozás kivételekkel: Specifikus kivételek használata különböző hibák kezelésére.
• Programtervezési minták túlzott használata: A minták használata azt jelezheti, hogy vagy nincs elég absztrakció betervezve, vagy hogy nem a megfelelő nyelvet vagy paradigmát választották a probléma megoldására.^[6] Például ahelyett, hogy a nyelv funkcionális képességeit használnák, ezt a feladatot a látogató programtervezési mintával oldják meg; vagy tervezéskor egy olyan nyelvet választanak, amiben nincs többszörös öröklődés, aztán kiderül, hogy mégis kell, így az ikrek mintát használják.
• Hiba elrejtése: A hibák elkapása azok megmutatása nélkül, és üres vagy semmitmondó üzenet kiíratása. Ugyanez vonatkozik a verem elrejtésére is.
• Kemény kód: Feltételezések a rendszer környezetéről.
• Lasagna kód: Túl sok réteg a programban, főként öröklődésben.
• Lávafolyam: A nemkívánatos kód (redundáns, vagy rossz minőségű) nem távolítható el vagy nem helyettesíthető, mivel annak következményei megjósolhatatlanok.^[7][8]
• Loop-switch szekvencia: Egy ciklus belsejében switch használata arra, hogy szekvenciát hozzanak létre.
• Varázsszámok: Tisztázatlan jelentésű számok.
• Varázsszavak: Feltehetően ritkán előforduló bemenet feltételezése, például stringek összeghasonlítása. Ez elleplezi a valódi funkcionalitást.
• Önmagad ismétlése: Ismétlődő minták és részsstringek; elkerülhető az egyszer és csak egyszer absztrakciós elvvel.
• Sörétespuska-sebészet: Olyan változások bevezetése, amik egy lépésben sok helyen módosítanak.
• Puha kód: Az üzleti logika kiszervezése konfigurációs fájlokba.^[9]
• Spagetti kód: nehezen követhető, ömlesztett, szerkezet nélküli vagy szerkezetét elleplező program.

• Másol-beillesztéses programozás: Létező kód másolása és módosítása általános megoldások helyett.
• Minden bolondnak a maga eszköze: A fejlesztést támogató eszközök létrehozásakor nem követik a programfejlesztési módszertanokat.^[10]
• Arany kalapács: Az a feltételezés, hogy a kedvenc megoldás mindenütt alkalmazható.
• Valószínűtlenségi faktor: Az a feltételezés, hogy egy hiba nagyon kis valószínűséggel fordul elő.
• Mi találtuk fel: Egy már létező megoldás bármely nem triviális megváltoztatására tett kísérlet elutasítása, mivel a főnökség nem bízik a beosztottakban.
• Nem mi találtuk fel: Sikertelen próbálkozás egy már létező megoldás használatára, emiatt saját megoldás használata. Lásd: Kerék feltalálása.
• Korai optimalizáció: A kód korai optimalizálása a feltételezett hatékonyságra, és ennek érdekében minden más feláldozása (tervezés, érthetőség, fenntarthatóság, és valódi hatékonyság).
• Próba-szerencse programozás: A program változtatgatása elaprózott lépésekben, hogy lássuk, hogy működik.
• Csodaszer: Annak feltételezése, hogy egy kedvenc technikai megoldás meg tud oldani minden problémát.
• Tesztelővezérelt fejlesztés: A projektben az új elvárásokat a hibajelentésekből kell kiolvasni.

• Verziópokol: Valamelyik függőségnek nincs legjobb verziója. Az egyik verzióban ez, a másikban az a jó, és nem lehet több verziót együtt használni.
• DLL pokol: A DLL-ek (dinamikus linkelésű könyvtárak) nem megfelelő menedzselése, különösen Windowson.
• Kiterjesztések konfliktusa: A klasszikus Mac OS kiterjesztéseinek problémája, ahol is nem használhatók együtt azok a kiterjesztések, amelyek a rendszernek ugyanazt a hibáját küszöbölik ki.
• JAR pokol: a Java betöltési modell félreértése miatt több JAR fájl túlhasználata, ami verziókezelési és lokációs problémákat okoz.

• Minták, antiminták, refaktorálás, UML

Ez a szócikk részben vagy egészben az Anti-pattern című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.