Czy wasz kod zawsze jest w waszych oczach niewystarczająco dobry?

Piszę sobie teraz taki większy projekt, szukałem w Internecie podpowiedzi do jednego problemu programistycznego z którym teraz się zmagam, znalazłem całe rozwiązanie z całym kodem, i żałuję bo jak na niego patrzę to mam wrażenie że to wszystko nie ma sensu bo ja tak świetnego kodu sam napisać nie jestem w stanie. Łapie mnie wtedy zawsze takie programistyczne przygnębienie że cały mój projekt z moim własnym kodem nie ma racji bytu bo nie dorównuje ani trochę do tych które widzę napisane przez innych.

Oczywiście zdaję sobie sprawę że to kwestia treningu. doświadczenia itd. jednak myślę że wiele programistów ma ten sam problem. Własny kod zawsze wydaje się słaby, z czego to wynika i jak sobie z tym radzicie?

Albo łapie Ciebie "impostor syndrome" (poszukaj sobie) albo faktycznie twój kod jest taki że oczy wypala.... niestety tego ostatniego ocenić nie mogę. Wrzuć link to jakiegoś projektu na GH to będzie można popatrzeć czy się mieścisz w "normie" :P

Tak, moj kod jest dla mnie zawsze za slaby, ale nie mysle nad tym dlugo - wole skupic sie na tym aby byl coraz lepszy, chociaz mysle, ze nigdy nie bedzie zbyt dobry. Czy to bez sensu? Dla mnie nie.

Jest idealny.

W sporcie jest podobnie, jak idę gdzieś pokopać piłkę to się łapie za głowę - jak tak słabo można kopać piłkę.

Trzeba ćwiczyć, reflektować, popełniać błędy, uczyć się. Tak naprawdę założę się, że jakby na ten „super kod”, który znalazłeś popatrzył ktoś doświadczony, tez znalazłby jakieś mankamenty albo zrobiłby pewne rzeczy inaczej. Wszystko przyjdzie z czasem, a „idealny kod” nie istnieje. Kod może być „wystarczająco dobry” ;)

Podstawowa sprawa - czy to, co piszesz to działa? Spełnia swoje zadanie?
Jak dostajesz temat do ogarnięcia to umiesz sobie z tym poradzić?
Jak masz coś nowego - jakąś bibliotekę czy framework to umiesz w miarę bezstresowo się w niego wdrożyć?
Jak pracujesz nad swoimi projektami sprzed paru miesięcy/lat to da się je w miarę bezstresowo przerobić/rozszerzyć/zrobić refactor, czy łatwiej jest to wszystko zaorać i napisać od nowa?

Jeśli na w/w odpowiesz "TAK" to znaczy, że nie ma wielkiego problemu. Nie każdy musi mieć umiejętności kierowcy rajdowego, żeby swoją taksówką sprawnie i bezstresowo zawieźć klienta na miejsce.

A dodatkowo - skoro wiesz, że masz problem (czy wymyślony czy prawdziwy to inna sprawa) ze swoim kodem, to masz jakiś cel, nad którym możesz pracować w przyszłości. Ale to tak "przy okazji" - bo główne cele Twojego pisania (czyli powyższe pytania) zostały osiągnięte, kod działa i jest OK, jedynie trzeba popracować nad kosmetyką.

I tak za dobry biorąc pod uwagę organizację pracy oraz stawkę.

Kiedyś chyba więcej porównywałem się do innych. Obecnie czasem, jak patrzę na kod innych, myślę: dlaczego to jest tak napisane? nie lepiej zrobić tak, tak lub tak (przychodzą mi do głowy różne konfiguracje kodu). Czasem znów myślę: cóż, ja bym to inaczej napisał… ale skoro działa, to co za różnica.

Generalnie chyba z wiekiem (doświadczeniem?) spłaszcza mi się wizja własnych potrzeb. Nie potrzebuję tak dużo i tak mocno. Po pierwsze staram się, by działało; po drugie, by nie było błędów; po trzecie, by było utrzymywalne (dzięki dobrym praktykom pisania kodu, wzorcom projektowym i tym podobnym). Trochę jak piszą @teofrast i @cerrato . Oczywiście to staranie różnie wychodzi. ;) Nie wiem zresztą, czy więcej jest to proces automatyczny, czy świadomy.

@ProgramistaPralki , jeśli chodzi o Ciebie… Nie wiem, jak widzisz proces tworzenia oprogramowania, ale ja patrzę na niego tak, przynajmniej póki co, że jest idea, zarys, architektura – a na nią "nakłada się" warstwę kodu. Ta "idea" może być w głowie w przypadku niewielkich projektów; w przypadku większych można ją ująć w formalne ramy wymagań funkcjonalnych, diagramów UML czy tym podobnych. Dzięki oddzieleniu tej "idei" i kodu, łatwiej chyba przychodzi powiedzieć: kod jest, jaki jest. Możesz spróbować tak patrzeć na to.

Czekam na @LukeJL , bo on ma fajne przemyślenia w takich tematach. <myśli>

Bo kodu nie napiszesz ładnego ot tak (chyba, że masz tonę doświadczenia i robiłeś w przeszłości podobne rzeczy do tego, co robisz).

Trzeba więc iterować, robić rzeczy albo ciągle od nowa albo choć trochę przerabiać to, co się napisało. Sprawdzać różne podejścia.

Można też zapoznać się z zasadami stosowanymi przez programistów jak DRY, SOLID, KISS, YAGNI i innymi. Możesz poczytać o złożoności algorytmicznej (to też daje do myślenia). Możesz poczytać o hexagonal architecture czy innych rzeczach. Trzeba i tak jednak rozeznać, którą zasadę czy wzorzec kiedy stosować. Bo samo przeczytanie i stosowanie czegoś z książki niekoniecznie da pozytywny wynik (chociaż żeby się nauczyć, trzeba robić najpierw coś źle).

Warto też poznać dobrze i zaufać językowi, w którym się pisze. Dzisiaj są mega rzeczy w językach programowania (np. odpowiednio wykorzystane generatory czy async/await w JS potrafią ułatwić pisanie asynchronicznej logiki. Ale musisz wtedy sam kombinować, jak wykorzystać możliwości języka, starać się wyjść dalej niż większość, bo większość programistów używa języka w sposób prymitywny).

ProgramistaPralki napisał(a):

bo nie dorównuje ani trochę do tych które widzę napisane przez innych.

1. Możesz mieć ból d**y, ale możesz też się pogodzić z tym, że nie jesteś najmądrzejszy w pokoju i że ktoś wpadł na bardziej błyskotliwe czy po prostu lepsze podejście. Inaczej to nic by człowiek nie mógł zrobić, bo zawsze ktoś będzie lepszy.
2. Pewnymi rzeczami można się zainspirować, np. jeśli widzisz, że ktoś zamiast jednej wielkiej klasy zrobił kilka małych i jest bardziej elegancko - to też tak możesz zrobić, jeśli widzisz, że zrobił coś w postaci prostej pętli zamiast robić drabinkę ifów na 100 linijek - też możesz później tak zrobić (takie przykłady tylko).
3. Ale z drugiej strony - skąd wiesz, że dany kod jest faktycznie dobry? Czasem kod wydaje się dobry, a w praktyce zastosowane techniki albo nie robią wielkiej różnicy albo (co gorsza) robią różnicę na gorsze (np. często kod najeżony wzorcami obiektowymi wygląda ładnie na pierwszy rzut oka, ale jest nieutrzymywalny na dłuższą metę).

Co do 3. to przydaje się doświadczenie komercyjne i wejście w jakiś duży projekt wyglądający na profesjonalny. Wtedy zobaczysz, że niestety wiele kodów tylko wygląda na profesjonalne, a w rzeczywistości są to przykłady wesołej twórczości pseudoseniorów czy juniorów, którzy się naczytali czegoś o wzorcach.

(chyba, że masz tonę doświadczenia i robiłeś w przeszłości podobne rzeczy do tego, co robisz)

I tak po roku czy dwóch jak na to spojrzysz to będziesz miał kaca moralnego i mocne poczucie zażenowania ;)

zapoznać się z zasadami stosowanymi przez programistów jak DRY, SOLID, KISS, YAGNI i innymi

To powinno się samo pojawić/wykształcić z czasem. Jedną z większych bolaczek ludzi początkujących jest pchanie na siłę wzorców i ścisłe trzymanie się jakichś zasad (mimo, że nie jest to niczym uzasdnione i można lekko nagiąć pewne wytyczne z zyskiem dla jakości projektu)

Możesz poczytać o hexagonal architecture czy innych rzeczach

Cargo kult? :P

pogodzić z tym, że nie jesteś najmądrzejszy w pokoju i że ktoś wpadł na bardziej błyskotliwe czy po prostu lepsze podejście

Ciężko oceniać, nie znając okoliczności. Nie wiemy, ile czasu dany kod był pieszczony, ile osób brało udział w jego CR albo w inny sposób doradzało, może jest wzorowany na jakimś innym?

cerrato napisał(a):

To powinno się samo pojawić/wykształcić z czasem. Jedną z większych bolaczek ludzi początkujących jest pchanie na siłę wzorców, ścisłe trzymanie się jakichś zasad (mimo, że nie jest to niczym uzasdnione i można lekko nagiąć pewne wytyczne z zyskiem dla jakości projektu)

Zgadzam się.

Tylko to dylemat. Z jednej strony poczytanie o czymś może pomóc, rozwinąć, z drugiej strony masę ludzi robi to za wcześnie. Idealnie by było, jakby ktoś już miał na tyle doświadczenia, że sam by doszedł do choćby części z tych zasad i mógłby sam rozeznać "faktycznie, to ma sens! Też to zauważyłem". Jeśli ktoś jednak nie ma na tyle doświadczenia, to niestety później wpada w cargo cult.

Tylko, czy należy unikać cargo cultu? Ja mam wrażenie, że cargo cult może być normalnym etapem rozwoju programisty i że nie on jest problemem, co fakt, że niektórzy w nim zostają przez całe lata, nie idą dalej, nie mądrzeją.

Ale to chyba problem z tym, jak jest nauczane programowanie. Mamy dużo materiałów, które uczą różnych technik/wzorców/zasad programowania (czyli książki, które cię nauczą JAK programować, począwszy od tego jak pisać ify, pętle aż po zasadę SOLID, wzorce bandy czworga czy machine learning), natomiast mało jest materiałów, które pokazują DLACZEGO (albo DLACZEGO NIE), PO CO czy CO ZAMIAST TEGO. Więc ludzie potem wiedzą JAK programować, ale tylko w ten sposób, jakiego się nauczyli (z książek, tutoriali czy przez naśladownictwo innych programistów).

Plus jednostronna nauka w stylu propagandy rodem z TVP - jak coś jest uważane za dobre, to w książkach piszą o tym tylko pozytywnie (a przydałaby się jakaś galeria patologii wynikających np. z nieudolnej stosowania zasady DRY czy SOLID). Niektórzy ludzie też są nieopatrznie rozumiani. Wujek Bob też musiał prostować na blogu, o co mu chodziło z tym TDD (niczym JKM został niezrozumiany).

Możesz poczytać o hexagonal architecture czy innych rzeczach

Cargo kult? :P

To może i pewnie wystąpi. Ale tak jak napisałem Trzeba i tak jednak rozeznać, którą zasadę czy wzorzec kiedy stosować. Bo samo przeczytanie i stosowanie czegoś z książki niekoniecznie da pozytywny wynik (chociaż żeby się nauczyć, trzeba robić najpierw coś źle).