W którym momencie YAGNI powinien mieć pierwszeństwo przed dobrymi praktykami kodowania i odwrotnie? Pracuję nad projektem w pracy i chcę powoli wprowadzać dobre standardy kodu dla moich współpracowników (obecnie ich nie ma i wszystko jest po prostu zhakowane razem bez rymowania i powodu), ale po utworzeniu serii klas (my nie wykonuj TDD ani, niestety, żadnych testów jednostkowych) Cofnąłem się o krok i pomyślałem, że to narusza YAGNI, ponieważ jestem pewien, że nie potrzebujemy rozszerzać niektórych z tych klas.
Oto konkretny przykład tego, co mam na myśli: mam warstwę dostępu do danych owijającą zestaw procedur przechowywanych, która wykorzystuje podstawowy wzorzec w stylu Repozytorium z podstawowymi funkcjami CRUD. Ponieważ istnieje kilka metod, których potrzebują wszystkie moje klasy repozytoriów, stworzyłem ogólny interfejs dla moich repozytoriów, zwany IRepository. Jednak potem stworzyłem interfejs „znacznika” (tj. Interfejs, który nie dodaje żadnej nowej funkcjonalności) dla każdego typu repozytorium (np. ICustomerRepository) I konkretna klasa go implementuje. Zrobiłem to samo z implementacją Factory, aby zbudować obiekty biznesowe z DataReaders / DataSets zwróconych przez procedurę przechowywaną; sygnatura mojej klasy repozytorium wygląda mniej więcej tak:
public class CustomerRepository : ICustomerRepository
{
ICustomerFactory factory = null;
public CustomerRepository() : this(new CustomerFactory() { }
public CustomerRepository(ICustomerFactory factory) {
this.factory = factory;
}
public Customer Find(int customerID)
{
// data access stuff here
return factory.Build(ds.Tables[0].Rows[0]);
}
}
Obawiam się tutaj, że naruszam YAGNI, ponieważ wiem z 99% pewnością, że nigdy nie będzie powodu, aby dać CustomerFactorytemu repozytorium cokolwiek innego niż konkret ; ponieważ nie mamy testów jednostkowych, nie potrzebuję MockCustomerFactoryani podobnych rzeczy, a posiadanie tak wielu interfejsów może dezorientować moich współpracowników. Z drugiej strony zastosowanie konkretnej implementacji fabryki wydaje się zapachem projektowym.
Czy istnieje dobry sposób na kompromis między właściwym projektowaniem oprogramowania a niewystarczającą ochroną rozwiązania? Pytam, czy muszę mieć wszystkie „interfejsy pojedynczej implementacji”, czy też mógłbym poświęcić trochę dobrego projektu i po prostu mieć na przykład interfejs podstawowy, a następnie pojedynczy konkretny, i nie martwić się o programowanie w interfejs, jeśli implementacja będzie kiedykolwiek używana.
źródło
Odpowiedzi:
YAGNI.
Fałszywe założenie.
To nie jest „ofiara”. Że to dobry projekt.
źródło
W większości przypadków unikanie kodu, którego nie będziesz potrzebować, prowadzi do lepszego projektowania. Najbardziej konserwowalny i przyszłościowy projekt to taki, który wykorzystuje najmniejszą ilość dobrze nazwanego, prostego kodu, który spełnia wymagania.
Najprostsze projekty są najłatwiejsze do rozwinięcia. Nic nie zabija łatwości utrzymania, jak bezużyteczne, przepracowane warstwy abstrakcji.
źródło
YAGNI i SOLID (lub dowolna inna metodologia projektowania) nie wykluczają się wzajemnie. Są to jednak przeciwieństwa prawie biegunowe. Nie musisz przestrzegać 100%, ale będzie trochę dawania i przyjmowania; im więcej patrzysz na wysoce abstrakcyjny wzór używany przez jedną klasę w jednym miejscu, i mówisz YAGNI i upraszczasz, tym mniej SOLIDNY staje się projekt. Odwrotna może być również prawda; wiele razy w fazie rozwoju projekt jest wdrażany SOLIDNIE „na wiarę”; nie widzisz, jak będziesz tego potrzebować, ale masz przeczucie. Może to być prawda (i jest coraz bardziej prawdopodobne, że im więcej zdobędziesz doświadczenia), ale może także narazić cię na tak duże zadłużenie techniczne, jak podejście „zrób to lekko”; zamiast bazy kodu „kod spaghetti” DIL, możesz otrzymać „kod lasagna”, posiadanie tak wielu warstw, że po prostu dodanie metody lub nowego pola danych staje się całodniowym procesem brodzenia przez serwery proxy i luźno powiązane zależności za pomocą tylko jednej implementacji. Lub możesz skończyć z „kodem ravioli”, który jest w tak małych kawałkach wielkości kęsa, że poruszanie się w górę, w dół, w lewo lub w prawo w architekturze prowadzi przez 50 metod z 3 liniami każda.
Powiedziałem to w innych odpowiedziach, ale oto jest: Przy pierwszym przejściu spraw, by działało. Przy drugim przejściu spraw, aby był elegancki. Przy trzecim przejściu ustaw SOLID.
Podział tego:
Kiedy po raz pierwszy piszesz wiersz kodu, musi on po prostu działać. W tym momencie, jak wiadomo, jest to jednorazowe. Tak więc nie dostajesz żadnych punktów stylu za budowę architektury „wieży z kości słoniowej”, aby dodać 2 i 2. Rób to, co musisz zrobić i zakładaj, że nigdy więcej go nie zobaczysz.
Gdy następnym razem kursor znajdzie się w tym wierszu kodu, odrzuciłeś swoją hipotezę od momentu jej pierwszego napisania. Ponownie odwiedzasz ten kod, prawdopodobnie go rozszerzysz lub użyjesz go w innym miejscu, więc nie jest to jednorazowy przypadek. Teraz należy zaimplementować niektóre podstawowe zasady, takie jak DRY (nie powtarzaj się) i inne proste reguły projektowania kodu; wyodrębniaj metody i / lub formuj pętle dla powtarzającego się kodu, wydobywaj zmienne dla typowych literałów lub wyrażeń, być może dodaj kilka komentarzy, ale ogólnie twój kod powinien sam dokumentować. Teraz twój kod jest dobrze zorganizowany, nawet jeśli może być ściśle powiązany, a każdy, kto na niego patrzy, może łatwo dowiedzieć się, co robisz, czytając kod, zamiast śledzić go wiersz po wierszu.
Za trzecim razem, gdy kursor wpisze ten kod, jest to prawdopodobnie wielka sprawa; albo przedłużasz go jeszcze raz, albo staje się on użyteczny w co najmniej trzech różnych innych miejscach w bazie kodu. W tym momencie jest to kluczowy, jeśli nie podstawowy, element twojego systemu i powinien być tak zaprojektowany. W tym momencie zazwyczaj masz również wiedzę o tym, jak dotychczas był używany, co pozwoli Ci podejmować dobre decyzje projektowe dotyczące tego, jak zaprojektować projekt, aby usprawnić te zastosowania i wszelkie nowe. Teraz reguły SOLID powinny wprowadzić równanie; wyodrębnij klasy zawierające kod o określonych celach, zdefiniuj wspólne interfejsy dla dowolnych klas o podobnych celach lub funkcjach, skonfiguruj luźno powiązane zależności między klasami i zaprojektuj zależności, które można łatwo dodawać, usuwać lub zamieniać.
Od tego momentu, jeśli trzeba będzie dalej rozszerzać, reimplementować lub ponownie wykorzystywać ten kod, wszystko jest ładnie zapakowane i wyodrębnione w formacie „czarnej skrzynki”, który wszyscy znamy i kochamy; podłącz go tam, gdzie jest to potrzebne, lub dodaj nową odmianę motywu jako nową implementację interfejsu bez konieczności zmiany użycia tego interfejsu.
źródło
Zamiast jednego z nich wolę WTSTWCDTUAWCROT?
(Jaka najprostsza rzecz, jaką możemy zrobić, jest przydatna i którą możemy wydać w czwartek?)
Prostsze akronimy znajdują się na mojej liście rzeczy do zrobienia, ale nie są priorytetem.
źródło
YAGNI i dobry design nie są sprzeczne. YAGNI dotyczy (nie) wspierania przyszłych potrzeb. Dobry projekt polega na tym, aby przejrzyste było to, co robi teraz twoje oprogramowanie i jak to robi.
Czy wprowadzenie fabryki uprości istniejący kod? Jeśli nie, nie dodawaj go. Jeśli tak, na przykład podczas dodawania testów (co powinieneś zrobić!), Dodaj go.
YAGNI nie polega na dodawaniu złożoności do obsługi przyszłych funkcji.
Dobry projekt polega na usuwaniu złożoności przy jednoczesnym wspieraniu wszystkich bieżących funkcji.
źródło
Nie są w konflikcie, twoje cele są błędne.
Co próbujesz osiągnąć?
Chcesz pisać wysokiej jakości oprogramowanie, a do tego chcesz mieć małą bazę kodu i nie mieć problemów.
Teraz dochodzimy do konfliktu, w jaki sposób chronimy wszystkie sprawy, jeśli nie piszemy spraw, których nie będziemy używać?
Oto jak wygląda twój problem.
Więc co to napędza?
Który z nich możemy rozwiązać? Wygląda na to, że nie chcemy marnować czasu, a nadużywanie kodu jest wielkim celem i ma sens. Co z tym pierwszym? Czy możemy dowiedzieć się, czego będziemy potrzebować do kodowania?
Powtórzmy to wszystko
Nie potrzebujesz kompromisu, potrzebujesz kogoś, kto będzie zarządzał zespołem, który jest kompetentny i ma wizję całego projektu. Potrzebujesz kogoś, kto może zaplanować to, czego będziesz potrzebować, zamiast wrzucać rzeczy, których NIE BĘDĄ ci potrzebne, ponieważ jesteś tak niepewny co do przyszłości, ponieważ ... dlaczego? Powiem ci dlaczego, ponieważ nikt nie ma cholernego planu między wami wszystkimi. Próbujesz wprowadzić standardy kodu, aby rozwiązać zupełnie osobny problem. Podstawowym problemem, który musisz rozwiązać, jest przejrzysta mapa drogowa i projekt. Gdy to zrobisz, możesz powiedzieć: „normy kodowe pomagają nam osiągać ten cel bardziej skutecznie jako zespół”, co jest absolutną prawdą, ale poza zakresem tego pytania.
Poproś kierownika projektu / zespołu, który może robić te rzeczy. Jeśli masz taką kartę, musisz poprosić ją o mapę i wyjaśnić problem YAGNI, którego nie przedstawia mapa. Jeśli są rażąco niekompetentni, sam napisz plan i powiedz „Oto mój raport na temat potrzebnych nam spraw, przejrzyj go i daj nam znać o swojej decyzji”.
źródło
Zezwolenie na rozszerzenie kodu o testy jednostkowe nigdy nie będzie objęte programem YAGNI, ponieważ będzie on potrzebny. Jednak nie jestem przekonany, że zmiany w projekcie interfejsu pojedynczej implementacji faktycznie zwiększają testowalność kodu, ponieważ CustomerFactory już dziedziczy z interfejsu i można go w dowolnym momencie zamienić na MockCustomerFactory.
źródło
Pytanie stanowi fałszywy dylemat. Właściwe stosowanie zasady YAGNI nie jest niczym niepowiązanym. To jeden z aspektów dobrego projektu. Każda z zasad SOLID jest również aspektem dobrego projektowania. Nie zawsze możesz w pełni zastosować każdą zasadę w dowolnej dyscyplinie. Problemy w świecie rzeczywistym nakładają na kod wiele sił, a niektóre z nich popychają w przeciwnych kierunkach. Zasady projektowania muszą uwzględniać je wszystkie, ale żadna garść zasad nie pasuje do wszystkich sytuacji.
Spójrzmy teraz na każdą zasadę ze zrozumieniem, że chociaż czasami mogą one zmierzać w różnych kierunkach, nie są one z natury rzeczy w konflikcie.
YAGNI został stworzony, aby pomóc programistom uniknąć szczególnego rodzaju przeróbek: tego, co wynika z budowania niewłaściwej rzeczy. Robi to, prowadząc nas do unikania zbyt wczesnych błędnych decyzji w oparciu o założenia lub prognozy dotyczące tego, co naszym zdaniem zmieni się lub będzie potrzebne w przyszłości. Wspólne doświadczenie mówi nam, że kiedy to robimy, zwykle się mylimy. Na przykład YAGNI powiedziałby ci, żebyś nie tworzył interfejsu w celu ponownego użycia , chyba że wiesz już , że potrzebujesz wielu implementatorów. Podobnie YAGNI powiedziałbym nie stworzyć „ScreenManagera” zarządzać jednego formularza w aplikacji, chyba że wiesz już teraz , że masz zamiar mieć więcej niż jeden ekran.
W przeciwieństwie do tego, co myśli wielu ludzi, SOLID nie polega na możliwości ponownego użycia, generyczności, a nawet abstrakcji. SOLID ma na celu pomóc Ci napisać kod, który jest przygotowany na zmianę , nie mówiąc nic o tym, jaka może być ta konkretna zmiana. Pięć zasad SOLID tworzy strategię budowania kodu, która jest elastyczna, nie jest zbyt ogólna i prosta, nie będąc naiwna. Właściwe stosowanie kodu SOLID tworzy małe, skoncentrowane klasy o ściśle określonych rolach i granicach. Praktycznym rezultatem jest to, że przy każdej potrzebnej zmianie wymagań należy dotknąć minimalną liczbę klas. Podobnie, przy każdej zmianie kodu istnieje zminimalizowana ilość „falowania” do innych klas.
Patrząc na przykładową sytuację, zobaczymy, co mogliby powiedzieć YAGNI i SOLID. Rozważasz wspólny interfejs repozytorium, ponieważ wszystkie repozytoria wyglądają tak samo z zewnątrz. Ale wartością wspólnego, ogólnego interfejsu jest możliwość korzystania z dowolnego z implementatorów bez konieczności określania, który z nich jest konkretny. O ile w Twojej aplikacji nie ma takiego miejsca, w którym byłoby to konieczne lub przydatne, YAGNI mówi, nie rób tego.
Do obejrzenia jest 5 SOLIDNYCH zasad. S to pojedyncza odpowiedzialność. Nie mówi to nic o interfejsie, ale może powiedzieć coś o twoich konkretnych klasach. Można argumentować, że za obsługę samego dostępu do danych najlepiej może odpowiadać jedna lub więcej innych klas, podczas gdy odpowiedzialność repozytoriów polega na tłumaczeniu z kontekstu niejawnego (CustomerRepository jest repozytorium niejawnie dla podmiotów klienta) na jawne wywołania do uogólniony interfejs API dostępu do danych określający typ jednostki klienta.
O jest otwarte-zamknięte. Chodzi głównie o dziedziczenie. Miałoby to zastosowanie, gdybyś próbował czerpać swoje repozytoria ze wspólnej bazy implementującej wspólną funkcjonalność lub gdybyś spodziewał się, że będziesz czerpał dalej z różnych repozytoriów. Ale nie jesteś, więc nie.
L oznacza substytucyjność Liskowa. Ma to zastosowanie, jeśli zamierzasz korzystać z repozytoriów za pośrednictwem wspólnego interfejsu repozytorium. Nakłada ograniczenia na interfejs i implementacje, aby zapewnić spójność i uniknąć specjalnego obchodzenia się z różnymi impelementerami. Powodem tego jest to, że taka specjalna obsługa podważa cel interfejsu. Przydatne może być rozważenie tej zasady, ponieważ może to ostrzec cię przed używaniem wspólnego interfejsu repozytorium. Jest to zgodne z wytycznymi YAGNI.
I to Segregacja interfejsu. Może to mieć zastosowanie, jeśli zaczniesz dodawać różne operacje zapytań do swoich repozytoriów. Segregacja interfejsu ma zastosowanie tam, gdzie można podzielić członków klasy na dwa podzbiory, z których jeden będzie używany przez niektórych konsumentów, a drugi przez innych, ale żaden konsument prawdopodobnie nie użyje obu podzbiorów. Wytyczne dotyczą utworzenia dwóch oddzielnych interfejsów zamiast jednego wspólnego. W twoim przypadku jest mało prawdopodobne, że pobieranie i zapisywanie pojedynczych instancji byłoby zajęte przez ten sam kod, który przeprowadzałby ogólne zapytania, więc może być przydatne rozdzielenie ich na dwa interfejsy.
D to wstrzyknięcie zależne. Wracamy do tego samego punktu, co S. Jeśli podzieliłeś zużycie interfejsu API dostępu do danych na osobny obiekt, ta zasada mówi, że zamiast tylko nowego wystąpienia tego obiektu, powinieneś przekazać go podczas tworzenia repozytorium. Ułatwia to kontrolowanie żywotności komponentu dostępu do danych, otwierając możliwość udostępniania referencji do niego między repozytoriami, bez konieczności podejmowania decyzji o uczynieniu go singletonem.
Należy zauważyć, że większość zasad SOLID niekoniecznie ma zastosowanie na tym konkretnym etapie tworzenia aplikacji. Na przykład to, czy należy zerwać dostęp do danych, zależy od tego, jak skomplikowane jest to zadanie i czy chcesz przetestować logikę repozytorium bez wchodzenia do bazy danych. Wygląda na to, że jest to mało prawdopodobne (niestety, moim zdaniem), więc prawdopodobnie nie jest konieczne.
Po tych wszystkich rozważaniach okazuje się, że YAGNI i SOLID rzeczywiście zapewniają jedną wspólną, solidną, natychmiastową poradę: prawdopodobnie nie jest konieczne tworzenie wspólnego ogólnego interfejsu repozytorium.
Cała ta uważna myśl jest niezwykle przydatna jako ćwiczenie edukacyjne. Nauka zajmuje dużo czasu, ale z czasem rozwijasz intuicję i staje się bardzo szybka. Będziesz wiedział, co należy zrobić, ale nie musisz myśleć o wszystkich tych słowach, chyba że ktoś poprosi cię o wyjaśnienie przyczyny.
źródło
Wydaje się, że wierzysz, że „dobry projekt” oznacza przestrzeganie pewnego rodzaju ideologii i formalnego zestawu zasad, które zawsze muszą być stosowane, nawet jeśli są bezużyteczne.
IMO to zły projekt. YAGNI jest elementem dobrego projektu, nigdy nie jest z nim sprzecznością.
źródło
W twoim przykładzie powiedziałbym, że YAGNI powinien zwyciężyć. Nie będzie Cię to dużo kosztować, jeśli będziesz musiał później dodać interfejsy. Nawiasem mówiąc, czy naprawdę dobrym pomysłem jest posiadanie jednego interfejsu według klasy, jeśli w ogóle nie ma celu?
Jeszcze jedna myśl, być może czasem nie potrzebujesz dobrego projektu, ale wystarczającego projektu. Oto bardzo interesująca sekwencja postów na ten temat:
źródło
Niektórzy twierdzą, że nazwy interfejsów nie powinny zaczynać się od I. W szczególności jednym z powodów jest fakt, że faktycznie przeciekasz zależność od tego, czy dany typ jest klasą czy interfejsem.
Co powstrzymuje cię od
CustomerFactorybycia klasą na początku, a później przekształcania jej w interfejs, który będzie albo zaimplementowany przez,DefaultCustormerFactoryalboUberMegaHappyCustomerPowerFactory3000? Jedyną rzeczą, którą powinieneś zmienić, jest miejsce, w którym implementacja jest generowana. A jeśli masz mniej dobry projekt, jest to najwyżej garść miejsc.Refaktoryzacja jest częścią rozwoju. Lepiej mieć mało kodu, który jest łatwy do refaktoryzacji, niż mieć interfejs i klasę zadeklarowaną dla każdej klasy, co zmusza cię do zmiany każdej nazwy metody w co najmniej dwóch miejscach jednocześnie.
Prawdziwym celem korzystania z interfejsów jest osiągnięcie modułowości, która jest prawdopodobnie najważniejszym filarem dobrego projektowania. Zauważ jednak, że moduł jest definiowany nie tylko przez jego oddzielenie od świata zewnętrznego (chociaż tak postrzegamy go z perspektywy zewnętrznej), ale również przez jego wewnętrzne działanie.
Mam na myśli to, że oddzielanie rzeczy, które z natury należą do siebie, nie ma większego sensu. W pewnym sensie przypomina szafkę z indywidualną półką na filiżankę.
Znaczenie polega na opracowaniu dużego, złożonego problemu w mniejsze, prostsze podproblemy. I musisz zatrzymać się w punkcie, w którym stają się wystarczająco proste bez dalszych podziałów, w przeciwnym razie staną się bardziej skomplikowane. Można to uznać za następstwo YAGNI. I to zdecydowanie oznacza dobry projekt.
Celem nie jest jakoś rozwiązanie lokalnego problemu za pomocą jednego repozytorium i jednej fabryki. Chodzi o to, aby ta decyzja nie miała wpływu na resztę wniosku. Na tym polega modułowość.
Chcesz, aby Twoi współpracownicy spojrzeli na Twój moduł, zobaczyli fasadę z garstką prostych wyjaśnień i poczują się pewnie, że mogą z nich korzystać, nie martwiąc się o wszystkie potencjalnie wyrafinowane instalacje wewnętrzne.
źródło
Tworzysz
interfacewiele przyszłych implementacji. Równie dobrze możesz miećI<class>dla każdej klasy w swojej bazie kodu. Nie róbWystarczy użyć pojedynczej klasy betonu zgodnie z YAGNI. Jeśli stwierdzisz, że potrzebujesz obiektu „próbnego” do celów testowych, zamień klasę oryginalną w klasę abstrakcyjną z dwiema implementacjami, jedną z oryginalną klasą konkretną, a drugą z próbną implementacją.
Będziesz oczywiście musiał zaktualizować wszystkie instancje oryginalnej klasy, aby utworzyć instancję nowej konkretnej klasy. Można to obejść za pomocą statycznego konstruktora z góry.
YAGNI mówi, aby nie pisać kodu, zanim będzie trzeba go napisać.
Dobry projekt mówi o użyciu abstrakcji.
Możesz mieć oba. Klasa jest abstrakcją.
źródło
Dlaczego interfejsy znaczników? Uderza mnie, że nie robi nic poza „tagowaniem”. Jaki jest sens z innym „znacznikiem” dla każdego typu fabryki?
Interfejs ma na celu nadanie klasie „zachowania podobnego do”, nadanie jej „zdolności repozytorium”. Więc jeśli wszystkie Twoje konkretne typy repozytoriów zachowują się jak to samo IRepository (wszystkie implementują IRepository), wówczas wszystkie mogą być obsługiwane w ten sam sposób przez inny kod - dokładnie ten sam kod. W tym momencie twój projekt jest rozszerzalny. Dodając więcej konkretnych typów repozytoriów, wszystkie obsługiwane jako ogólne IRepository (s) - ten sam kod obsługuje wszystkie konkretne typy jak repozytoria „ogólne”.
Interfejsy służą do obsługi rzeczy opartych na podobieństwach. Ale niestandardowe interfejsy znaczników a) nie dodają żadnego zachowania. i b) zmusić cię do zajęcia się ich wyjątkowością.
W zakresie, w jakim projektujesz użyteczne interfejsy, zyskujesz tę zaletę, że nie musisz pisać specjalistycznego kodu do obsługi wyspecjalizowanych klas, typów lub niestandardowych interfejsów znaczników, które mają korelację 1: 1 z konkretnymi klasami. To bezcelowa redundancja.
Pod ręką widzę interfejs znaczników, jeśli na przykład potrzebujesz mocno napisanej kolekcji wielu różnych klas. W kolekcji wszystkie są „ImarkerInterface”, ale gdy je wyciągniesz, musisz rzucić je na odpowiednie typy.
źródło
Czy potrafisz teraz zapisać dość rozsądne repozytorium ICustomer? Np. (Naprawdę docierając tutaj, prawdopodobnie zły przykład) w przeszłości Twoi klienci zawsze korzystali z PayPal? Czy wszyscy w firmie mają kłopoty z przyłączeniem się do Alibaba? Jeśli tak, możesz teraz użyć bardziej złożonego projektu i wyglądać na dalekowzrocznych dla swoich szefów. :-)
W przeciwnym razie poczekaj. Zgadywanie na interfejsie przed jedną lub dwiema rzeczywistymi implementacjami zwykle kończy się niepowodzeniem. Innymi słowy, nie uogólniaj / streszczaj / nie używaj fantazyjnego wzorca projektowego, dopóki nie masz kilku przykładów do uogólnienia.
źródło