Wątek przeniesiony 2019-08-14 11:27 z przez Shalom.

Stosowanie wzorców projektowych w pracy.

Odpowiedz Nowy wątek
2019-08-14 11:05
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 :)

Pozostało 580 znaków

2019-08-14 11:13
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.

Kod ma działać, ma działać szybko ale też powinien być czytelny dla innych ludzi - jak zapomnisz o tym ostatnim "warunku" to kod po jakimś czasie będzie ciężki do utrzymania - Markuz 2019-08-16 13:48

Pozostało 580 znaków

2019-08-14 11:14
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.

To jak ten umiar znaleźć ? To jest problem. Z jednej strony chcę aby była super jakość kodu, ale też jest wydajność. - evenuel 2019-08-14 11:22
myślę, że w dużej mierze przychodzi to z doświadczeniem. Parę razy zawalisz w jedną czy w drugą stronę, to się nauczysz :) - no_solution_found 2019-08-14 11:33
@evenuel: Przez praktykę, innej drogi nie ma. Metodą prób i błędów dochodzimy do tego co właściwe. Chociaż są pewne sposoby na to, żeby próby przynosiły więcej wniosków. - elwis 2019-08-14 11:37

Pozostało 580 znaków

2019-08-14 11:25
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.


Prosząc o pomoc w wiadomości prywatnej odbierasz sobie szansę na otrzymanie pomocy od kogoś bardziej kompetentnego :)
edytowany 2x, ostatnio: superdurszlak, 2019-08-14 11:32

Pozostało 580 znaków

2019-08-14 11:29
var
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ć.

edytowany 1x, ostatnio: var, 2019-08-14 11:29

Pozostało 580 znaków

2019-08-14 11:29
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).


edytowany 5x, ostatnio: elwis, 2019-08-14 11:37
Pokaż pozostałe 10 komentarzy
@somekind: jest pewna różnica między gotowaniem i programowaniem. Przede wszystkim na temat programowania jest ogromna ilość teorii, prac naukowych i generalnie programista powinien z tego korzystać. Dzieje się inaczej bo zapotrzebowanie na programistów znacznie przewyższa podaż. Dlatego zaniża się poziom, stąd pseudonauka jest dobrym rozwiązaniem, przynajmniej dla tej masy ludzi którym się nie chcę ogarniać albo nie czają matematyki. - elwis 2019-08-23 13:48
Owszem, programista powinien znać teorię informatyki. Wzorce projektowe do niej nie należą, to pojęcie z innej dziedziny - inżynierii oprogramowania. Nie ma powodu, dla którego miałoby się formalnie udowadniać wzorce projektowe. No i ogólnie dowiedz się najpierw, czym jest pseudonauka. - somekind 2019-08-23 23:53
Trochę sobie rozszerzyłem pojęcie. Mam do tego prawo. Inni zrozumieli. - elwis 2019-08-24 06:41
Jasne, to ma nawet nazwę straw man. - somekind 2019-08-24 11:10
Co tu pleciesz człowieku? daj mi spokój. - elwis 2019-08-24 14:15

Pozostało 580 znaków

2019-08-14 11:43
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.

Pozostało 580 znaków

2019-08-14 12:09
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.

Pozostało 580 znaków

2019-08-14 14:37
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.

edytowany 1x, ostatnio: Charles_Ray, 2019-08-14 14:39

Pozostało 580 znaków

2019-08-14 14:51
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.

Pozostało 580 znaków

2019-08-14 21:43
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ą.

edytowany 2x, ostatnio: nalik, 2019-08-14 22:53
Wzorce projektowe występują nie tylko w programowaniu obiektowym. - hauleth 2019-08-16 12:32

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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