SOLIDNE zasady a YAGNI

43

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:

KeesDijk
źródło
Czy tytuł nie powinien być również SOLID principle vs YAGNI?
Wolf
2
@Wolf: Jest to liczba mnoga „SOLID (Pojedyncza odpowiedzialność, Otwarte-zamknięte, Zastąpienie Liskowa, Segregacja interfejsu i Inwersja zależności) to mnemoniczny akronim wprowadzony przez Michaela Feathersa dla„ pierwszych pięciu zasad ”wymienionych przez Roberta C. Martina na początku 2000s, co oznacza pięć podstawowych zasad programowania obiektowego i projektowania ”.
logc

Odpowiedzi:

55

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

Adam Lear
źródło
Tak też myślę. Jako komentarz, którego nie oceniam na podstawie screencastu, po prostu uważam, że jest to dobry przykład rozwoju oprogramowania przy zastosowaniu SOLID.
KeesDijk
Słuszna uwaga. Każda demonstracja zostanie wypaczona, aby zademonstrować lub zaostrzyć problem. Zasadniczo cała jego idea polega na doprowadzeniu pomysłu do końca, aby udowodnić, że jest to błąd. Założenie, które samo w sobie może być nadużywane.
Berin Loritsch,
YAGNI and SOLID coexistdobry wniosek. Chociaż może to być dobry punkt wyjścia
Wolf
Wydaje się, że czasem może być potrzebne przeczucie. Musisz wiedzieć, gdzie możesz zacząć widzieć wiele zmian, aby wiedzieć, gdzie kończą się poziomy abstrakcji w stosunku do hydrauliki.
Johnny
19

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.

Berin Loritsch
źródło
Tak, zgadzam się… nie ma srebrnego podejścia, które pasowałoby do każdego scenariusza.
EL Yusubov,
Twoje make sure the pieces of the bridge fit togethernie jest tak oczywiste jak can be maintained over time.
Wolf,
Zasadniczo SOLID umożliwia przekształcenie tego drewnianego mostu w pełny na stalowy most o długości 1 mili, który jest w stanie wesprzeć opancerzony pluton bez konieczności pełnego przepisywania lub po prostu przyklejając się do hacka po hacku.
sara,
@kai, to fałszywa przesłanka. Jeśli potrzebujesz mostu o długości 1 mili, możesz zaprojektować most o długości 1 mili. Jeśli potrzebujesz mostu o długości 5 stóp, budujesz most o długości 5 stóp. Nie zrozumcie mnie źle, zasady SOLID są bardzo pomocne, ale potrzeba ich większego zrozumienia, aby wiedzieć, które zasady nie są konieczne dla danego problemu. 9 razy na 10 ta dodatkowa mila nigdy nie jest potrzebna.
Berin Loritsch,
@BerinLoritsch i dlatego zgadzam się, że jeśli potrzebujesz 5 stóp, budujesz 5 stóp, ale NIE budujesz 5 stóp, przeciągając kilka 2x4s na ziemię. robisz to, czego potrzebujesz i robisz to dobrze. (chociaż ta analogia się rozpada)
sara
9

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.

George Stocker
źródło
1
Czy to nie pomieszane? A co z tym: odpowiednio zastosuj zasady SOLID, aby poradzić sobie ze złożonością samoleczących się samochodów, lub zastosuj YAGNI, dopóki twoje samochody są tak proste, że nigdy się nie zepsują (lub - alternatywnie - tak tanio, że można je po prostu wyrzucić) .
Wolf,
2
@Wolf SOLIDNE zasady nie mówią, co powinieneś zrobić, tylko JAK. jeśli już zdecydowałeś, że chcesz samoleczących się samochodów, możesz zastosować zasady SOLID do tego kodu. SOLID nie mówi jednak, czy samoleczący się samochód jest dobrym pomysłem. Tam właśnie wchodzi YAGNI.
sara
Często aplikacje odrzucające nie są.
Tulains Córdova,
„Samoleczenie” jest dobre. „Zanim klient o to poprosi”, jest również dobre, ponieważ uważam, że cały pomysł, jeśli posłuchasz wujka Boba, dotyczy miejsc, które osiągają zysk i przewidują potrzeby klienta i prowadzą rentowny biznes, który może odpowiedzieć na potrzeby ponieważ się zmieniają. Wiele osób denerwuje się na wuja Boba, ponieważ nie wchodzi on bezpośrednio w programowanie, ale mówi ci przez większość czasu, dlaczego warto korzystać z SOLID, a nie tylko jak.
Johnny
„Zasady SOLID nie są potrzebne, gdy jest to aplikacja wyrzucana” . Myślę, że zasady SOLID są dobrym nawykiem, więc nawet jeśli jest to wyrzucana aplikacja, trenujesz siebie, kiedy potrzebujesz napisać dużą aplikację, więc możesz skorzystać z przestrzegania zasad SOLID.
icc97
4

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!

Brandon
źródło
2

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.

logc
źródło
Dobra uwaga: you never know if a program is 'throw-away' code- myślę, że alternatywnie pomysł nie jest zbyt dobry.
Wolf,
@Wolf: tak, rozwijałem się według kolejności kroków, które uważam za najlepsze (podsumowane w sloganie „Najpierw spraw, by było to możliwe, a potem uczyń to pięknym, a potem szybkim”), ale potem pomyślałem… YAGNI :)
logc,
1

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.

Doval
źródło
0

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.

Binyamin
źródło
Hm, rozumiem, że twój post jest zbędny, usunę go, ale wygląda na to, że nie mam do tego uprawnień (lub nie widzę przycisku). Tak czy inaczej, zmienię to, aby było jaśniej.
Binyamin