Antywzorzec projektowy

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacji, wyszukiwania

Antywzorce (ang. Anti-patterns, Pitfalls) – przypadki 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 aplikowane ogólnie do problemów inżynierskich, obejmując wszelkie inne aspekty inżynierii z udziałem człowieka. Jakkolwiek termin nie jest jeszcze szeroko używany, koncepcja antywzorca jest bardzo ogólna.

Antywzorce w zarządzaniu projektem[edytuj | edytuj kod]

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

Antywzorce w projektowaniu oprogramowania[edytuj | edytuj kod]

  • Zmiana funkcjonalności, 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 jest przewidzieć skutków zmian, kod przypomina spaghetti.
  • 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. Często jest tak, że programista nie jest w stanie wykryć takiego błędu, natomiast użytkownik wykrywa go z łatwością przy pierwszym uruchomieniu.
  • Interfejs gigant (ang. Interface bloat): Tworzenie rozbudowanych i ciężkich interfejsów (w sensie diagramu klas) tak, że stają się one ciężkie do implementacji.
  • Magiczny przycisk (ang. Magic pushbutton): Implementowanie zbyt ubogiego interfejsu użytkownika, bez pozwolenia mu na większą ingerencję w działanie programu. Zachodzi najczęściej wtedy, gdy programista najpierw wyklikuje interfejs użytkownika, a później go oprogramowuje. Zazwyczaj kod, który stoi za funkcjonalnością przycisku dotyczy tylko tego przycisku (np. jest napisany w funkcji onClick), jest bardzo rozbudowany i trudno go wykorzystać w innych miejscach interfejsu.
  • Silnie zależne komponenty (ang. Re-Coupling): Wprowadzanie zbyt silnie powiązanych 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 (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[edytuj | edytuj kod]

  • 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 wypadku jest stworzenie czysto abstrakcyjnej metody w klasie bazowej.
  • Empty subclass failure: Złamanie kontraktu klasy nadrzędnej. Mówi się wówczas o nie speł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 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[edytuj | edytuj kod]

  • 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 – wstawianie wyników podprocedur do zmiennych globalnych
  • Blind faith – niesprawdzanie rezultatow napisanego kodu
  • Boat anchor – zostawianie części systemu od dawna nieużywanego
  • Busy spin – zużywanie zasobów CPU przy czekaniu na zdarzenie (zwykle poprzez permanentne sprawdzanie zamiast zdarzeniowo)
  • Caching failure – pozostawienie ustawionej flagi istnienia błędu w systemie już po obsłużeniu błędnej sytuacji
  • Checking type instead of interface
  • Code momentum
  • Coding by exception – wstawianie kodu do obsługi wszystkich wyjątków
  • 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 – wstawianie do kodu programu wartości, które mogłyby być potencjalnie modyfikowalne przez użytkownika
  • Lava flow – 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 – użycie w kodzie stałych o niewyjaśnionym sensie i pochodzeniu. Przykładem wystąpienia tego antywzorca jest użycie stałej, której nazwa nic nie mówi o jej przeznaczeniu, a komentarze nie wyjaśniają sensu jej użycia. W efekcie tego działania posiadamy w kodzie magiczną liczbę, której przeznaczenia nikt nie zna.
  • Magic string
  • Packratting
  • 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.
  • Superboolean logic
  • Ravioli code – system z bardzo dużą ilością luźno powiązanych obiektów
  • Loop-switch sequence

Antywzorce metodyczne[edytuj | edytuj kod]

  • Copypasteryzm (ang. Copy and paste programming) – zamiast tworzyć ogólne rozwiązania, kopiuje się (i modyfikuje) istniejący kod
  • Programowanie przez permutację (ang. programming by permutation) – próba rozwiązania problemu przez konsekwentne zmiany w kodzie (bez przemyślenia sprawy i zrozumienia problemu), do czasu aż program zadziała.
  • De-factoring – proces zastępowania funkcjonalności dokumentacją
  • Złoty młotek (ang. golden hammer) – faworyzowanie jednej technologii w celu rozwiązania wszystkich problemów, również tych, dla których istnieją znacznie lepsze metody.
  • Silver bullet – założenie, że sprawdzone rozwiązanie techniczne musi być zawsze skuteczne przy rozwiązaniu znacznie większego problemu
  • Czynnik nieprawdopodobieństwa (ang. improbability factor) – założenie, że nie jest prawdopodobne, aby znany błąd się ujawnił w działaniu
  • Przedwczesna optymalizacja (ang. premature optimization) – optymalizacja na podstawie niedostatecznego zbioru danych
  • Ponowne odkrywanie koła (ang. Reinventing the wheel)
  • Odkrywanie kwadratowego koła (ang. Reinventing the square wheel) – rozwiązywanie problemu w zły sposób, podczas gdy istnieją skuteczne i sprawdzone rozwiązania. Na przykład tworzenie własnego systemu bazodanowego, zamiast wykorzystania istniejących darmowych rozwiązań, z dużym prawdopodobieństwem lepszych niż sami jesteśmy w stanie stworzyć.
  • U mnie działa – ignorowanie problemu powstałego na pewnej instalacji systemu ponieważ problem ten nie wystąpił na innej instalacji
  • Rozwój inicjowany podczas testowania – rozwój oprogramowania, w którym nowe wymagania definiowane są w raportach o błędach

Antywzorce w zarządzaniu konfiguracją (Configuration management)[edytuj | edytuj kod]

  • Piekło zależności (ang. Dependency hell) – problem z zależnościami wymaganych wersji produktów. Występuje szczególnie na systemach Unix/Linux.
  • Piekło DLL (ang. DLL hell) – problem z zależnościami, dostępnością lub mnogością dynamicznie łączonych bibliotek DLL. Występuje w systemie Microsoft Windows, oraz wszelkich produktach, mających go emulować, lub obsługiwać programy zgodne z nim.
  • Piekło JAR (ang. JAR hell) – problem z niezgodnością wersji lub lokalizacji plików JAR. Najczęściej spowodowany niezrozumieniem modelu ClassLoader’a.
  • Konflikt rozszerzeń (ang. Extension conflict) – problem z niezgodnością rozszerzeń dla systemu Mac OS, usiłujących załatać ten sam fragment systemu operacyjnego.

Niektóre antywzorce organizacyjne[edytuj | edytuj kod]

  • Paraliż analityczny (ang. Analysis paralysis): zjawisko to zachodzi wtedy, gdy koszty poniesione na analizę decyzji przekraczają korzyści wynikające z podjęcia tej decyzji. Często analiza zagadnienia zagłębia się do takiego poziomu szczegółowości, że trudno jest ją ogarnąć, zidentyfikować problemy, a kontekst zagadnienia jest tracony. W przypadku projektów programistycznych zjawisko to objawia się nieproporcjonalnie długim czasem poświęconym na zbieranie wymagań, projektowanie systemu, bez żadnej wartości dodanej z poświęcenia tego dodatkowego czasu. Paraliż analityczny może być skutkiem zbyt biurokratycznego i zbyt drobiazgowego podejścia do problemu, często spowodowany jest brakiem doświadczenia projektantów i kierowników, lub potrzebą spełnienia wymogów korporacyjnych (np. wypełnienia odpowiednich szablonów dokumentów), metodologicznych (forsowania zbędnych kroków w metodologii, analiza zjawisk poza zakresem systemu wymuszona metodologią – w powiązaniu z antywzorcem: rozmycia zakresu) etc.
  • Dojna krowa (ang. Cash cow): Znane z marketingu (macierz wzrostu-udziałów Boston Consulting Group) pojęcie określające bardzo dochodowy produkt, w rynku sprzedaży którego firma ma duży udział, jest zarazem nazwą antywzorca. Jest nim wtedy gdy firma skupiająca swoją uwagę na sprzedaży dochodowego produktu, nie pracuje jednocześnie nad nowymi produktami. Dochodowy produkt może w niedługim czasie okazać się przestarzały, a firma z powodu braku nowości wypadnie z rynku.
  • Ciągła przestarzałość (ang. Continuous obsolescence): Zjawisko, kiedy firma poświęca więcej uwagi na przenoszenie istniejącego systemu na nowe platformy i środowiska, niż nad poprawą jego funkcjonalności. Nazwa została stworzona przez analogię z pojęciem Ciągła integracja (ang. Continous Integration).
  • Cost migration
  • Creeping featurism
  • Design by committee Efekt pracy projektowej wielu osób, z których każda chciała wnieść swój wkład do wyniku prac. W efekcie otrzymujemy niespójny projekt, który opisuje poszczególne części systemu, brak w nim jednej spójnej wizji całości.
  • Escalation of commitment
  • I told you so
  • Zarządzanie przez wskaźniki (ang. management by numbers) Przykładanie nadmiernej uwagi do liczb, wskaźników, metryk itd. jako środka do zarządzania projektem. Następuje tutaj pominięcie innych istotnych, niekoniecznie mierzalnych czynników wpływających na postępy prac (np. morale załogi) i przyszłe wyniki
  • Management by perkele
  • Uprawa pieczarek (ang. Mushroom management): Styl zarządzania podobny do uprawy pieczarek. Pieczarki trzymane są w ciemnościach, w oborniku (ang. bullshit), a gdy trochę urosną – obcina się im głowy. W zarządzaniu przekłada się to na podejmowanie decyzji bez konsultacji z personelem, którego dotyczą te decyzje, lub wręcz nie informowanie personelu aż do czasu, gdy decyzje zapadną i będą odczuwalne. Zjawisko spotykane jest najczęściej w organizacjach o hierarchicznej strukturze, z barierami komunikacyjnymi pomiędzy poszczególnymi szczeblami. Antywzorzec ten dotyczy także projektów informatycznych, a dokładniej braku komunikacji pomiędzy klientami lub architektami systemu, a programistami, którzy implementują system. Programiści nie mają bezpośredniego kontaktu z klientem i mogą polegać tylko na stworzonej dokumentacji, która z kolei jest często traktowana niezobowiązująco przez klienta (np. klient traktuje ją „po macoszemu”, jako zło konieczne).
  • Rozpłynięcie zakresu (ang. Scope creep): Powstaje na ogół wtedy, gdy zakres projektu nie jest poprawnie określony, dokumentowany i kontrolowany (na skutek braku zarządzania zmianami, braku określenia co jest celem projektu, słabego lub bezsilnego kierownika projektu). Zakres projektu podlega niekontrolowanym zmianom, a zespół zbacza z początkowo określonego kierunku. Powoduje to, że w projekcie wykonywane są inne czynności, niż przewidziane w opracowanym na początku budżecie i harmonogramie. Na ogół zakres projektu powiększa się, co powoduje, że w uprzednio zaplanowanym czasie próbuje się wykonać więcej czynności.
  • Stovepipe
  • Uzależnienie od dostawcy (ang. Vendor lock-in): Sytuacja, w której klient jest uzależniony od produktów dostawcy do tego stopnia, że nie może zmienić dostawcy bez poniesienia kosztów zmiany. W przypadku oprogramowania termin ten odnosi się do niemożności wymiany komponentu oprogramowania na inny z powodu ich niekompatybilności. Dostawcy oprogramowania tworzą często różne architektury, interfejsy systemów, które uniemożliwiają łatwą migrację. Często taka sytuacja wynika także z błędnego zaprojektowania systemu. Może się zdarzyć, że niekompatybilność komponentów jest celowym zamierzeniem dostawcy, który z uzależnienia nabywcy czerpie korzyści – w modelu biznesowym powiązanych produktów (ang. razor and blades) dostawca sprzedaje główny produkt (np. maszynkę do golenia, drukarkę, telefon) po zaniżonej cenie, po to, aby czerpać korzyści ze sprzedaży komponentów które do niego pasują (np. ostrzy, wkładów, abonamentu).
  • Violin string organization

Bibliografia[edytuj | edytuj kod]