Antywzór - Anti-pattern
Anty-wzorzec jest częstą odpowiedzią na powtarzającym się problemem, który zwykle nieskuteczne i istnieje ryzyko, że jest bardzo szkodliwe. Termin, ukuty w 1995 roku przez programistę komputerowego Andrew Koeniga , został zainspirowany książką Design Patterns , w której podkreślono szereg wzorców projektowych w tworzeniu oprogramowania, które autorzy uznali za wysoce niezawodne i skuteczne.
Termin ten został spopularyzowany trzy lata później w książce AntiPatterns , która rozszerzyła jego zastosowanie poza dziedzinę projektowania oprogramowania, aby nieformalnie odnosić się do każdego powszechnie wymyślonego na nowo, ale złego rozwiązania problemu. Przykłady obejmują paraliż analizy , programowanie kultu cargo , marsz śmierci , myślenie grupowe i uzależnienie od dostawcy .
Definicja
Według autorów Wzorców projektowych istnieją dwa kluczowe elementy antywzorca, które odróżniają go od złego nawyku, złej praktyki lub złego pomysłu:
- Antywzór jest powszechnie stosowanym procesem, strukturą wzorca działania, która mimo, że początkowo wydaje się właściwą i skuteczną reakcją na problem, ma więcej złych konsekwencji niż dobrych
- Istnieje inne rozwiązanie problemu, który próbuje rozwiązać antywzorzec, które jest udokumentowane, powtarzalne i okazuje się skuteczne tam, gdzie antywzorzec nie jest
Przykłady
Działalność społeczna i biznesowa
Organizacyjny
- Paraliż analityczny : projekt, który utknął w fazie analizy rozwoju i nie jest w stanie uzyskać wsparcia dla żadnego z potencjalnych planów jego realizacji
- Szopa na rowery : nadawanie nieproporcjonalnej wagi trywialnym problemom
- Krwawienie : praca z najnowocześniejszymi technologiami, które wciąż nie zostały przetestowane lub są niestabilne, co prowadzi do przekroczenia kosztów, niewystarczającej wydajności lub opóźnień w dostawie produktu
- Apatia świadka : zjawisko, w którym ludzie rzadziej lub nie oferują pomocy osobie w potrzebie, gdy inni są obecni
- Dojna krowa : rentowny starszy produkt, który często prowadzi do samozadowolenia z nowych produktów
- Projekt przez komisję : wynik posiadania wielu współtwórców projektu, ale brak jednoczącej wizji
- Eskalacja zaangażowania : Nie cofnięcie decyzji, gdy okaże się ona błędna
- Myślenie grupowe: zbiorowy stan, w którym członkowie grupy zaczynają, często nieświadomie, myśleć podobnie i odrzucać różne punkty widzenia
- Zarządzanie przez cele : Zarząd działający z wyłącznym naciskiem na ilościowe kryteria zarządzania, takie jak liczba sprzedaży, gdy są one nieistotne lub są zbyt drogie do pozyskania
- Mikrozarządzanie : nieefektywne wyniki wynikające z nadmiernej obserwacji, nadzoru lub innego praktycznego zaangażowania kierownictwa
- Ryzyko moralne : izolowanie decydenta przed konsekwencjami jego decyzji
- Zarządzanie grzybami : Utrzymywanie pracowników „w ciemności i karmienie obornikiem” (również „pozostawionych do gulaszu i wreszcie w puszkach”) o decyzjach podejmowanych przez kierownictwo
- Zasada Petera : Nieustanne awansowanie pracowników osiągających dobre wyniki na stanowisko, na które nie są oni przystosowani, z obowiązkami, których nie są w stanie wypełnić, gdzie pozostają na czas nieokreślony
- Zarządzanie Seagull : Zarządzanie, w którym menedżerowie wchodzą w interakcję z pracownikami tylko wtedy, gdy pojawia się problem, kiedy „wlatują, robią dużo hałasu, zrzucają na wszystkich, nie rozwiązują problemu, a potem wylatują”
- Stovepipe lub Silos : struktura organizacyjna izolowanych lub częściowo odizolowanych zespołów, w których zbyt wiele komunikacji odbywa się w górę i w dół hierarchii, a nie bezpośrednio z innymi zespołami w organizacji
- Typecasting : Blokowanie odnoszących sukcesy pracowników w nadmiernie bezpiecznych, wąsko zdefiniowanych, przewidywalnych rolach w oparciu o ich wcześniejsze sukcesy, a nie ich potencjał
- Uzależnienie od dostawcy : Nadmierne uzależnienie systemu od elementów dostarczanych z zewnątrz
Zarządzanie projektami
- Wózek przed koniem : Koncentracja zbyt wielu zasobów na etapie projektu poza jego kolejnością
- Marsz śmierci : projekt, którego pracownicy, oczekując, że się nie powiedzie, są zmuszeni kontynuować, często z dużym przepracowaniem, przez kierownictwo, które zaprzecza możliwej niepowodzeniu projektu
- Reguła dziewięćdziesiąt dziewięćdziesiąt : tendencja do niedoceniania czasu potrzebnego na ukończenie projektu, gdy jest on „prawie skończony”
- Nadmierna inżynieria : wydawanie zasobów, dzięki czemu projekt jest bardziej solidny i złożony niż jest to konieczne
- Pełzanie zakresu : niekontrolowane zmiany lub ciągły wzrost zakresu projektu lub dodawanie nowych funkcji do projektu po opracowaniu i zaakceptowaniu pierwotnych wymagań (znane również jako pełzanie wymagań i pełzanie funkcji )
- Smoke and mirrors : Demonstracja niezaimplementowanych funkcji, tak jakby były już zaimplementowane
- Prawo Brooksa : Dodanie większej ilości zasobów do projektu w celu zwiększenia prędkości, gdy projekt jest już spowolniony przez ogólne koszty koordynacji
- Pozłacanie : Kontynuacja pracy nad zadaniem lub projektem znacznie po przekroczeniu punktu, w którym dodatkowy wysiłek nie dodaje wartości
Inżynieria oprogramowania
Projektowanie Oprogramowania
- Odwrócenie abstrakcji : nieujawnianie zaimplementowanej funkcjonalności wymaganej przez wywołujące funkcję/metodę/konstruktora, tak że kod wywołujący niezręcznie ponownie implementuje tę samą funkcjonalność pod względem tych wywołań
- Niejednoznaczny punkt widzenia : Prezentacja modelu (zazwyczaj analiza i projektowanie zorientowane obiektowo (OOAD)) bez określania jego punktu widzenia
- Wielka kula błota : system bez rozpoznawalnej struktury
- Database-as-IPC : Używanie bazy danych jako kolejki komunikatów do rutynowej komunikacji międzyprocesowej, gdzie odpowiedni byłby znacznie lżejszy mechanizm
- Efekt platformy wewnętrznej : system tak konfigurowalny, że staje się słabą repliką platformy programistycznej
- Input kludge : Niepowodzenie w określeniu i zaimplementowaniu obsługi prawdopodobnie nieprawidłowych danych wejściowych
- Rozdęcie interfejsu : tworzenie interfejsu tak potężnego, że jest niezwykle trudne do wdrożenia
- Magiczny przycisk : formularz bez dynamicznej walidacji lub wspomagania wprowadzania danych, takich jak listy rozwijane
- Zagrożenie związane z wyścigiem : Niedostrzeżenie konsekwencji wydarzeń, które czasami mogą ze sobą kolidować
- System kominków : ledwo nadający się do utrzymania zespół źle powiązanych komponentów
Programowanie obiektowe
- Anemiczny model domeny : zastosowanie modelu domeny bez żadnej logiki biznesowej . Obiekty modelu domeny nie mogą zagwarantować ich poprawności w dowolnym momencie, ponieważ ich logika walidacji i mutacji jest umieszczona gdzieś na zewnątrz (najprawdopodobniej w wielu miejscach). Martin Fowler uważa to za antywzorzec, ale niektórzy nie zgadzają się, że zawsze jest to antywzorzec.
- Wywołaj super : wymaganie podklas do wywołania nadpisanej metody nadklasy
- Zagadnienie koło-elipsa : Podtypowanie typów zmiennych na podstawie podtypów wartości
- Zależność kołowa : wprowadzenie niepotrzebnych bezpośrednich lub pośrednich wzajemnych zależności między obiektami lub modułami oprogramowania
- Stały interfejs : Używanie interfejsów do definiowania stałych
- Bóg obiekt : Koncentracja zbyt wielu funkcji w jednej części projektu (klasa)
- Szamba obiektów : ponowne wykorzystanie obiektów, których stan nie jest zgodny z (prawdopodobnie niejawną) umową o ponowne użycie
- Orgia z obiektami : Niewłaściwa obudowa obiektów umożliwiająca nieograniczony dostęp do ich wnętrza
- Poltergeists : Obiekty, których jedynym celem jest przekazywanie informacji innemu obiektowi
- Sprzężenie sekwencyjne : klasa, która wymaga wywoływania jej metod w określonej kolejności
- Wzór Singleton : Ten wzór projektowy zapewnia sprzężenie i jest uważany za złe rozwiązanie
- Problem jojo : struktura (np. dziedziczenia), która jest trudna do zrozumienia z powodu nadmiernej fragmentacji
Programowanie
- Przypadkowa złożoność : zadania programistyczne, które można wyeliminować za pomocą lepszych narzędzi (w przeciwieństwie do podstawowej złożoności związanej z rozwiązywanym problemem)
- Działanie na odległość : Nieoczekiwana interakcja między szeroko oddzielonymi częściami systemu
- Kotwica łodzi : Zachowanie części systemu, która nie ma już żadnego zastosowania
- Zajęte oczekiwanie : Zużywanie procesora podczas oczekiwania na coś, co się wydarzy, zwykle przez wielokrotne sprawdzanie zamiast wysyłania wiadomości
- Błąd pamięci podręcznej : Zapomnienie o wyczyszczeniu pamięci podręcznej, która przechowuje wynik ujemny (błąd) po naprawieniu błędu
- Programowanie kultu ładunku : używanie wzorców i metod bez zrozumienia dlaczego
- Kodowanie przez wyjątek : Dodanie nowego kodu do obsługi każdego specjalnego przypadku, gdy jest rozpoznawany
- Wzorzec projektowy : samo użycie wzorców zostało nazwane antywzorcem, co oznacza, że system nie wykorzystuje wystarczającej abstrakcji
- Ukrywanie błędów : przechwytywanie komunikatu o błędzie, zanim zostanie on wyświetlony użytkownikowi i albo nic nie pokazuje, albo pokazuje nic nieznaczące wiadomości. Ten anty-wzór jest również nazywany wzorem pieluchy . Może również odnosić się do usuwania śladu stosu podczas obsługi wyjątków, co może utrudnić debugowanie.
- Twardy kod : Osadzanie założeń dotyczących środowiska systemu w jego implementacji
- Kod lasagny : programy, których struktura składa się ze zbyt wielu warstw dziedziczenia
- Przepływ lawy : zachowywanie niepożądanego (nadmiarowego lub niskiej jakości) kodu, ponieważ jego usunięcie jest zbyt kosztowne lub ma nieprzewidywalne konsekwencje
- Sekwencja przełącznika pętli : kodowanie zestawu kolejnych kroków za pomocą przełącznika w instrukcji pętli
- Liczby magiczne : w tym niewyjaśnione liczby w algorytmach
- Magiczne ciągi : implementacja prawdopodobnie mało prawdopodobnych scenariuszy wejściowych, takich jak porównania z bardzo konkretnymi ciągami, w celu zamaskowania funkcjonalności.
- Powtarzanie siebie : ponowne pisanie kodu, który zawiera powtarzające się wzorce i podciągi; unikaj raz i tylko raz (zasada abstrakcji)
- Shooting the messenger : zgłaszanie wyjątków z zakresu wtyczki lub subskrybenta w odpowiedzi na prawidłowe dane wejściowe, zwłaszcza gdy powoduje to awarię zewnętrznego zakresu.
- Chirurgia strzelby : programista dodaje funkcje do bazy kodu aplikacji, które obejmują wiele implementatorów lub implementacji w jednej zmianie
- Kod miękki : przechowywanie logiki biznesowej w plikach konfiguracyjnych zamiast w kodzie źródłowym
- Kod spaghetti : programy, których struktura jest ledwo zrozumiała, zwłaszcza z powodu niewłaściwego użycia struktur kodu
Metodologiczne
- Programowanie kopiowania i wklejania : Kopiowanie (i modyfikowanie) istniejącego kodu zamiast tworzenia ogólnych rozwiązań
- Złoty młotek : Zakładając, że ulubione rozwiązanie ma uniwersalne zastosowanie (Patrz: Srebrny pocisk )
- Wynalezione tutaj : tendencja do odrzucania wszelkich innowacji lub mniej niż trywialnych rozwiązań pochodzących z wewnątrz organizacji, zwykle z powodu braku zaufania do personelu
- Syndrom nie wynalezionego tutaj (NIH): tendencja do ponownego wymyślania koła (nieprzyjęcia istniejącego, adekwatnego rozwiązania)
- Przedwczesna optymalizacja : kodowanie na wczesnym etapie, aby uzyskać postrzeganą wydajność, poświęcając dobry projekt, łatwość konserwacji, a czasem nawet rzeczywistą wydajność
- Programowanie przez permutację (lub „programowanie przez przypadek” lub „programowanie przez przypadek”): próba podejścia do rozwiązania poprzez sukcesywną modyfikację kodu, aby sprawdzić, czy działa
- Ponowne wynalezienie koła kwadratowego : nieprzyjęcie istniejącego rozwiązania, a zamiast tego przyjęcie niestandardowego rozwiązania, które działa znacznie gorzej niż istniejące
- Srebrny punktor : Zakładając, że ulubione rozwiązanie techniczne może rozwiązać większy proces lub problem
- Tester-driven development : Projekty oprogramowania, w których nowe wymagania są określone w raportach o błędach
Zarządzanie konfiguracją
- Piekło zależności : Problemy z wersjami wymaganych produktów
- piekło DLL : nieodpowiednie zarządzanie bibliotekami dołączanymi dynamicznie (DLL), szczególnie w systemie Microsoft Windows
- Konflikt rozszerzeń : problemy z różnymi rozszerzeniami klasycznego systemu Mac OS podczas próby załatania tych samych części systemu operacyjnego
- JAR hell : Nadmierne wykorzystanie wielu plików JAR , zwykle powodujące problemy z wersjonowaniem i lokalizacją z powodu niezrozumienia modelu ładowania klas Java
Zobacz też
- Zapach kodu – objaw nieprawidłowego programowania
- Zapach projektowy
- Ciemny wzór
- Lista filozofii tworzenia oprogramowania – podejścia, style, maksymy i filozofie tworzenia oprogramowania
- Lista narzędzi do statycznej analizy kodu
- Oprogramowanie rot
- Oprogramowanie Peter zasada
- Model niedojrzałości zdolności
- ISO / IEC 29110 : Profile cyklu życia oprogramowania i wytyczne dla bardzo małych podmiotów (VSE)
- Dylemat innowatora
Bibliografia
Dalsza lektura
- Laplante, Phillip A.; Neill, Colin J. (2005). Antywzorce: Identyfikacja, Refaktoryzacja i Zarządzanie . Publikacje Auerbacha. Numer ISBN 0-8493-2994-9.
- Brown, William J.; Malveau, Raphael C.; McCormick, Hays W.; Thomas, Scott W. (2000). Hudson, Theresa Hudson (red.). Antywzorce w zarządzaniu projektami . John Wiley i Synowie . Numer ISBN 0-471-36366-9.