Antywzorzec (ang. anti-patternSłownik terminów testowych ISTQB, s. 8.) – przypadek powtarzających się, odkrywanych na nowo złych rozwiązań problemów. Badanie antywzorców zajmuje się ich rozpoznawaniem i porządkowaniem, tak aby można ich było uniknąć w przyszłości, a także aby można było je łatwo wykryć w wadliwie działających systemach.

Termin „antywzorzec” ma swoje źródło w informatyce, czerpiąc inspirację ze wzorców projektowych opracowanych przez Bandę Czworga, które zawierają przykłady dobrych praktyk programistycznych.

Według książki Browna, Malveau, McCormicka i Mowbraya antywzorce są naturalnym antonimem do wzorców. Do dobrych praktyk należy unikanie antywzorców.

Pojęcie to jest obecnie stosowane ogólnie do problemów inżynierskich. Jakkolwiek termin nie jest jeszcze szeroko używany, koncepcja antywzorca jest bardzo ogólna.

Antywzorce w zarządzaniu projektem Magiczna atrapa (ang. Smoke and mirrors, od triku magicznego): Antywzorzec dotyczy najczęściej oprogramowania, które nie ma zaimplementowanej funkcjonalności, chociaż udaje, że ją ma (np. niedziałające formularze, opcje konfiguracyjne). Termin ten używany jest także w kontekście prezentowania możliwości firmy-wykonawcy klientowi, tak, aby ten myślał, że firma jest w stanie wykonać zleconą pracę. Eksplozja oprogramowania (ang. Software bloat): Przydzielanie kolejnym wersjom oprogramowania coraz większej ilości zasobów z powodu jego nadmiernego rozrostu. Oprogramowanie jest często rozwijane przez dodawanie kolejnych funkcjonalności, bez ulepszania istniejących, co zwiększa zarówno jego wymagania, jak i liczbę osób potrzebnych do jego utrzymywania. Zarządzanie przez bzdury (ang. Bullshit Management): Zarządzanie projektem bez odpowiedniej wiedzy na temat przedmiotu projektu. Nazwa wzięła się od kierowników, którzy są przekonani, że aby dobrze zarządzać projektem nie trzeba mieć wiedzy, wystarczy sprawiać dobre wrażenie, wygłaszając mądrze brzmiące opinie. Ja nie jestem techniczny (ang. I’m not an IT guy): Przydzielanie zarządzania projektem osobie bez odpowiedniej wiedzy technicznej oraz doświadczenia w sposobie prowadzenia procesu rozwoju oprogramowania. Rozwój oprogramowania sprowadza się do podejmowania krytycznych decyzji o przesunięciu znaku graficznego logotypu o 5 pikseli w lewo bądź w prawo. Wszelkie kwestie związane z logiką biznesową prowadzone są z wykorzystaniem frazy „Ja nie jestem techniczny, ale czemu nie możemy zainstalować Windowsa na iPadzie?”. Kot (ang. newbie, dosł. nowicjusz; przyjęta polska nazwa wynika z nieoficjalnej nomenklatury wojskowej) wykonanie najbardziej krytycznych elementów projektu powierza się najmniej doświadczonej osobie z najmniejszym stażem pracy. Na tym etapie bym się tym nie przejmował (ang. We’ll handle it later): Antywzorzec najczęściej dotyczący projektów zarządzanych przez członków zespołu sprzedażowego. Sprzedawca, kierujący się chęcią szybkiego wdrożenia oprogramowania, nie zastanawia się nad technicznymi aspektami podejmowanych z klientem decyzji. Dba tylko o to, aby jak najszybciej zdobyć od klienta zlecenie utwierdzając zamawiającego w przekonaniu o wysokich kompetencjach firmy zdolnej do wdrożenia dowolnej funkcjonalności. W następstwie kierujący projektem sprzedawca ignoruje wszelkie próby wskazania zagrożeń płynących z wykonania uzgodnionych z klientem zmian w oprogramowaniu twierdząc, że na tym etapie nie ma potrzeby przejmowania się negatywnymi dla projektu konsekwencjami.

Antywzorce w projektowaniu oprogramowania Inwersja abstrakcji (ang. Abstraction inversion): Nieudostępnianie użytkownikom zaimplementowanej funkcjonalności, której potrzebują, przez co muszą ją zaimplementować ponownie używając funkcji wyższego poziomu. Niejednoznaczny punkt odniesienia (ang. Ambiguous viewpoint): Obiektowe modele systemu są prezentowane bez wskazania do czego się odnoszą (bez określenia w jakim kontekście są ukazane). Błotna bryła (ang. Big ball of mud): Dotyczy systemu o trudnej do wyodrębnienia i zrozumienia strukturze. Modyfikowanie takiego systemu jest ryzykowne, gdyż nie sposób przewidzieć skutków zmian, kod przypomina spaghetti. Złocenie (ang. Gold plating): Kontynuowanie pracy nad zadaniem lub projektem na długo po przekroczeniu punktu, w którym dodatkowy wysiłek przestaje przynosić wartość dodaną. Petrochemia (ang. Gas factory): Zbyt skomplikowany, uciążliwie drobiazgowy projekt systemu lub funkcjonalność. Wadliwe wejście (ang. Input kludge): Zachodzi gdy system nie radzi sobie z poprawnymi i niepoprawnymi danymi na wejściu, gdyż ich obsługa nie jest wyspecyfikowana i błędnie zaimplementowana. Zdarza się, że programista nie jest w stanie wykryć takiego błędu (ponieważ wiedząc, jakich danych potrzebuje program, wprowadza dane poprawne), natomiast użytkownik wykrywa go z łatwością przy pierwszym uruchomieniu (nie mając specyfikacji może podać dane dowolne, np. nazwę ulicy tam, gdzie miał być kod pocztowy). Interfejs gigant (ang. Interface bloat): Tworzenie rozbudowanych i ciężkich interfejsów (w sensie diagramu klas) tak, że trudno je zrealizować. Magiczny przycisk (ang. Magic pushbutton): Implementowanie zbyt ubogiego interfejsu użytkownika, bez pozwolenia mu na większą ingerencję w działanie programu. Silnie zależne komponenty (ang. Re-Coupling): Wprowadzanie nadmiernych zależności w systemie, tj. zbyt silnych powiązań komponentów, klas w systemie. System, który gra i tańczy (ang. Stovepipe system): Ciężko serwisowalny system zbudowany z komponentów niepowiązanych ze sobą (funkcjonalnie). System z wyścigami (ang. Race hazard): System, w którym źle zorganizowano obsługę zdarzeń i jego działanie jest zależne od ich kolejności.

Antywzorce w projektowaniu obiektowym BaseBean: Umieszczanie metod typu utility w klasie bazowej, a następnie tworzenie na jej podstawie klas pochodnych. Prawidłowo używanie metod utility powinno być obsłużone przez delegowanie. Użycie dziedziczenia powoduje, że klasy dziedziczące polegają na funkcjonalności klasy bazowej, co może utrudniać kontrolę kodu przez programistę. Klasy typu utility są za to stabilne i podobne do siebie w różnych projektach – można je wyodrębnić w bibliotekę. Wołanie przodka (ang. CallSuper): W programowaniu obiektowym możliwe jest dziedziczenie właściwości i zachowania klas bazowych i przedefiniowywanie ich. Często metoda, która przedefiniowuje metodę bazową musi się i tak odwołać do metody bazowej w środku, aby skorzystać z jej funkcjonalności – dużo lepszym pomysłem w takim przypadku jest stworzenie czysto abstrakcyjnej metody w klasie bazowej. Empty subclass failure: Złamanie kontraktu klasy nadrzędnej. Mówi się wówczas o niespełnieniu testu Empty Subclass Test to znaczy metody danej klasy nie zachowują się tak, jak te z klasy bazowej. Boski obiekt (ang. God object): Umieszczenie zbyt wielu funkcji w jednym komponencie (klasie). Obarczenie jej nadmierną odpowiedzialnością, co powoduje problemy w utrzymaniu jej kodu i wyodrębnieniu funkcjonalności. Object cesspool: Ponowne wykorzystywanie obiektów, których zachowanie zmienia się przy kolejnym użyciu. Może to być wynikiem braku automatycznego przywracania stanu obiektu przy zwracaniu go do puli obiektów. Poltergeists: Tworzenie obiektów, których jedynym zadaniem jest przekazywanie danych do innych obiektów. Jo-jo (ang. Yo-yo problem): Sytuacja, kiedy funkcjonalność jest rozłożona pomiędzy głęboką hierarchię dziedziczących się klas. Aby zrozumieć działanie programu programista musi przechodzić w tę i z powrotem pomiędzy definicjami klas. Większość praktyk programistycznych (w tym znany artykuł „Inheritance considered harmful”) zaleca stosowanie płytkiej hierarchii dziedziczenia. Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten jest przedmiotem wielu dyskusji – znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób. Sequential Coupling: Klasa wymaga, aby jej metody były wywoływane w określonej kolejności. Singletonizm (ang. Singletonitis): Niepotrzebne używanie wzorca singleton

Antywzorce w programowaniu Accidental complexity – wprowadzanie niepotrzebnej złożoności kodu Action at a distance – niespodziewana interakcja pomiędzy rozseparowanymi częściami systemu (np. poprzez zmienne globalne) Accumulate and fire (zgromadź i odpal) – przekazywanie argumentów do podprogramów przez zmienne globalne Blind faith (ślepa wiara) – niesprawdzanie wyników (a) słuszności poprawek w kodzie lub (b) wyników zwracanych przez podprogramy Boat anchor – zostawianie części systemu od dawna nieużywanego Busy spin – zajmowanie zasobów CPU przez aktywne czekanie (ciągłe sprawdzanie) na zdarzenie Caching failure – pozostawienie ustawionej flagi istnienia błędu w systemie już po obsłużeniu błędnej sytuacji Checking type instead of interface – sprawdzenie czy zmienna jest danego typu zamiast sprawdzenia czy implementuje potrzebny interfejs (błąd ten wyklucza korzystanie z polimorfizmu) Coding by exception (kodowanie przez wyjątki) – dodawanie nadmiernej liczby osobnych typów wyjątków dla każdego możliwego błędu oraz kodu do ich obsługi; prowadzi do niekontrolowanego wzrostu zbędnej złożoności (accidental complexity) Error hiding – przechwytywanie komunikatu o błędzie w celu ukrycia go przed użytkownikiem Sterowanie wyjątkami – używanie konstrukcji językowych służących do zarządzania błędami (wyjątkami) w celu implementacji właściwej logiki programu (np. zwracanie wyniku z funkcji przez wyrzucenie wyjątku) Hard code – „usztywnianie” rozwiązania przez wstawianie w wielu miejscach kodu programu ustalonych wartości, związanych z założoną strukturą systemu i jego środowiska (np. dotyczących systemu operacyjnego, liczby lub rodzaju procesorów, pojemności pamięci, wydajności bazy danych, rodzaju urządzeń wejścia-wyjścia) Lava flow (zalewanie przez lawę) – sytuacja, w której kod znajdujący się w fazie rozwoju zostaje włączony do produkcyjnej wersji systemu. Dzieje się tak np. w czasie zmian osobowych w zespole (nowa osoba nie jest świadoma tego, że przejmowany kod nie jest jeszcze ukończony). Ten wzorzec nazywa również sytuację, w której prototyp pewnej funkcjonalności (wytworzony np. w celu sprawdzenia technologii) zostaje włączony do systemu w wersji produkcyjnej. Kod ten jest niskiej jakości, nieprzemyślany, źle zaprojektowany. Jego usunięcie (zastąpienie) wymaga dużej pracy. Magic number (magiczna liczba) – użycie w kodzie stałych o niewyjaśnionym sensie i pochodzeniu, które „magicznie” sprawiają, że program działa prawidłowo. Magic string (magiczny napis) – użycie w kodzie literałów (nienazwanych stałych) łańcuchowych (napisowych) do porównań, np. jako nazwy typów danych, identyfikatorów zdarzeń itp. Packratting (Syllogomania) – nieuzasadnione zajmowanie dużych obszarów pamięci przez przetrzymywanie zbędnych danych Spaghetti code – kod, który na skutek używania złożonych struktur językowych (duże zagnieżdżenie instrukcji warunkowych, instrukcje goto itd.) jest nieczytelny i trudny do modyfikacji. Ravioli code – system z bardzo dużą ilością luźno powiązanych obiektów Anty-Mechanizm Duffa (ang. Loop-switch sequence lub for-case paradigm) – użycie instrukcji wyboru (np. switch) wewnątrz pętli zamiast prostych poleceńThe FOR-CASE paradigm .

Antywzorce metodyczne Copypasteryzm (ang. Copy and paste programming) – zamiast tworzyć ogólne rozwiązania, kopiuje się (i modyfikuje) istniejący kod.