Kod doskonały vs rzeczywistość Opcje

[Omenomn]

Cześć, programuję w php, js, html, css, czyli taki standard jeżeli chodzi o strony www, frameworki to: laravel, vue.js, materializecss, może niektórzy mnie kojarzą po nicku.

Spotykam się czasem podczas pisania aplikacji z tym, że w pewnym momencie np. w połowie prac, uświadamiam sobie, że kod jest bardziej zawile napisany niż mógłbym być.
Załóżmy, że chciałem zastosować do kilku funkcjonalności tą samą część kodu i teraz okazuje się, że, aby tą część wykorzystać, komplikuję sobie świeżo pisane rzeczy, żeby je dostosować do tego co już mam. Teraz przyszło mi na myśl, czy aż tak ważne jest to, aby nie powielać kodu, bo w sumie kierując się taką genezą, wszystko mam (tak mi się wydaje) napisane bardziej zawile, ostatecznie tylko po to, żeby wykorzystać istniejące elementy i dostosować do nich nowe.
Przeważnie znajdują się jakieś mini różnice w poszczególnych funkcjonalnościach, które po zsumowaniu robią o wiele większy bałagan niż jakby napisać dla każdej funkcjonalności oddzielnie ten "uniwersalny kod".
Dodatkowo, jeśli teraz chciałbym zmienić rzeczy, które są używane w kilkunastu miejscach, to te kilkanaście miejsc przestaje działać z automatu i muszę je wszystkie poprawiać.
Nie wiem, czy przedstawienie sprawy w tak ogólny i teoretyczny sposób pozwoli Wam się odnieść do tematu, jeśli nie to podam jakiś przykład.

Druga rzecz, to np. 5 lub więcej rozwiązań jednego problemu, gdzie większość wydaje się być niezła.
Jak podejmujecie decyzje, czy na szybko, czy jakoś bardziej analizujecie, bo mi schodzi trochę czasu na takie analizy i jest to dość irytujące?

Mam w sobie jakąś taką cechę, że strasznie drażni mnie jak zaczyna się robić bałagan i zależy mi bardzo na prostocie i przejrzystości tego co piszę, zarówno od strony użytkownika jak i programisty, chciałbym, żeby to co piszę było idealne i jak mi się nie udaje to mam nerwy.

Czy macie podobne problemy, jeśli tak, jak sobie z nimi radzicie?

Może to kwestia doświadczenia, programuję zawodowo już praktycznie 2 lata, więc trochę doświadczenia nabrałem, ale to jednak nie 10 lat:p
Próbuję sobie wytworzyć jakieś standardy i rozwiązania powtarzalnych problemów, czyli np. stosować jeden lub dwa typy formularzy we froncie, na upload filmów mieć jeden sprawdzony sposób po stronie użytkownika i serwera, usuwanie zasobów też działające w konkretny sposób do wielokrotnego stosowania.

Tylko teraz pytanie się pojawia, czy chcąc budować taką swoją bazę rozwiązań nie zostanę w tyle, przez to, że nie zapoznaję się z innymi narzędziami, a pracuję cały czas na tych samych, oczywiście aktualnych wersjach.

Co sądzicie?

[com]

Mówię o routingu. Dziwnie Cię zdziwiło, że są metody przypisane do konkretnej akcji z urla.

Nie napisałem że coś w tym dziwnego, napisałem, że masz tu strategie o której ja i inni mówiliśmy.

Nieprawda, znajdź mi informację, że w dekoratorze kolejność dekoratorów ma nie mieć znaczenia.
Choćby zawsze musi istnieć końcowy dekorator, który nie przyjmuje wartości do konstrukora, więc jeżeli musi istnieć końcowy, to może istnieć początkowy i może istnieć ustalona kolejność.

Wgl nie zrozumiałeś dekoratorów.

Jedyne co musi istnieć to klasa która rozszerzasz, ona ma jakaś funkcjonalność w Twoim przypadku bazą jest Upload. I kiedy podczas tego uploadu zależy Ci żeby powstała miniaturka, wiec dodajesz do istniejącego obiektu Uploadu zrób mi miniaturkę. Dlatego tworzysz dekorator, którego jedynym zadaniem jest zmienić obiekt bazowy tak żeby zamiast pełnego obrazu zwrócona została miniaturka w jego miejscu.
Dla innego route chcesz miniaturkę obrócona o 180 stopni. Wiec bierzesz klase Upload bierzesz dekorator Thumbnail i dekorator Rotate i masz miniaturkę i obrócony. Ale nie ma znaczenia czy najpierw obrócisz potem zmniejszysz czy na odwrót i tak i tak efekt zawsze jest taki sam i tak powinno być u Ciebie, a tak nie jest bo u Ciebie każda klasa zależy od innej. W przypadku prawdziwego dekoratora nadawane ograniczenia/zmiany na obiekcie są od siebie nie zależne, wiec mogę mięć: miniaturkę; miniaturkę i obrócony == obrócony i miniaturka; obrócony, a wszystko to bez jakiejkolwiek zmiany w kodzie. Twoje początkowe założenie było blednę, czyli:

Choćby zawsze musi istnieć końcowy dekorator

Nie ma czegoś takiego jak początkowy czy końcowy dekorator, jest obiekt który dekorujesz i jeśli dekoratory maja ten sam interface co ten obiekt, to można je ze sobą składać tak jak było opisane w przykładach, ale tylko i wyłącznie wtedy.

Soryy, ale nie bede sobie "nieulatwial" pracy tylko dlatego ze ktos moze kiedys nie wiedziec jak tego uzyc...

Tu wcale nie chodzi o nie ułatwianie pracy, bo po to zaproponowane zostało użycie wzorców, żeby te rozwiązanie było jak najbardziej elastyczne i można było wykorzystać je w wielu projektach, ale wzorce zostały zdefiniowane w taki sposób, żeby każdy kto sporzy na kod, znając je wie jaki będzie efekt. A kiedy kolega Omenomn po roku czy dwóch latach wróci do tego kodu coś zmienić, najpierw znów będzie musiał wdrożyć sam siebie jak to działa i czemu tak to zrobiłem wtedy a nie inaczej.

Przeczytaj jeszcze raz uważnie co tam zostało napisane
http://blogophp.com/2009/08/16/dekorator/#more-40
Najistotniejsze fragmenty

// obiekty tej klasy beda dekorowane
class SimpleText extends Information

Proszę zwrócić uwagę na fakt, iż gdy obiekt dekorowany jest tego samego typu co dekoratory jesteśmy w stanie ?dekorować? również dekoratory

obiekt dekorowany !== dekorator i nie możesz go nazwać dekoratorem końcowym.

Pomijając już sam fakt, że tak jak tam było:
new FirstLetter(new TextLength(new SimpleText()));
Dekoratory idą od środka w górę, a u Ciebie odnoszę wrażenie, że idziesz od początku w dół, przynajmniej tak wynikało z pierwszego opisu.

Trochę wracając jeszcze do tematu frameworka i jego roli, o czym mówiliśmy wcześniej to przykład od olx:


Ten post edytował com 11.01.2017, 19:27:12