[Nexiu]

#php #programowanie

Polecicie cos poza 'Czysty Kod' do nauki pisania ładnego obiektowego kodu?
To co pisze to niby robi to co chce, ale wygląda znacznie inaczej od tego jakbym chciał żeby wyglądało... Dziś pobralem z gh paczkę do API poczty polskiej i to tam jest wszystko tak ładne i poukladane, że aż zazdroszczę

[Saly]

@Nexiu: czytaj projekty, wybieraj to co ci się podoba i na tym oprzyj swój gust. Czysty kod według mnie nie prowadzi do dobrego kodu. Jak dla mnie to do dobrego kodu prowadzą takie praktyki:
* immutability gdzie się da, zwłaszcza na poziomie interfejsów
* dobra modularyzacja, ograniczenie połączeń pomiędzy modułami
* zero globali
* myślenie o koszcie wprowadzenia abstrakcji np. zamiast przepychać fabrykę zazwyczaj dużo prościej jest przepchać interfejs
*

[uzytkownik_wykop_pl]

@Nexiu z pewnością nie polecimy czystego kodu

[cppguy]

@Nexiu:

w pierwszej kolejnosci to ktos w ogole kiedykolwiek polecal czysty kod nieironicznie? xddd

[Nexiu]

@Saly @uzytkownik_wykop_pl @cppguy
Co do CK, to kilkanaście razy mi się na yt na różnych polskich kanałach nawinął, ale nie mogłem jakoś nigdy pokonać pierwszych 30 stron.

I dzięki @Saly że chciało Ci się pisać.

[Nexiu]

Na przykład teraz kończę Job'a odpowiedzialnego za adresowanie przesyłek przy pomocy wspomnianego wcześniej projektu co mi się tak spodobał, to nie wiem czy na studiach bym za to dostał +2, pomimo, że mi działa i robi co chce :-P

Niestety, jako samouk to nie ma mi kto nawet za bardzo zrobić code review, co z tego, że mam świadomość, że to co robię nie jest dość dobre, jak tylko powielam swoje złe

[mariecziek]

@Nexiu: Na początek warto byłoby przestać używać polskich zmiennych. Skoro masz wszystko po angielsku, to ta zmienna poczta pasuje tam jak pięść do nosa.

[Nexiu]

@mariecziek te polskie zmienne to nie mój (no dobra, z wyjątkiem zmiennej poczta) , ale tylko dlatego, że kod z GH używa Polsko-angielskich nazw zmiennych, ogólnie to często widzę to w projektach rozwijanych lata (a tu akurat mowa o e nadawcy poczty polskiej co jest na rynku od ponad 13 lat)

[Krolik]

@Nexiu: kilka zasad którymi się kieruję i mnie jeszcze nie zawiodły:

- Starać się nie mieszać zupełnie różnych odpowiedzialności / funkcjonalności w jednym miejscu - budować kod z prostych klocków, na tyle prostych że każdy można ogarnąć bez konieczności rozumienia jak działają inne. Dodatkowy efekt uboczny to łatwiejsze testowanie. Przykładowo: kod obliczeniowy nie powinien robić we/wy i nie powinien w ogóle musieć wiedzieć jak będzie formatowane wyjście i wyjście.
- Komponenty realizujące jakąś jedną funkcję systemu trzymać blisko siebie. Oznacza to, że w przypadku klasycznego weba w jednym pakiecie będzie kontroler, DTO, DAO, widok itp, a nie osobne pakiety na każdą warstwę. Ciacham system pionowo a nie poziomo. Analogicznie jeżeli jest gdzieś kodowanie danych to dekodowanie musi być blisko, najlepiej nawet w tej samej klasie/module. Dzięki temu zmiany można ograniczyć często do jednego pakietu. To taki odwrotny SRP.
- Nie robić funkcjonalności “na przyszłość” a szczególnie nie starać się zgadywać jakie będą zmiany. Jak będzie konieczność zmiany to zrobi się wtedy.
- Zrozumiałość i prostota kodu jest ważniejsza niż rozszerzalność. Lepiej zmodyfikować prosty i konkretny kod w pięciu miejscach niż dopisywać nowy kod do przekombinowanej fabryki

[y0da]

@Nexiu: Single Responsibility Principle to protip

[Pieczu666]

@Nexiu: Moje kilka spostrzeżeń, na bazie tego z kim, co i jak do tej pory robiłem. Dodam, że jestem tylko studentem i z takimi ludźmi miałem do czynienia - nie pracuję jako programista.
- Wiele osób robi błąd na zasadzie tworzenia dodatkowej zmiennej/referencji do jakiejś wartości np. podanej jako argument funkcji, albo wynik działania innej funkcji tylko po to, żeby później użyć tego dokładnie jeden raz, przez co dany blok kodu zawiera często 10+ linijek, które da się skrócić do 4-5 ¯_(ツ)_/¯
- Nie wyodrębniam kodu do osobnej funkcji, jeżeli nie użyłem go więcej niż 2 razy.
- Nie do końca mam wiarę w siebie oraz innych kiedy mówią, że wystarczy popatrzeć na kod i zrozumiem wszystko bez komentarzy/dokumentacji. Tak jak mówi @Krolik - komentować ile wlezie, ułatwi to pracę wszystkim łącznie z tobą samym, jak będzie trzeba do czegoś wracać.
- Jako, że #php to polecam używać typów zmiennych w argumentach funkcji oraz ewentualny typ zwracany jeżeli jakikolwiek występuje.
- Nie stosować w 100% Clean Code, bo można narobić więcej szkód niż dobrego, szczególnie w małych aplikacjach. SRP jest zawsze mile widziane, ale trzeba zorganizować swój kod tak, aby nie okazało się że musimy przebrnąć przez 8 funkcji w 5 różnych klasach aby dowiedzieć się jak coś działa, trafiałem na takie potworki i miałem szczerze mówiąc

[Krolik]

- Nie wyodrębniam kodu do osobnej funkcji, jeżeli nie użyłem go więcej niż 2 razy.

@Pieczu666: A to jest na ogół błąd. Wyodrębnienie funkcji nie powinno być na podstawie tego ile razy jest użyta, tylko na podstawie tego, czy istnienie funkcji upraszcza kod z którego jest wywołana. Tzn. jeśli łatwiej jest zrozumieć sygnaturę + opis funkcji niż jej implementację, to należy wydzielić.

Ponadto wydzielenie kodu do funkcji czasami pozwala czasem uprościć samą implementację tego wydzielanego kodu. Przykładowo wewnątrz małej funkcji może się okazać, że możesz wykorzystać early return, natomiast dopóki ten kod jest inline z pozostałym kodem, to nie

[Pieczu666]

@Krolik: Mój błąd, nie doprecyzowałem tutaj ( ͡° ʖ̯ ͡°) Oczywiście jak kod zaczyna być zbyt skomplikowany i ciężko się go czyta to lepiej rozdzielić, chodziło mi o to, że spotykałem się też z funkcjami zawierającymi 1-3 linijki bardzo prostego kodu, którego wydzielenie bardziej komplikowało sprawę, a dalsza użyteczność była zerowa.