Kryteria złego projektu
Życie działa po prostu: często, aby być mądrym, wystarczy nie robić głupich rzeczy. Dotyczy to również tworzenia oprogramowania: w większości przypadków, aby zrobić coś dobrze, wystarczy nie zrobić tego źle.
Większość programistów miała doświadczenie z częściami systemu, które zostały źle zaprojektowane. Ale jeszcze bardziej smutne jest to, że większość z was będzie miała smutne doświadczenie uświadomienia sobie, że to wy byliście autorami takiego systemu. Chcieliśmy jak najlepiej, ale wyszło jak zwykle.
Większość programistów nie aspiruje do złej architektury, aw przypadku wielu systemów przychodzi moment, w którym zaczynają mówić, że ich architektura jest okropna. Dlaczego to się dzieje? Czy projekt architektury był zły od samego początku, czy też z czasem stał się zły?
Źródłem tego problemu jest brak definicji „złego” projektu.
Wydaje mi się, że właśnie zrozumienie jakości projektu i przyczyn jego „rozpadu” jest najważniejszą cechą każdego programisty. Podobnie jak w większości innych przypadków, najważniejsze jest zidentyfikowanie problemu, a rozwiązanie go będzie kwestią technologii.
Definicja „złego projektu”
Jeśli zdecydujesz się pochwalić swoim kodem przed kolegą programistą, najprawdopodobniej zostaniesz wyśmiany w odpowiedzi: „Kto to robi?”, „Dlaczego tak jest?” i „Zrobiłbym pewne rzeczy inaczej”. To zdarza się bardzo często.
Wszyscy ludzie są różni, ale nadal piszesz kod dla innych programistów, więc w procesie opracowywania każdej funkcji zawsze potrzebujesz fazy przeglądu, gdy inne osoby patrzą na Twój kod.
Ale nawet jeśli wiele rzeczy można zrobić na różne sposoby, istnieje zestaw kryteriów, co do których zgodziliby się wszyscy programiści. Każdy fragment kodu, który spełnia wymagania, ale nadal wykazuje jedną (lub więcej) cech, jest złym projektem.
Zły projekt:
- Trudno zmienić, ponieważ każda zmiana wpływa na zbyt wiele innych części systemu. ( sztywność , sztywność).
- Kiedy wprowadzane są zmiany, inne części systemu nieoczekiwanie się psują. ( Kruchość , Kruchość).
- Kod jest trudny do ponownego użycia w innej aplikacji, ponieważ zbyt trudno jest wyciągnąć go z bieżącej aplikacji. ( Nieruchomość , Nieruchomość).
A najśmieszniejsze jest to, że prawie niemożliwe jest znalezienie elementu systemu , który nie zawiera żadnej z tych cech (czyli jest elastyczny, niezawodny i wielokrotnego użytku), spełnia wymagania, a jednocześnie jest źle zaprojektowany .
W ten sposób możemy wykorzystać te trzy cechy, aby jednoznacznie określić, czy projekt jest „zły”, czy „dobry”.
Przyczyny „złego projektu”
Co sprawia, że projekt jest sztywny, kruchy i nieruchomy? Sztywna współzależność modułów.
Projekt jest sztywny , jeśli nie można go łatwo zmienić. Ta sztywność wynika z faktu, że pojedyncza zmiana fragmentu kodu w tkanym systemie powoduje kaskadowe zmiany w zależnych modułach. Dzieje się tak zawsze, gdy nad kodem pracuje jedna osoba.
To natychmiast komplikuje cały proces rozwoju komercyjnego: kiedy projektant lub deweloper nie może przewidzieć liczby kaskadowych zmian, niemożliwe jest oszacowanie wpływu takiej zmiany. Dlatego starają się odkładać takie zmiany w nieskończoność.
A to z kolei sprawia, że koszt zmiany jest nieprzewidywalny. W obliczu takiej niepewności menedżerowie niechętnie wprowadzają zmiany, więc projekt oficjalnie staje się sztywny.
W pewnym momencie Twój projekt przekracza „horyzont zdarzeń” i jest skazany na wpadnięcie w „czarną dziurę” sztywnej architektury.
Kruchość to tendencja systemu do załamania się w wielu miejscach po jednej zmianie. Zwykle nowe problemy pojawiają się w miejscach, które są koncepcyjnie niezwiązane z miejscem zmiany. Taka kruchość poważnie podważa zaufanie do projektu i utrzymania systemu.
Zwykle tak było, gdy nie było metod prywatnych. Wystarczy upublicznić wszystkie metody, a będziesz skazany na wygląd kruchej architektury. Hermetyzacja pomaga radzić sobie z tym na poziomie mikro. Ale na poziomie makro potrzebna jest architektura modułowa.
Gdy projekt ma delikatną architekturę, programiści nie mogą zagwarantować jakości produktu.
Proste zmiany w jednej części aplikacji prowadzą do błędów w innych niezwiązanych częściach. Poprawianie tych błędów prowadzi do jeszcze większych problemów, a proces eskortowania zamienia się w słynnego psa goniącego własny ogon.
Projekt jest nieruchomy , gdy niezbędne części systemu są mocno powiązane z innymi niechcianymi detalami. Za dużo własnego kodu, własnych unikalnych podejść i rozwiązań.
Czy pamiętasz rejestrator JUL, którego programiści wymyślili własne poziomy logowania bez powodu? To tylko przypadek.
Aby dać projektantowi wyobrażenie o tym, jak łatwo jest ponownie wykorzystać istniejący projekt, wystarczy pomyśleć o tym, jak łatwo będzie go użyć w nowej aplikacji.
Jeśli projekt jest ściśle powiązany, projektant będzie przerażony ilością pracy wymaganej do oddzielenia wymaganych części systemu od zbędnych szczegółów. W większości przypadków taki projekt nie nadaje się do ponownego wykorzystania, ponieważ koszt jego wydzielenia przewyższa opracowanie go od podstaw.
Znaczenie
Wszystko się zmienia, ale wszystko pozostaje takie samo. (Chińskie przysłowie)
Powyżej postawiono bardzo dobre pytania. Jakie niebezpieczeństwa wiążą się z kruchymi i sztywnymi systemami? Tak, ponieważ proces zarządzania takim projektem staje się nieprzewidywalny i niekontrolowany. A cena jest wygórowana.
Jak menedżer może dać lub nie dać zielone światło na dodanie jakiejś funkcji, jeśli nie wie, ile czasu to faktycznie zajmie? Jak priorytetyzować zadania, jeśli nie można odpowiednio oszacować czasu i złożoności ich realizacji?
A jak programiści mogą spłacić ten sam dług techniczny, kiedy my będziemy go spłacać z prowizji, a nie możemy zrozumieć, ile będziemy prowizji, dopóki nie spłacimy prowizji?
Bardzo istotne są również problemy z ponownym użyciem kodu lub testowaniem. Testy jednostkowe służą nie tylko do sprawdzenia pewnych założeń na temat testowanej jednostki, ale także do określenia stopnia jej spójności i mogą służyć jako wskaźnik ponownego użycia.
Oto cytat Boba Martina dotyczący tego przypadku: „Aby ponownie wykorzystać swój kod, musisz dołożyć starań, aby ponowne użycie go było mniejsze niż koszt opracowania od podstaw ” . W przeciwnym razie nikt nie będzie nawet zawracał sobie głowy tą sprawą.
Stosowanie zasad i wzorców projektowych służy jednemu celowi – uczynieniu projektu dobrym. Jeśli ich użycie nie przynosi żadnych korzyści (lub odwrotnie, narusza zasady „dobrego projektu”), to coś w Twoim ogrodzie zimowym jest nie tak i być może narzędzie zaczęło być wykorzystywane do innych celów.