Wikipédia

Antiminta

(Antiminták szócikkből átirányítva)

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.

Definíció szerkeszté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.

Példák szerkeszté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.

Általános példák szerkesztés

Szervezeti szerkesztés

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

Projektmenedzsment szerkesztés

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

Szoftverfejlesztés szerkesztés

Tervezés szerkeszté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 szerkeszté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.[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.

Megvalósítás szerkeszté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.[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ódszertan szerkesztés

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

Konfiguráció szerkesztés

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

Jegyzetek szerkesztés

  1. ↑ Budgen, D.. Software design. Harlow, Eng.: Addison-Wesley, 225. o. (2003). ISBN 0-201-72219-4  "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
  2. ↑ Scott W. Ambler. Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press, 4. o. (1998). ISBN 0-521-64568-9  "...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."
  3. ↑ Peter, Lawrence J. (1969), The Peter Principle: Why Things Always Go Wrong; 1969 Buccaneer Books, ISBN 9781568491615
  4. ↑ Yourdon, Edward (1997), Death March; ISBN 978-0137483105
  5. ↑ The Anaemic Domain Model is no Anti-Pattern, it’s a SOLID design. SAPM: Course blog , 2014. február 4. (Hozzáférés: 2015. január 3.)
  6. ↑ Revenge of the Nerds. „In the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough— often that I'm generating by hand the expansions of some macro that I need to write.”
  7. ↑ Lava Flow at antipatterns.com
  8. ↑ Undocumented 'lava flow' antipatterns complicate process. Icmgworld.com, 2002. január 14. [2011. március 11-i dátummal az eredetiből archiválva]. (Hozzáférés: 2010. május 3.)
  9. ↑ Papadimoulis, Alex: Soft Coding. thedailywtf.com, 2007. április 10. (Hozzáférés: 2011. június 27.)
  10. ↑ https://www.linkedin.com/pulse/every-fool-his-own-tool-marcel-heemskerk-msc-scea

Források szerkesztés

Fordítás szerkeszté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.

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Antiminta&oldid=26128191”