SOLIDNE zasady a YAGNI

Kiedy zasady SOLID stają się YAGNI?

Jako programiści dokonujemy kompromisów przez cały czas, między złożonością, łatwością utrzymania, czasem budowy i tak dalej. Między innymi dwie najmądrzejsze wytyczne dotyczące dokonywania wyborów to moim zdaniem zasady SOLID i YAGNI. Jeśli nie potrzebujesz tego; nie buduj go i utrzymuj w czystości.

Teraz, na przykład, kiedy oglądam serię dimecastów w SOLID , widzę, że zaczyna się ona jako dość prosty program i kończy się jako dość złożony (koniec tak, złożoność zależy również od obserwatora), ale nadal powoduje Zastanawiam się: kiedy zasady SOLID stają się czymś, czego nie potrzebujesz? Wszystkie solidne zasady to sposoby działania, które pozwalają na wprowadzanie zmian na późniejszym etapie. Ale co, jeśli problem do rozwiązania jest dość prosty i jest to aplikacja jednorazowa, to co? Czy też zasady SOLID są czymś, co zawsze obowiązuje?

Jak zapytano w komentarzach:

• SOLIDNE Zasady
• YAGNI

Zawsze trudno jest ocenić podejście oparte na zrzucie ekranu, ponieważ problemy wybrane do prezentacji są zazwyczaj tak małe, że zastosowanie zasad takich jak SOLID szybko sprawia, że ​​wygląda na to, że rozwiązanie jest całkowicie nadinstruowane.

Powiedziałbym, że zasady SOLID są prawie zawsze przydatne. Po opanowaniu ich używanie ich nie wydaje się czymś, o czym trzeba rozmyślnie myśleć. To po prostu staje się naturalne. Widziałem, że wiele jednorazowych aplikacji stało się czymś więcej, więc teraz boję się powiedzieć, że coś wyrzucę, ponieważ po prostu nigdy nie wiadomo.

Podejście, które zazwyczaj przyjmuję, polega na tym, że jeśli piszę prostą aplikację do określonego zadania, czasami rezygnuję z zasad wielkich nazwisk na rzecz kilku działających linii kodu. Jeśli stwierdzę, że wracam do tej aplikacji, aby wprowadzić dalsze zmiany, poświęcę trochę czasu, aby uczynić ją SOLIDNĄ (przynajmniej nieco, ponieważ 100% stosowanie zasad jest rzadko wykonalne).

W większych aplikacjach zaczynam od małych, a gdy program się rozwija, stosuję zasady SOLID tam, gdzie to możliwe. W ten sposób nie próbuję projektować całości z góry do ostatniego wyliczenia. Dla mnie to najsłodsze miejsce, w którym YAGNI i SOLID współistnieją.

Pomyśl przede wszystkim o problemie. Jeśli ślepo zastosujesz zasady YAGNI lub SOLID, możesz później zrobić sobie krzywdę. Mam nadzieję, że wszyscy możemy zrozumieć, że nie ma jednego podejścia projektowego, które pasowałoby do wszystkich problemów. Możesz to zobaczyć, gdy sklep sprzedaje czapkę reklamowaną jako „jeden rozmiar dla wszystkich”, ale to nie pasuje do twojej głowy. Jest albo za duży, albo za mały.

Zamiast tego lepiej jest zrozumieć zasady i problemy, które SOLID próbuje rozwiązać; a także zasady i problemy, które YAGNI próbuje rozwiązać. Przekonasz się, że jedno dotyczy architektury aplikacji, a drugie dotyczy całego procesu programowania. Chociaż w niektórych przypadkach mogą się one nakładać, są to wyraźnie różne problemy.

YAGNI (You Ain't Gonna Need It [osobliwy amerykański akronim]) zajmuje się oszczędzaniem czasu dewelopera poprzez dodanie stalowych zbrojonych betonowych fundamentów do mostu, który ma obejmować tylko 3 stopy szerokości, gdy prostszy drewniany most wystarczy w porządku. Jeśli zajmiemy rzekę o szerokości mili i będziemy musieli wesprzeć kilka przyczep ciągnikowych, oczywiście potrzebowalibyśmy dodatkowych prac fundamentowych. Zasadniczo YAGNI mówi ci, abyś spojrzał na większy obraz i projekt dla bieżących potrzeb. Rozwiązuje problem zbytniego skomplikowania, ponieważ przewidujemy szereg potencjalnych potrzeb, których klient jeszcze nie zidentyfikował.

SOLID martwi się tym, w jaki sposób upewniamy się, że elementy mostu pasują do siebie odpowiednio i mogą być utrzymywane z czasem. Możesz zastosować SOLIDNE zasady do drewnianego mostu, a także stalowego zbrojonego mostu betonowego.

Krótko mówiąc, te dwa pojęcia niekoniecznie są ze sobą sprzeczne. Kiedy natrafisz na sytuację, w której uważasz, że tak, nadszedł czas, aby spojrzeć na duży obraz. W zależności od wniosków możesz zdecydować się na rezygnację z części zasad SOLID lub zdecydować, że naprawdę tego potrzebujesz.

Zasady SOLID nie są potrzebne, gdy jest to aplikacja wyrzucana; w przeciwnym razie są zawsze potrzebne.

SOLID i YAGNI nie są ze sobą sprzeczne: dobry projekt klasy ułatwia utrzymanie aplikacji. YAGNI stwierdza tylko, że nie powinieneś dodawać możliwości, by twoja aplikacja była konfigurowalną potwornością, która może robić wszystko pod słońcem - chyba że faktycznie tego potrzebuje.

Jest to różnica między klasą samochodów, która ma dobrze zdefiniowane granice (SOLID), a klasą samochodu, która ma zdolność samoleczenia (YAGNI), zanim klient o to poprosi.

Nic nie ma zastosowania! Nie pozwól, aby astronauci z architektury Cię wystraszyli! Ważne jest, aby spróbować zrozumieć, jakie problemy próbują rozwiązać te zasady, abyś mógł podjąć świadomą decyzję o ich zastosowaniu.

Ostatnio próbowałem zrozumieć, kiedy powinienem zastosować zasadę pojedynczej odpowiedzialności ( oto, co wymyśliłem).

Mam nadzieję że to pomoże!

Jest cytat przypisany Einsteinowi (prawdopodobnie wariantowi prawdziwego ):

„Wszystko powinno być tak proste, jak to możliwe, ale nie prostsze”.

I to mniej więcej podejście, które podchodzę w obliczu kompromisu SOLID vs YAGNI: zastosuj je alternatywnie, ponieważ nigdy nie wiesz, czy program jest kodem „wyrzucającym”, czy nie. Więc po prostu dodaj warstwę brudu, która działa, a następnie wypoleruj ją do czystszego interfejsu ... i powtarzaj, aż osiągniesz odpowiedni poziom entropii. Ufnie.

Istnieje wiele sposobów zaprojektowania programu dla danego problemu; SOLID to próba zidentyfikowania właściwości dobrego projektu. Właściwe użycie SOLID powinno skutkować stworzeniem programu, który łatwiej jest uzasadnić i zmodyfikować.

YAGNI i KISS zajmują się zakresem funkcji. Program, który rozwiązuje więcej rodzajów problemów, jest bardziej złożony i abstrakcyjny. Jeśli nie potrzebujesz takiej ogólności, poświęciłeś czas i wysiłek na tworzenie kodu, który jest trudniejszy do zrozumienia i utrzymania, ale nie oferuje żadnej wartości dodanej.

Program, który został dobrze zaprojektowany, niekoniecznie koncentruje się tylko na potrzebnych funkcjach. Program, który koncentruje się tylko na potrzebnych mu funkcjach, niekoniecznie jest dobrze zaprojektowany. Nie ma kompromisu, tylko dwie ortogonalne osie w przestrzeni decyzyjnej. Idealny program jest zarówno modułowy, jak i ma tylko podstawowe funkcje.

Myślę, że powinieneś założyć YAGNI i kiedykolwiek zajdzie taka potrzeba, SOLIDify.

Mam na myśli SOLID, więc kiedy dodajesz nową klasę, nie będziesz musiał refaktoryzować, po prostu zmienić implementację (na przykład), cóż, moim zdaniem, po prostu napisz kod, a kiedy zobaczysz, że się zmieniasz rzeczy - zmień to na SOLID (tzn. boisz się, że refaktoryzacja SOLID ma cię przed tym uratować - nie jest tak źle, kiedy dopiero zaczynasz).

Nie marnujesz czasu, bo i tak musiałbyś wykonać pracę (na początku), a gdziekolwiek jest to potrzebne, kod jest miły i uporządkowany.

Myślę, że można to nazwać leniwą oceną SOLID.