[Dragon_Lord_2137]

Dlaczego wiele osób nie zwraca uwagi na to w jaki sposób mają napisany projekt? Od kilku lat łączę się na różne spotkania z programistami (praca, szkolenia itd.) i zauważyłem, że ludzie w ogóle nie stosują zaleceń wujka Boba. Na YT jest mnóstwo tego typu kanałów dot. pisania czystego kodu. Tymczasem ludzie nadal mają funkcje, w których jest kilkanaście zagnieżdżonych pętli, ifów, mają nazwy w różnych notacjach. Jakieś importy z porozwalanymi na nich modułami/bibliotekami.

Dlaczego tak jest? Zawsze miałem wrażenie, że te wszystkie korporacje, kontraktornie to są nienagannie urządzone a tu się okazuje, że z zewnątrz ładne a w środku brzydactwo. Ja się zastanawiam czy dobrze nazwałem funkcję, czy nie rozbić jej na kolejne kilka mniejszych, a tu ktoś wrzuca commit z tysiącami nowych linii i jest zadowolony(?)

#programowanie #programista15k #pracait #pytanie #pdk

[Krolik]

@Dragon_Lord_2137: Poka konkretny przykład. To, że w projektach jest gówno w kodzie to normalka, ale z drugiej strony rygorystyczne przestrzeganie zaleceń "wujka Boba" wcale nie jest receptą na dobry kod.

[peoplearestrange]

@Dragon_Lord_2137: podczas gdy ty czytasz kolejna ksiazke pt "jak dobrac skarpetki aby kod byl przejrzysty", pan Rakesh awansuje na SWE LVL5 w gugl ( ͡° ͜ʖ ͡°)

[wpiot]

@Dragon_Lord_2137: Wiele powodów, np. pracowałem z spagetti-potworkiem z ośmiotysięcznikami, kodem praktycznie nietestowalnym przez kilkanaście zależności, jakieś statyczne klasy i przychodził ktoś nowy, refaktoryzował, wszystko fajnie, każdy zapomniał o tej zmianie i za 2 miesiące jest release i jest fakap. Jak dostaniesz tak kilka razy po łapach to się odechciewa.

[Saly]

@Dragon_Lord_2137: zalecenia wujka Boba to bizancjum, które może zaszkodzić bardziej niz pomóc. Najważniejsze w pisaniu dobrego kodu to dbanie o dobrą modułowość. Jeśli kod jest dobrze podzielony tak, że wiadomo co gdzie jest i nie ma miejsc, które robią wiele rzeczy to masz łatwo utrzymywalny kod, nawet, gdy masz funkcje na 200 lini i brak dynamicznego polimorfizmu.

Dlaczego pisanie dobrego kodu jest trudne? Bo się to nie opłaca na początku a

[WaveCreator]

@Dragon_Lord_2137: Bo ostatecznie na jakość kodu wpływa głównie to na ile programiści mają czas by go dopracować - a jak firmy wykorzystują "adżajl" jako wymówkę by robić dużo i byle jak, byle dowieźć i klient zapłacił, to potem są takie efekty (bo klientowi wisi czy kod jest spaghetti czy nie - jego interesuje czy był w terminie i działa).

No i korporacje a kontraktornie/software house'y to dwa zupełnie inne tematy -

[5da4266d3de6dbaf425a2d4fc16225d0]

Dlaczego tak jest?

@Dragon_Lord_2137: Częsta przyczyna to "ewolucja kodu" - na początku wszystko jest ładnie i schludnie, ale z czasem przychodzą nowe wymagania z biznesu, które często są w konflikcie z początkowymi wymaganiami i założeniami. Jednocześnie nie ma czasu przepisywać projektu od nowa i zamiast tego zaczynają się różne "hacki". Podobnie jest z poprawkami i bugami, często żeby coś zrobić "dobrze" musiałbyś przeorać cały codebase, a zamiast tego możesz wcisnąć jednego

[eloar]

@Dragon_Lord_2137: bo uruchomiony projekt jest cenniejszy niż "czysty" projekt. Trzymanie się na siłę czystego kodu to często przejaw prokrastynacji.

[groman43]

udzie w ogóle nie stosują zaleceń wujka Boba

@Dragon_Lord_2137: Bo zalecanie wujka Boba to jedna wielka kupa ( ͡° ͜ʖ ͡°)

[murdoc]

@Dragon_Lord_2137: nom, to pokaż nam ten swój idealny projekt. Ale warunek - musi być na prodzie

[barnej-flinston]

@Dragon_Lord_2137: w każdym projekcie masz nasrane, a nikt nie będzie dawał drugie tyle czasu na zadanie jeśli spełnia zadanie biznesowe, a dopiero na C/R wyszło że kod jest #!$%@?, bo pisał fullsztak tydzień. Tym bardziej że często/gęsto taki gówniany kod żyje do końca projektu nieruszany. Ważne żeby kluczowe rzeczy były napisane przez bardziej ogarnięte małpy, w sumie to projekt jest jak drzewo - korzenie i pień muszą być w miarę wolne

[nad__czlowiek]

Dlaczego wiele osób nie zwraca uwagi na to w jaki sposób mają napisany projekt? Od kilku lat łączę się na różne spotkania z programistami (praca, szkolenia itd.) i zauważyłem, że ludzie w ogóle nie stosują zaleceń wujka Boba. Na YT jest mnóstwo tego typu kanałów dot. pisania czystego kodu. Tymczasem ludzie nadal mają funkcje, w których jest kilkanaście zagnieżdżonych pętli, ifów, mają nazwy w różnych notacjach. Jakieś importy z porozwalanymi na nich

[nad__czlowiek]

Dlaczego pisanie dobrego kodu jest trudne? Bo się to nie opłaca na początku a potem jest już za późno. Niepotrzebnie uczy się programistów jak pisać idealny kod, gdzie IMO dużo większy nacisk powinień być na pisaniu dobrego kodu, który jest oczywisty. Dużo ważniejsze jest np. odzielenie warstwy danych od logiki niż napisanie mądrej abstrakcji, gdzie mamy dużo interfejsów. Jeśli kod jest dobrze podzielony to refaktor takiego zagmatwanego kodu jest trywialny. Najgorsze projekty

[nad__czlowiek]

@Dragon_Lord_2137: w każdym projekcie masz nasrane, a nikt nie będzie dawał drugie tyle czasu na zadanie jeśli spełnia zadanie biznesowe, a dopiero na C/R wyszło że kod jest #!$%@?, bo pisał fullsztak tydzień. Tym bardziej że często/gęsto taki gówniany kod żyje do końca projektu nieruszany. Ważne żeby kluczowe rzeczy były napisane przez bardziej ogarnięte małpy, w sumie to projekt jest jak drzewo - korzenie i pień muszą być w miarę wolne

[matka_boska_w_klapie]

@Dragon_Lord_2137 bo liczy się to jak szybko rozwiązujesz taski a nie czy kod jest czysty

[szpongiel]

@nad__czlowiek

robienie z kodu jakiegoś jednego wielkiego schematu dziedziczącego zamkniętego na modyfikacje i otwartego na rozszerzenia.

Ogólnie to się zgadzam z tym co piszesz ale czy jesteś powinien, że open-closed principle zaleca właśnie, czy wręcz wyłącznie używanie dziedziczenia?

Bo jeśli tak, to sorry ale ktoś Ci wkręcił lipę ( ͡° ͜ʖ ͡°)

[meme_generator]

@Saly Polecam zobaczyć jakie cuda można robić ze statycznym polimorfizmem w Rust. Okazuje się często, że w zasadzie dynamiczny nie jest potrzebny ale wiele języków tylko taki obsługuje.

[szpongiel]

@matka_boska_w_klapie

liczy się to jak szybko rozwiązujesz taski a nie czy kod jest czysty

Tylko, że gdy taski są do rozwiązania w kodzie, w którym jest nasrane, to nie ma mocnych, będą rozwiązywane wolniej niż we względnie czystym.

Także o ile nie piszesz apki, która ma krótki żywot (np. kampania marketingowa na 3 miesiące, a potem projekt idzie do zsypu) to co przestajesz ma swoją nazwę: fałszywa alternatywa.

Tzn. to nie jest

[szpongiel]

@eloar
@Dragon_Lord_2137

bo uruchomiony projekt jest cenniejszy niż "czysty" projekt.

Tylko jeśli nie sam go utrzymujesz/rozwijasz.
Czyli dość często gdy dostawca jest zewnętrzny i ma płacone za dostarczenie, a potem elo.

Trzymanie się na siłę czystego kodu to często przejaw prokrastynacji.

Zgodzę się, że ślepe aplikowanie jakichś "najlepszych" praktyk czy wzorców projektowych bez zrozumienia może przynieść więcej szkody niż pożytku. Ale pisanie czystego kodu niemal nic nie kosztuje. Wystarczy nie być niechlujem

[matka_boska_w_klapie]

Tylko, że gdy taski są rozwiązania w kodzie, w którym jest nasrane, to nie ma mocnych, będą rozwiązywane wolniej niż we względnie czystym.

@szpongiel: Za takie podejście (tzn wymaganie przeze mnie aby kod był czytelny) wyrzucili mnie z ostatniej firmy w której pracowałem.