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?

[Omenomn]

Wskaż mi gdzie framework ma coś nie udokumentowane i nie wiesz co uzyskasz jak wykonasz dany fragment jego kodu.

To trochę tak jakbyś z kota chciał zrobić mysz

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

Podsumowując, właściwości nie powinny wędrować miedzy dekoratorami, bo wtedy już to nie jest dekorator! Dekorujesz konkrety obiekt bazę która rozszerzasz, a nie budujesz nad obiektem bazy nowego obiektu do rozszerzeń. Każdy dekorator to niezależny byt, który możesz wywołać bezpośrednio na obiekcie bazowym zawsze i nie potrzebujesz do tego więcej dekoratorów po drodze.

Miedzy dokoratorami będę przekazywał obiekt, w którym będzie się znajdował kontent pliku plus inne atrybuty, które można modyfikować, a nie jak do tej pory sam kontent. Dlatego musiałem rozwiązać problem przekazywania właściwości, ale z obiektem będzie prościej o wiele.

To:

[PHP] pobierz, plaintext 
$video = new PropertyGeter(
       new ThumbnailFromVideoCuter(
            new ContentGeter(
                    new FilePuter)));
[PHP] pobierz, plaintext 

i to:

[PHP] pobierz, plaintext 
$video = new ThumbnailFromVideoCuter(
 new PropertyGeter(       
            new ContentGeter(
                    new FilePuter)));
[PHP] pobierz, plaintext 

Ma dać ten sam efekt, daje, zapewne nie bo ThumbnailFromVideoCuter() zależy pewnie od obiektu PropertyGeter(), skoro potrzebny był Ci obserwator.

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ść.

[solificati]

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ść.

Principle of least astonishment jak to się w kulturze OOP nazywa. Gdy kolejność ma znaczenie to wprowadzasz składnię a to się liczy conajmniej jako "zaskoczenie".

Precyzując, Dekorator implementuje ten sam interfejs, który implementuje obiekt który jest dekorowany. Żeby dekorator mógł korzystać z pól dodanych przez inny dekorator, musisz wprowadzić drugie drzewo dekoratorów bazujące na poszerzonym interface albo ich produkcie.

Ten post edytował solificati 11.01.2017, 15:34:27