Czy istnieje formalny anty-wzór opisujący scenariusz?

Część kodu została napisana w celu wygenerowania arkuszy kalkulacyjnych Excel (Office Interop).

• Kod działa bardzo słabo.
  
  • Podsystem jest zaprojektowany do generowania plików w nocy. Wydajność nie jest problemem w nocy.
    • Utworzono funkcję wyboru poprawnego pliku ze 100 różnych dostępnych plików w zależności od wybranego zestawu parametrów.
    • Ponieważ istnieją pliki fizyczne, do archiwizacji tych plików dodano system archiwizacji (nie ma powodu do archiwizacji. Pliki te należy generować w locie).
    • Ten system nie zawiera pliku konfiguracyjnego, zamiast tego ma zakodowaną na stałe funkcję „wyboru serwera”, która po prostu odzwierciedla serwer, na którym działa kod.
    • Zaplanowane zadanie jest niezbędne do obsługi i uruchomienia tej usługi.

Sprowadza się to do jednego problemu. Oryginalny kod działa zbyt słabo, aby działał w środowisku produkcyjnym.

Gdyby problem wydajności został rozwiązany, podsystem, a następnie system archiwizacji, „funkcja fabryczna próbnika plików”, zakodowany na stałe punkt awarii oraz utrzymanie zaplanowanego zadania i jego dodatkowego punktu awarii nie muszą istnieć.

Jeśli to zrobisz, jest to „awaria kaskadowa”. Pierwotny problem spowodował więcej złego kodu, więcej złych rozwiązań i niepotrzebne koszty ogólne. Czy istnieje formalny anty-wzór lub ogólny termin na opisanie go?

Lawa, strumień lawy?

W żargonie programowania komputerowego przepływ lawy jest problemem, w którym kod komputerowy napisany w nieoptymalnych warunkach jest wprowadzany do produkcji i dodawany, gdy jest jeszcze w stanie rozwojowym.

Z Perl Design Wiki: Lava Flow jest „gdy kod ... wytryskuje i staje się trwały, staje się architektoniczną cechą różnorodności archeologicznej. Rzeczy buduje się na strukturze bez pytania i bez nadziei na zmianę tego, co pod nią. istniejący kod jest postrzegany jako historyczna ciekawość ”.

Często wprowadzenie systemu do produkcji powoduje konieczność zachowania kompatybilności wstecznej (ponieważ wiele dodatkowych komponentów jest od niego zależnych) z oryginalnym, niekompletnym projektem.

Przepływy lawy są często zaostrzone przez zmiany w zespole programistycznym pracującym nad projektem. Gdy pracownicy wchodzą i wychodzą z projektu, wiedza na temat celu aspektów systemu może zostać utracona, a zamiast posprzątać te elementy, są one omijane, co zwiększa złożoność i bałagan systemu.

Przepływ lawy jest uważany za anty-wzór, często spotykane zjawisko prowadzące do złego projektowania.

Nie jestem pewien, czy to jest anty-wzór. Podobnie jak w przypadku wszystkich anty-wzorów, musimy wierzyć słowom, że ktokolwiek myślał, że to dobry pomysł, mylił się, ale w tym przypadku brzmi to prawdopodobne i uwierzę ci na słowo, więc to nie jest problem.

Problem polega na tym, że aby anty-wzorzec był użyteczny, należy opisać pewien ogólny pułapkę i sposoby jego uniknięcia. W tym przypadku wydaje mi się, że byłoby to obejście problemu dla kodu, który działa źle, gdy można go po prostu poprawić.

Problem z tym jako anty-wzorem, IMHO, polega na tym, że znajomość tego wydaje się mało cenna. Ktokolwiek to zrobił, prawdopodobnie już zrozumiał, że byłoby miło wiedzieć, jak sprawić, by działał lepiej, więc nie mogli wiedzieć, jak to zrobić. Więc usłyszenie o ogólnej sytuacji jako anty-wzór naprawdę by nie pomogło.

Jeśli chodzi o ogólny termin, aby to opisać, „kaskadowa awaria”, jak sugerowałeś, działa całkiem dobrze. Termin, który lubię w przypadku osób niewykwalifikowanych na misję, która nie miała sensu, to przede wszystkim polowanie na snarki , ale wydaje się to zbyt surowe w tej sytuacji. (Ale i tak nieco podrzucę link, ponieważ jest to najlepsze przedstawienie skazanego na zagładę przedsięwzięcia, jakie znam).

Nie jestem pewien, czy to pomaga, ale automatyzacja biura jest często szczególnym przypadkiem:

Automatyzacja biura jest zwykle wykonywana w ten sposób, jeśli musi zostać zautomatyzowana z poziomu pulpitu użytkownika (szczególnie dla witryn .net, ponieważ dokumenty automatyzacji biura poprawnie ostrzegają, że wystąpią nieszczelności w narzędziach do współpracy biurowej, jeśli zostaną uruchomione bez głowy. zmuszeni do pisania bezgłowych procesów w celu wygenerowania dokumentów biurowych za pomocą tego zestawu narzędzi, który nazywaliśmy usługami ofiarnymi, ponieważ musieliście je okresowo mordować, aby odzyskać pamięć.

Poza opisywaną archiwizacją jest to niestety najlepsza praktyka w niektórych przypadkach.

Link: http://support.microsoft.com/kb/257757