Stosowanie wzorców projektowych w pracy.

0

Witam wszystkich.
Jak to jest ze stosowaniem wzorców projektowych ? W okresie próbnym w pracy przestawiłem się na stosowanie wzorców projektowych, praktycznie wszędzie. Dla przykładu chcę sklonować dwa obiekty, odrazy chwytam za wzorzec Prototyp i szukam przykładowej, najprostszej implementacji w internecie. Faktycznie wtedy praca mi idzie wolniej. Co ciekawe zwróciłem uwagę, że inni programiści nie stosują wzorców projektowych praktycznie w ogóle, może tylko czasami. Czy coś ze mną nie jest tak ? Czy stosować wzorce projektowe gdzie się da, czy nie. Dzięki za informacje i wskazówki :)

2

Masz dostarczać kod, który ma działać i masz robić to możliwie szybko. Czy będzie oparty o wzorce wymyślone przez kogoś, czy twój osobisty zestaw, czy tworzone na bieżąco rozwiązania to już przeważnie wszystkich rypie. Jeśli coś cię spowalnia to albo popracuj nad przyśpieszeniem tego czegoś, albo sobie to coś daruj. There is no silver bullet.

2

na pewno nie wszędzie gdzie się da! Bo pójdziesz w drugą stronę i zrobisz overengeering, co jest chyba gorsze niż nie stosowanie wzorców. Wzorce mają pomagać, a nie przeszkadzać. Wpychanie wszędzie gdzie się da doprowadzi do tego, że będziesz pisać może trochę lepszej jakości kod, ale zwolnisz dostarczać i to ogromnie.

Myślę, że to kwestia balastu oraz ciągłej refaktoryzacji. Na początku robisz to byleby działało a później refaktoryzujesz do akceptalnej (nie idealnej) formy i idziesz dalej z tematem.
Jak z prawie wszystkim - trzeba umiaru.

10

Spytaj sam siebie, czy w danym momencie chcesz zastosować wzorzec projektowy dlatego, że chcesz go zastosować czy dlatego, że faktycznie jest potrzebny.

Jeśli w danej sytuacji wzorzec faktycznie wniesie jakąś wartość, to nie ma powodu żeby go nie użyć, ale wpychając je na siłę, byleby tylko ich użyć możesz osiągnąć skutek odwrotny do zamierzonego, szczególnie jeśli zaczniesz wpychać takie, które rozwiązują problem, którego nie masz. Nie przymierzając, zawiniesz cukierek w tyle sreberek, że jak ktoś po latach na to spojrzy to myśli, że ma do czynienia z repliką Sputnika a nie cukierkiem :]

To jak ten umiar znaleźć ? To jest problem. Z jednej strony chcę aby była super jakość kodu, ale też jest wydajność.

Stosując uniwersalne narzędzia przydatne w rozwiązywaniu każdego problemu inżynierskiego: zdrowy rozsądek i umiar :P

To:

tacticool

Wcale nie jest wyższej jakości i nie ma większej wartości bojowej niż to:

lee-enfield

Choć typowy Mall Ninja władający taką nafaszerowaną bajerami kaszanką z pewnością czuje się bardzo pro.

3

Na początku robisz to byleby działało a później refaktoryzujesz do akceptalnej (nie idealnej) formy i idziesz dalej z tematem.

A tuż po tym jak napiszesz to byle jak wpada PM z 5-cioma wrzutami i okazuje się że nie ma czasu żeby to przepisać porządnie. I pewnie między innymi przez takie właśnie podejście wiele projektów wygląda tak jak wygląda. Na samym początku trzeba przede wszystkim przeanalizować zadanie, przemyśleć jak je zrobić a kodować dopiero po zakończeniu dwóch poprzednich etapów. I idealnie jest robić to w taki sposób, żeby nie trzeba było później tego poprawiać.

10

Wzorce projektowe powstały jako obserwacja konstrukcji, do których programista naturalnie z czasem dochodzi, bo są zwyczajnie logiczne w danym zastosowaniu, Tak więc, nie wszystkie, ale stosujemy je. Tyle tylko, że mało kiedy w ogóle zwracamy na to uwagę, nie piszemy też, że używamy w kodzie jakiegoś wzorca (choć często spotyka się taką praktykę np. w API Javy i Androida), bo jakie to właściwie ma znaczenie? Tak więc może po prostu nie potrafisz dostrzec wzorca jeśli nie wiesz, że został użyty? A może pracujesz nie z tymi ludźmi co trzeba? A może wręcz pracujesz z za dobrymi ludźmi? Wzorce projektowe to pseudonauka, w większości związana z OO. Jeśli ktoś robi FP i dobrze ogarnia teorię kategorii pewnie nie potrzebuje takich rzeczy (chociaż, ostatnio zauważyłem, że monady nazywają już wzorcem projektowym).

4

Na początku kariery nie potrafiłem spamiętać wzorców projektówych ani znaleźć dobre miejsce na zastosowanie ich. Więc je olałem i jak natrafiałem na jakiś problem to dochodziłem do rozwiązania własnymi siłami. Po poprawkach i dopracowaniu często okazywało się, że wykorzystywałem taki czy siaki wzorzec.. . Przy okazji refaktoringu zmieniałem nazwy zmiennych, metod, klas aby zgadzały się z danym wzorcem (aby ktoś wchodzący do kodu po mnie od razu rozpoznał co robi dana część) i tyle. Nie szukałem wzorców do rozwiązania problemu a raczej patrzałem jakie wzorce użyłem po rozwiązaniu problemu.

2

Jest normalne, używa się gdy trzeba. Już kilka osób napisało na ten temat. Czasem widzisz że masz duplikację w kodzie na poziomie klas, i jakiś wzorzec mógłby w tym pomóc. Pytanie, czy duplikacja znaczy dwa razy, piętnaście czy trzy? I czy nawet jeśli tylko dwa to czy ktoś potem jeszcze dołoży? Jeśli tylko dwa, i nikt tego nie ruszy... możesz śmiało zostawić. Jeśli więcej to jest okazja do zastosowani właśnie wtedy wzorców i refaktoryzacji. Nie wtedy kiedy masz jednorazowy przypadek i pewnie nigdy się to nie zmieni.

Przy czym z podejściem "teraz zrobię na odwal się, zostawię, nie wydzielę, jak za tydzień wrócę dodać kolejny to zrobię refaktoring" trzeba uważać. Bo za tydzień dostaniesz za mało czasu na zrobienie refaktoringu i dodasz kolejnego ifa, albo przyjdzie ktoś inny i

  • dostanie za mało czasu
  • nie będzie wiedział że da się lepiej, bo np jest juniorem
  • wie że da się lepiej, ma czas... ale ma wywalone bo nie jego projekt, nie za to mu płacą, woli posiedzieć na FB...
    Także często warto poświęcić czas na zbudowanie od razu dobrego rozwiązania, ale niekoniecznie na poziomie każdej linijki kodu.
1

Zapytaj kolegów z zespołów i ustalcie zawczasu czy brnąć w refactoring czy nie. Co 2 pary oczu to nie jedna + dużo czasu zaoszczędzonego podczas code review. Pamiętaj, że istnieją jeszcze bardziej fundamentalne zasady jak KISS czy DRY.

Szukanie wzorców projektowych wszędzie na siłę jest moim zdaniem typowe dla początkujących. W praktyce refaktorujesz kod do postaci, która jest czytelna i łatwa w utrzymaniu. Wzorce są efektem ubocznym. Poza tym przez blisko 10 lat doświadczenia używam głównie buildera, strategii, fabryki (tej najprostszej), dekoratorów, adapterów itp, czyli bardzo podstawowe. Zdarzyło się template method z raz czy dwa. Raz miałem do czynienia z visitorem i to był przerost formy nad treścią, ale wtedy się jarałem, że użyłem visitora - wiec całkowicie rozumiem Twój punkt widzenia :) z tego się wyrasta.

0

Odpowiedź jest prosta: wyczucie przychodzi z praktyką. Zadbaj o solidny code review ze strony bardziej doświadczonych członków zespołu, możesz też zawczasu konsultować z nimi propozycję rozwiązań jeśli masz wątpliwości.

3

Wzorce projektowe to pewne sprawdzone i powszechnie rozpoznawalne praktyki programowania obiektowego. Ich obecność nie jest gwarancją dobrego oprogramowania. Jeżeli mają sens, wnoszą jakąś wartość dodaną, to warto ich użyć. Ale celem nie jest ich używanie bo można, a stworzenie architektury prostej, łatwej do zrozumienia, testowalnej, łatwej do utrzymania, funkcjonalnej, niezawodnej. Wciskanie na siłę tam gdzie się da to iście barokowe podejście do programowania i moim zdaniem przyrost formy nad treścią.

4

mi się wiele razy zdarzyło użyć prawie wzorca projektowego którego nawet nie znałem - zorientowałem się że używam czasem wzorco-podobnych rozwiązań dopiero jak zacząłem czytać o jakiś tam wzorcach ;D

10

Jeśli w czasie pracy zastanawiasz się "jakiego wzorca projektowego użyć do rozwiązania problemu X" to znaczy, że tu jest problem. Powinieneś raczej podejść tak:

  • widzę, że trzeba zrobić X
  • potrzebuję by to zachowywało się tak i tak
  • ok, znam podejście, które się tutaj sprawdzi

I to podejście to jest właśnie wzorzec. Część wzorców się będzie używało nawet nie znając ich nazw bo "po prostu już to kiedyś robiłem".

6

@hauleth podał bardzo fajny opis stosowania wzorców w praktyce. Na pewnym etapie, który wynika z doświadczenia, wzorce po prostu zaczynają „same się stosować”. Ich urok polega na tym, że są powszechnie znanymi i akceptowanymi rozwiązaniami typowych problemów. Jeżeli potrafisz zidentyfikować problem jako „typowy”, to stosujesz „powszechnie znane i akceptowane” rozwiązanie.

Warto tu jednak pamiętać, że niektóre narzędzia narzucają stosowanie wzorców. Szczególnie frameworki mają tendencję do standaryzacji rozwiązań. To może powodować, iż niestandardowy problem będzie bardzo trudny do rozwiązania, bo narzędzie będzie utrudniać nam pracę.

3

Pierwsza rzecz jaka chciałbym od siebie dodać to przestroga, że informacje jakie możesz znaleźć w książkach czy internecie niemal zawsze nie przedstawiają kontekstu, a bez kontekstu ciężej jest zweryfikować czy dana rzecz ma sens w Twoim konkretnym projekcie. Dlatego jeśli chcesz zachować umiar to zrozum pierw potrzeby i ograniczenia projektu (zwróć też uwagę na zespół i samą firmę).

Potrzeby to przepustka na wprowadzenie słusznych zmian. Jeśli chcesz coś poprawić, zapytaj zespół co go najbardziej wkurza w projekcie, a potem namierz cel i zlikwiduj. Nie skupiaj się na problemach, które tylko Ciebie drażnią. Patrz na projekt z perspektywy zespołowej.

Druga rzecz to ograniczenia. One też są dobre. Dzięki nim wiadomo kiedy się zatrzymać. Ograniczenia pomagają przy projektowaniu, one pomagają skreślić z listy te rozwiązania, które nie pasują do projektu.

Z perspektywy projektu chodzi też o złapanie balansu. Zauważ, że gdy wprowadzasz jakaś technikę to wpływasz na ten balans, ponieważ każda technika jednocześnie coś daje i zabiera. Dlatego przed wprowadzeniem zmian nie patrz tylko na to co dostaniesz, pomyśl dwa razy dłużej nad tym co w ten sposób stracisz. Inaczej Twój projekt stanie się zbyt wcześnie trudny w utrzymaniu.

Poza tym wszystkim warto znać kilka styli pisania kodu, wtedy będziesz miał większe szanse, że wybierzesz technike, która lepiej wpasuje się w potrzeby projektu. Inaczej będziesz miał młotek, a wszystko inne będziesz traktował jak gwoźdź - to jest trochę słabe. Najlepiej wybieraj języki inne (jeśli masz język statycznie typowany to wybierz dynamiczny), poznaj też funkcyjne programowanie. Ostatecznie warto pisać w takim języku, który nie prowadzi Cię za rączkę i pozwala pisać kod różnymi stylami.

1

Warto jednak znać podstawowe wzorce, by nie pisać obiektu o nazwie Builder, który jest singletonem i działa jak fabryka.

1

Wzorce są ok, bo wprowadzają wspólne słownictwo: jak mówię „dekorator” albo „listener”, to od razu wszyscy rozumieją, co mam na myśli.

Z drugiej strony, zawsze się trochę krzywię, bo kojarzą mi się z przemądrzałymi, pretensjonalnymi architektami. Ach te rozmowy kwalifikacyjne o tym, czym jest i czym nie jest „adapter”, albo wymienianie jak największej liczby wzorców projektowych w znanych bibliotekach. Im więcej mądrych słów używasz, tym wydajesz się mądrzejszy. Tylko że nie.

1

Dodam jeszcze że warto stosować wzorce jeżeli przewidujemy że dany komponent będzie się zmieniał w jakimś kierunku, wtedy można od razu zastosować właściwy wzorzec.
Przykład :
Chcemy notyfikować naszego partnera handlowego przez odpalenie linku

  1. jeżeli ukryjemy link pod jakąś metodą, to pojawi się problem z obsługą kilku partnerów.
  2. Możemy użyć buildera, wtedy będzie łatwiej parametryzować url.
  3. Może będzie trzeba wysyłać różne dane do różnych partnerów, wtedy lepiej dekorator.
  4. Może będziemy chcieli wywoływać tę operacje z wielu miejsc wtedy można dodać command lub strategy

Im więcej wiemy o tym jaki będzie kierunek zmian/rozwoju możemy podjąć lepsze decyzje czy używać wzorca czy nie ma takiej potrzeby.

2

Z wzorcami projektowymi jest tak:

  1. Są przydatne i należy je znać i stosować.
  2. Dużo tutoriali w internecie zawiera elementarne błędy na temat sposobów ich implementacji.
  3. Nie spotkałem jeszcze źródła, które oprócz samego wzorca, opisuje też sensowne przypadki użycia, żeby czytający mógł skumać po co to istnieje i kiedy należy używać.

Spotkałem natomiast masę programistów na różnych stopniach rozwoju zawodowego (w szczególności midzi i bieda seniorzy), którzy uważają, że wzorce to bullshit, nie ma o tym co czytać, program ma działać, czy mój hit "ja jeszcze nigdy nie napisałem interface'u". Oczywiście jest dość liczna grupa, która używa wzorców, bo je obczaiła z przykładów użycia jakiś zewnętrznych bibliotek, ale nie zna ich nazw - dla mnie OK. Według mnie, bez "czucia" wzorców, nie da się wyjść powyżej widoku pojedynczej metody, ew. klasy w kodzie. Jeżeli nawet za pierwszym razem, ktoś spędzi więcej czasu na nauce jakiegoś wzorca, to za drugim razem wykona podobne zadanie szybciej, czytelniej i z mniejszym ryzykiem błędu, więc tak - warto używać wzorców, natomiast potrzeba do tego sporej praktyki, żeby wiedzieć których kiedy i w jakich wypadkach iść we własne pomysły.

1 użytkowników online, w tym zalogowanych: 0, gości: 1