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. Ú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.

Definíció

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.

Példák

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.

Általános példák

Szervezeti

• 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.
• 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.

Projektmenedzsment

• 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.
• 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.

Szoftverfejlesztés

Tervezés

• 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.

Objektumorientált programozás

• 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. 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.

Megvalósítás

• 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. 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.
• 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.
• Spagetti kód: nehezen követhető, ömlesztett, szerkezet nélküli vagy szerkezetét elleplező program.

Módszertan

• 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.
• 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.

Konfiguráció

• 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.

Források

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

Fordítás

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.