Czy istnieje nazwany anty wzór dla historycznie produkowanego oprogramowania? [Zamknięte]

Czy istnieje anty-wzorzec opisujący historycznie rozwijany system oprogramowania, w którym wielu programistów właśnie dodało nowe funkcje do systemu, ale nikt tak naprawdę nie pilnował ogólnej architektury ani nigdy nie przeprowadzono refaktoryzacji?

Wydaje mi się, że dzieje się tak, gdy zarząd / klient ciągle prosi o nową funkcję i nikt nigdy niczego nie refaktoryzuje, tylko dodaje do tego, czego inni programiści wcześniej nie robili.

Powodem może być również to, że programista jest po prostu przytłoczony systemem oprogramowania i tak naprawdę nie rozumie, jak obecnie działa, a następnie po prostu dodaje / klei swój kod na samym końcu (zamiast refaktoryzować kod i go zmieniać).

Z biegiem czasu utrzymanie systemu staje się coraz trudniejsze.

(Zastanawiam się, czy są zdjęcia tego rodzaju anty-wzoru, aby uczynić to bardziej zrozumiałym dla nikogo, kto programuje - jak samochód, który został zbudowany po prostu dodając coraz więcej funkcji bez myślenia o ogólnym projekcie. Jakby ktoś musiał holować przyczepy podczas jazdy do tyłu, a następnie inżynier po prostu przysparza hak holowniczy do przedniej części samochodu. Praca wykonana. Ale teraz osłona już się nie otwiera).

Masz na myśli dług techniczny .

Wszyscy naliczamy dług techniczny od produktów, które opracowujemy z czasem; refaktoryzacja jest jednym z bardzo powszechnych i skutecznych sposobów zmniejszenia tego zadłużenia technicznego, chociaż wiele firm nigdy nie spłaca zadłużenia technicznego. Firmy te często uważają, że ich oprogramowanie jest wyjątkowo niestabilne, a dług techniczny staje się tak okropny, że nie można go spłacać stopniowo, ponieważ spłacanie go w ten sposób trwałoby zbyt długo.

Dług techniczny ma termin, ponieważ wynika z tych samych zachowań długu. Dostajesz dług i dopóki będziesz go wydawać (tworzyć funkcje) i nie spłacać tego długu, będzie on tylko rósł. Podobnie jak dług, gdy staje się zbyt duży, dochodzisz do punktów, w których możesz chcieć całkowicie go przelać za pomocą niebezpiecznych zadań, takich jak pełne przepisywanie. Podobnie jak prawdziwy dług, ponieważ narasta do pewnego momentu, utrudnia całkowicie wydawanie (tworzenie funkcji).

Po prostu wrzucając do miksu inny termin, spójność odnosi się do tego, jak dobrze system, mikro do poziomu linii lub makro do poziomu systemu, pasują do siebie. Bardzo spójny system sprawi, że wszystkie jego elementy będą bardzo dobrze do siebie pasować i będą wyglądać, jakby napisał je jeden inżynier. Twoje powyższe odniesienie do kogoś, kto po prostu przyklei kod do końca, naruszałoby spójność tego systemu.

Zarządzanie długiem technicznym

Istnieje wiele sposobów zarządzania długiem technicznym, chociaż tak jak w przypadku długu rzeczywistego najlepszym podejściem jest spłacanie go często. Niestety, tak jak w przypadku prawdziwego długu, czasem lepiej jest zgromadzić więcej na krótki okres, w którym na przykład czas na wprowadzenie na rynek funkcji może podwoić lub potroić przychody. Trudna część polega na wyważeniu tych konkurencyjnych priorytetów, a także ustaleniu, kiedy ROI zadłużenia nie jest tego warte dla danej funkcji, a kiedy jest.

Czasami więc warto naliczać dług na krótki okres, ale rzadko tak jest, i jak w przypadku wszystkich długów, im krótszy okres, tym lepiej. Więc w końcu (najlepiej szybko ) po narosnięciu długu technicznego musisz go spłacić, są to powszechne podejścia:

• Refaktoryzacja
  • Pozwala to pobrać fragmenty kodu, które zostały uświadomione, że zostały zgubione w trakcie lub po zakończeniu implementacji, i umieścić je we właściwym miejscu (lub bardziej poprawnym).
• Przepisać
  • To jest jak bankructwo. Czyści tabliczkę, ale zaczynasz od niczego i masz możliwość popełnienia tych samych lub nawet większych błędów. Podejście techniczne o wysokim ryzyku i wysokim wynagrodzeniu, ale czasami jest to jedyna opcja. Chociaż tak jest rzadziej, niż wielu ci to powie.
• Przegląd architektury
  • Jest to bardziej aktywne podejście do spłaty długu technicznego. Odbywa się to poprzez zatrudnienie kogoś, kto ma władzę nad szczegółami technicznymi, aby zatrzymać wdrażanie niezależnie od planów i harmonogramów projektu, aby zapewnić, że narosnie mniej długu technicznego.
• Zamrożenie kodu
  • Zamrożenie kodu zmian może pozwolić ci odetchnąć, gdzie twój dług nie rośnie ani nie maleje. Daje to czas na zaplanowanie podejścia do zmniejszenia zadłużenia technicznego z nadzieją uzyskania najwyższego zwrotu z inwestycji.
• Modularyzacja
  • To jest jak podejście poziomu 2 dostępne tylko wtedy, gdy zastosujesz albo Omówienie architektury, aby mieć już system modułowy, albo Refaktoryzację, aby przejść do jednego. Gdy masz system modułowy, możesz spłacać dług w całych częściach systemu w sposób izolowany. Pozwala to na częściowe ponowne zapisywanie, częściowe refaktoryzowanie, a także minimalizację naliczania długu technicznego, ponieważ izolacja utrzymuje dług tylko w tych obszarach, w których pojawiły się funkcje, w przeciwieństwie do rozprzestrzeniania się po całym systemie.
• Zautomatyzowane testy
  • Zautomatyzowane testy mogą pomóc w zarządzaniu zadłużeniem technicznym, ponieważ mogą pomóc w zidentyfikowaniu miejsc problemów w systemie, miejmy nadzieję, że zanim zadłużenie w tych obszarach wzrosnie bardzo duże, ale nawet po tym, jak nadal mogą uświadomić inżynierom te niebezpieczne obszary, które być może jeszcze nie zdawałem sobie sprawy. Co więcej, po przeprowadzeniu automatycznych testów możesz bardziej swobodnie refaktoryzować rzeczy bez obawy o zbyt duże uszkodzenie. Nie dlatego, że programiści nic nie zepsują, ale dlatego, że dowiedzą się, kiedy coś zepsują , poleganie na ręcznych testerach w wysoce zadłużonych systemach zwykle ma słabe wyniki w wykrywaniu problemów.

Twój opis pasuje do Big Ball of Mud Foote and Yoder :

W ciągu ostatnich kilku lat wielu autorów ... zaprezentowało wzorce charakteryzujące architektury wysokiego poziomu oprogramowania ... W idealnym świecie każdy system byłby przykładem jednego lub więcej takich wzorców wysokiego poziomu. Ale tak nie jest. Architektura, która faktycznie dominuje w praktyce, musi jeszcze zostać omówiona: BIG BALL OF MUD .

BIG BALL OF MUD to przypadkowo zbudowana, rozłożysta, niechlujna, taśma klejąca i drut ratunkowy, dżungla z kodem spaghetti. Wszyscy je widzieliśmy. Systemy te wykazują wyraźne oznaki nieuregulowanego wzrostu i powtarzalnych, celowych napraw. Informacje są dzielone między odległe elementy systemu, często do tego stopnia, że ​​prawie wszystkie ważne informacje stają się globalne lub powielane. Ogólna struktura systemu nigdy nie mogła być dobrze określona. Gdyby tak było, mogło to ulec erozji nie do poznania. Programiści z odrobiną wrażliwości architektonicznej unikają tych dziwactw. Tylko ci, którzy nie przejmują się architekturą i być może czują się dobrze z inercją codziennej pracy związanej z łataniem dziur w tych nieudanych wałach, są zadowoleni z pracy na takich systemach ...

Dlaczego system staje się WIELKĄ PIŁKĄ Błota? Czasami duże, brzydkie systemy wyłaniają się z KODU THROWAWAY . KOD THROWAWAY to szybki i brudny kod, który miał być użyty tylko raz, a następnie odrzucony. Jednak taki kod często nabiera własnego życia, pomimo luźnej struktury i słabej lub nieistniejącej dokumentacji. Działa, więc po co to naprawiać? Gdy pojawi się powiązany problem, najszybszym sposobem rozwiązania tego problemu może być celowe zmodyfikowanie tego działającego kodu, a nie zaprojektowanie odpowiedniego, ogólnego programu od podstaw. Z biegiem czasu, prosty program do rzucania rodzi WIELKĄ KULĘ Z BŁOGI.

Nawet systemy o dobrze zdefiniowanej architekturze są podatne na erozję strukturalną. Nieustanny atak zmieniających się wymagań, który przyciąga każdy udany system, może stopniowo podważać jego strukturę. Systemy, które kiedyś były czyste, zarastają, gdy PIECEMEAL GROWTH stopniowo pozwala na niekontrolowane rozszerzanie się elementów systemu.

Jeśli takie rozprzestrzenianie się będzie trwało nieprzerwanie, struktura systemu może stać się tak poważnie zagrożona, że ​​należy go porzucić. Podobnie jak w przypadku rozkładającej się dzielnicy, powstaje spirala w dół. Ponieważ system staje się coraz trudniejszy do zrozumienia, konserwacja staje się droższa i trudniejsza. Dobrzy programiści nie chcą tam pracować. Inwestorzy wycofują swój kapitał. A jednak, podobnie jak w dzielnicach, istnieją sposoby na uniknięcie, a nawet odwrócenie tego rodzaju upadku. Podobnie jak w przypadku wszystkiego innego we wszechświecie, przeciwdziałanie siłom entropii wymaga inwestycji energii. Gentryfikacja oprogramowania nie jest wyjątkiem. Sposobem na zatrzymanie entropii w oprogramowaniu jest jej refaktoryzacja. Długotrwałe zaangażowanie w refaktoryzację może powstrzymać system przed wpadnięciem w WIELKĄ KULĘ Z BŁOTU ...

• ... Jednym z najbardziej skutecznych wrogów błota jest słońce. Poddanie zawiłego kodu strzałce kontrolnej może przygotować grunt pod jego refaktoryzację, naprawę i rehabilitację. Przeglądy kodów są jednym z mechanizmów, których można użyć do wystawienia kodu na światło dzienne.