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:

  1. 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
  2. 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

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ą

Zobacz też

Bibliografia

Dalsza lektura

  1. Laplante, Phillip A.; Neill, Colin J. (2005). Antywzorce: Identyfikacja, Refaktoryzacja i Zarządzanie . Publikacje Auerbacha. Numer ISBN 0-8493-2994-9.
  2. 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.

Zewnętrzne linki