Dlaczego tak ciężko u początkujących z dbaniem o czytelność kodu?

0

Na studiach moi wykładowcy i ćwiczeniowcy zawsze szkalowali nieczytelne spagetti. Ja sam uczyłem się jak ma wyglądać czytelność na wielkich popularnych projektach typu Linux, FreeBSD, czy pomniejsze pakiety programistów skupionych wokół narzędzi Unixowych. Nawet tak szkalowane w środowisku FLOSS za stopień czytelności aplikacje GNU biją na głowę, to co tutaj ludzie wrzucają jako portfoli z githuba. Jak widzę ściany kilkunastu wywołań funkcji pod rząd to przypominają mi się czasy jak kodowałem sobie hobbistycznie gierki w TurboPascalu jako 13to latek. Nie ukrywam, że nie jestem entuzjastą programowania obiektowego, i tego typu "portfolia" tylko dają mi do ręki kolejne argumenty na temat tego jak to "Programowanie Zorientowane Obiektowo zwiększa przejrzystość kodu". O co chodzi? Gdzie tkwi problem? Przecież to na tym etapie czytelność powinna odgrywać kluczową rolę. Jak się chce budować solidny dom, to trzeba umieć łączyć odpowiednio ze sobą cegły czy inne pustaki. Wrzucanie ich do betoniarki i bezładne sklejanie ze sobą oblepionych grubą warstwą cementu pokruszonych szczątek to nie jest metoda na zbudowanie czegoś w czym będzie się dało mieszkać. Majster jak to zobaczy to popuka się w czoło, co ten szalony robol wyprawia.

0

Naczytali się na wykopach czy innych stronach dla ćwierćinteligentów z memami, że dajo 15k to chcą to jak najszybciej zdobyć i tyle. Działa? Działa. Na rynku jest sporo firm, które mają gdzieś czytelność kodu, bo liczy się tylko to co klient widzi. W dodatku jak pracują z gównokodem to potem ciężko im znaleźć lepszą pracę, więc pracodawcy to na rękę. Zresztą oni też mało nie zarabiają i koło się zamyka. Jak ktoś klepie proste apki dla klientów, o których potem zapomina to po co się ma starać z kodem i na to tracić czas? Weźmy takie systemy magazynowe. To czy ktoś wyklepie to i będzie działało (a będzie) czy też będzie pisał poprawnie to klientowi nie robi różnicy. Autor za to ma więcej czasu i może swój system sprzedać kolejnemu. Musisz się pogodzić z tym, że lepiej z kodem już nigdy nie będzie. Internet kiedyś też był spoko, byli tutaj inteligentni ludzie. A teraz? Masz jakieś nadzieje, że się to zmieni? Bez szans. I tak samo będzie z programowaniem. Ostatnio tu był temat, gdzie ktoś narzekał, że pracodawcy nie chcą juniora. Przeczytaj go sobie. Widać, że to jakiś fan memów z małpami, bo pełno odniesień do tego. Jeśli ktoś nawet po polsku nie potrafi poprawnie pisać to myślisz, że kod programistyczny będzie dobry? Nie będzie.

0

Mi się wydaje, że przesadzacie. Jeżeli pracodawcy nie przeszkadza mało czytelny kod to co? Ano nic.

0
Dzonzi napisał(a):

Mi się wydaje, że przesadzacie. Jeżeli pracodawcy nie przeszkadza mało czytelny kod to co? Ano nic.

Nie jest to mój problem (o ile nie będę zmuszony korzystać z ich produktóe, lub produktów korzystających z ich produktów - typu automaty biletowe PKP, MPK i inne). Interesuje mnie po prostu zlewanie tego jak by nie patrzeć istotnego elementu sztuki programistycznej w portfolio i dziwnie się, że maile i telefon milczą w odpowiedzi na ich CV.

0

Nie milczą.

0

Programiści mają to do siebie, że na ogół uważają się za lepszych od innych ludzi. Prawdą jest jednak, że po prostu wstrzelili się w fajne czasy dla siebie i zainteresowali się branżą, która daje dobry pieniądz. Gdyby za programowanie płacono jak na kasie w Biedrze, to bardzo często i tak by programowali. I jednocześnie zarabialiby mniej od kolegów z magazynów na strefach przemysłowych. Mnie boli brak czytelności mojego kodu, zdaję sobie sprawę ze swoich przywar, ale wiem jednocześnie, że to jest przede wszystkim skrzywienie wpojone nam przez innych nadętych idiotów. Czystość kodu to fajna rzecz, ale bulwers z powodu jego braku to jest taka sama sytuacja jak narzekanie na kierowców parkujących na chodnikach, przez co fejbukowe "madki" muszą przejechać jednym kołem wózkiem z dzieckiem po trawie zamiast środkiem chodnika. Myślicie że jesteście od nich lepsi? Nie jesteście. I wylewając swoje żale zachowujecie się tak samo jak ludzie, z których się śmiejecie ;)

4

mnie za to denerwuje przeinżynierowany kod, takjakby autor chciał pokazac, że mimo tego, że można stosować najbardziej znane instrukcje języka, to ten użyje czegoś mniej znanego wszystkim, żeby pokazać swój poziom

0

pamiętam na początku współpracując z pewną firmą popełniłem template do wordpressa, a że początkujący to zrobiłem w kodzie babola, którego z czasem dopiero zauważyłem, ale nic to poszło na produkcje, potem wszyscy bezmyślnie kopiowali templatę jako starter, pamiętam, że po 1,5 roku wszedłem na jedną z nowszych stron mojej byłej firmy i nadal był ten sam błąd w templacie :D

1

Jak widzę ściany kilkunastu wywołań funkcji pod rząd to przypominają mi się czasy jak kodowałem sobie hobbistycznie gierki w TurboPascalu jako 13to latek.

Dużo ludzi zaczyna programowanie w wieku dorosłym, więc kody dwudziestoparolatka, który zaczyna kodować można faktycznie przyrównać do kodu 13 latka, który zaczyna kodować. Każdy był kiedyś początkującym...

...chociaż zaczynanie programowania jako dzieciak ma tę zaletę, że człowiek nie myśli o hajsie. Ktoś kto zaczyna mając te naście lat może spokojnie się przyuczać do zawodu przez parę lat, zanim w ogóle pomyśli o profesjonalnym programowaniu.

Jak ktoś zaczyna programować będąc dorosłym, to myśli już zwykle o kasie, rezultatem czego jest to, że ludzie, którzy w ogóle nie powinni programować niczego komercyjnie (bo nie są na takim poziomie jeszcze) już szukają pracy za hajs.

Innymi słowy - lepiej jest zaczynać programować jak najwcześniej, w podstawówce albo gimnazjum (jeśli istnieje jeszcze takie coś), bo dzięki temu masz czas na odpowiednie przyuczenie do zawodu, bez myślenia o tym, żeby znaleźć jak najszybciej pracę, bo masz całe lata na przyuczenie się do zawodu.

1

A ja mam wrażenie, że początkujący z którymi miałem do czynienia ... uwaga .... przesadnie dbają o czytelność kodu skupiając się na tym najniższym (aczkolwiek ważnym) poziomie, za to zupełnie zaniedbując architekturę czy wzorce. Tam gdzie jest jakaś fabryka programistów i wolne tempo rzeźbienia w projekcie to pewnie i dobrze, tam gdzie od początkującego zależy tempo powstania nowej funkcjonalności, a nie jest to część krytyczna to już gorzej.

0
Smutny Kot napisał(a):

A ja mam wrażenie, że początkujący z którymi miałem do czynienia ... uwaga .... przesadnie dbają o czytelność kodu skupiając się na tym najniższym (aczkolwiek ważnym) poziomie, za to zupełnie zaniedbując architekturę czy wzorce. Tam gdzie jest jakaś fabryka programistów i wolne tempo rzeźbienia w projekcie to pewnie i dobrze, tam gdzie od początkującego zależy tempo powstania nowej funkcjonalności, a nie jest to część krytyczna to już gorzej.

Wiesz, starać się dbać o czytelność kodu, a pisać czytelny kod to dwie różne sprawy.Istnieje minimalny, przyzwoity zbiór zasad, które można zaadaptować bez medytowania całymi dniami nad zasadnością nazwania zmiennej imieniem bieżącego papieża. Ja czytając swoje kody w C z czasów studiów nie mam problemów z ogarnięciem do czego służy dana funkcja (bo ma przyzwoitą długość max 25 linii w ekstremalnych przypadkach) i co woła po samej nazwie wołanej funkcji. A nie należałem wówczas do ludzi medytujących 8h nad wzorcami, które by należało zastosować, bowiem te sam zlewałem, a i w materiale studiów, były on dopiero na późniejszych latach. Określenie problemu, podział na mniejsze części, rozrysowanie sobie sytuacji i określenie jakie moduły , algorytmy i struktury danych będą potrzebne i jazda.

Robiłem w zbliżonym czasie to co inni realizowali jako brawurowe spagetti 3-4 razy dłuższe od mojego kodu i nawet ani raz nie wyołując free() dla adresów któr wcześniej allocowali. Całe ich dbanie o czytelnosć polegało na używaniu nazw zmiennych typu ta_zmienna_przechowuje_rozmiar_tablicy i równie kwiecistych barokowych nazw funkcji. Chyba nie muszę tłumaczyć że ich późniejsze wywołania i przekazywanie do nich parametrów zajmowało jakieś 3 szerokości ekranu.

Ani ja, ani oni nie mieliśmy doświadczenia komercyjnego wtedy. Co mnie różniło? Czytałem maniacko kody innych ludzi - z repozytoriów sourceforge, kod Linuksa, czy inne jakie mi wpadły w ręce. Oni w tym czasie sączyli piwko z kumplami, zamulali w LOLa i oglądali Doctora House'a i Lost z torrentów. Mam niewielkie podstawy by podejrzewać, że ich kod uległ jakiejś znaczącej poprawie od czasów gdy dane mi było oglądać ich setki linii kodu, z których byli tak bardzo dumni, "bo wiesz, wypluwam kod jak maszyna". Do teraz wielu z nich zaliczyło już kilka czołowych w polsce korpo, prawdopodobnie będąc odpowiedzialnymi za wiele ton makaronu, z którymi zmagać się będą stażyści i praktykanci przez co najmniej kolejną dekadę. Więc fakt, można pisać makaron którego nie powstydziłby się szef włoskiej restauracji i dobrze z tego żyć. Wielkie korporacje są wystarczająco powolne i bezwładne, żeby się w nich prześlizgiwać latami z jednej do drugiej i za niezgorszą jak na Polskę kasę. Tylko pytanie, czy tego człowiek chce w życiu?

0

No, ja nie ukrywam, że wolę "sączyć piwko, zamulać w grach i oglądać seriale" niż "maniacko czytać kody innych osób z repozytoriów i kod linuksa". To drugie jednak trochę mniej brzmi jak to, czego normalny człowiek chce w życiu. - Biały Knur 3 minuty temu

Świnia woli życie świni, orzeł woli szybować w przestworzach.

2

U mnie najgorszy kod pod wzgledem czytelnosci pisza seniorzy 10+lat doswiadczenia, dostają duzo projektow z krotkimi terminami bo fakturki musza byc zaplacone jak najszybciej wiec robia po prostu szybko, a nie czytelnie. Za to junior potrafi sie spuszczać nad refaktoryzacja przez 2 dni

1

Z mojego doświadczenia wynika, że wiele osób prosto po studiach pisze duże ilości niepotrzebnych komentarzy. Zwykle dlatego, że na studiach podstarzali programiści tłumaczą, że komentarzy musi być jak najwięcej. Zdarza się, że uczelnie promują by kod zajmował, jak najmniej linii i plików. Doświadczeni programiści zwykle wiedzą, że te ekstra metody i pliki nic nie kosztują, zwiększając czytelność. Kod powinien być samo komentujący się, żadne dodatkowe komentarze nie są wtedy potrzebne (w przypadku CRUDów i typowej obiektówki).

0

Jak dla mnie masę kodu początkujących programistów (wliczając w to programistów z 10 letnim doświadczeniem, niektórzy po prostu nie wychodzą poza poziom początkujący) cierpi albo na niedoinżynierowanie albo przeinżynierowanie.

Niedoinżynierowanie - ludzie nie umieją spojrzeć na kod szerzej i stworzyć jakiejś wygodnej abstrakcji. Piszą bardzo low-levelowy kod, jakby pisali w assemblerze. Np. te wszystkie drabinki ifów.

if (user == 'Alice' && pass == 'qwerty') 
   login({user: 'Alice', timeout: 1000});
else if (user == 'Bob' && pass == 'dupa') 
   login({user: 'Bob', timeout: 1000});
else if (user == 'admin' && pass == 'admin1') 
   login({user: 'admin', timeout: 1000});

Przykład wymyślony, ale baaaardzo podobny do tego, co często widuję. Ludzie piszą na pałę z jakiejś takiej nieumiejętności myślenia abstrakcyjnego i operowania kodem w głowie, że mogliby np. wyciągnąć wywołanie login poza ify, że mogliby podawać zmienną user bezpośrednio do funkcji login, zamiast pisać na pałę, że mogliby gdzieś trzymać dane wszystkich użytkowników i ich hasła*... Tacy ludzie mają poważny problem z myśleniem, a brzydki kod jest tylko odzwierciedleniem tego, że nie umieją myśleć na wyższym poziomie.

Przeinżynierowanie z kolei bierze się z tego, że ktoś próbuje myśleć na za wysokim poziomie niż tego wymaga sytuacja. Zamiast napisać prosto, co ma na myśli (Chodzi mi o to, aby język giętki. Powiedział wszystko, co pomyśli głowa), to zaczyna odlatywać w krainie abstrakcji, bo sprawia mu to przyjemność intelektualną, bo np. przeczytał o jakimś wzorcu projektowym i chce go wszędzie stosować dla samej przyjemności stosowania. Trochę to wygląda jakby ktoś szedł ulicą i patrzył się cały czas na gwiazdy, i się jarał np. mgławicą w Orionie, i nie patrzyłby zupełnie gdzie idzie. A potem np. wpadłby pod samochód, tak samo przerost abstrakcji w kodzie też może się źle odbić, np. poprzez gigantyczne koszty utrzymania takiego przeinżynierowanego projektu.

* pomijam już potrzebę haszowania, bo nie chodzi mi o trzymanie haseł, tylko o przykład na drabinkę ifów.

2

Dlaczego ludzie nie piszą czystego kodu? To tak jakby zapytać dlaczego ludzie jedzą fastfood.

  • bo nie mają czasu
  • bo nie muszą wracać do tego kodu
  • bo nie mają emocjonalnej więzi z kodem (co w firmach zwykle się tępi)
  • bo nie rozumieją co robią
  • bo uważają refaktoring za fanaberię
  • bo nie mają testów, czyli nie robią refaktoringu
  • bo poziom programistów w zespole jest tak różny że nie warto, bo i tak przyjdzie ktoś o dużo niższych kompetencjach albo starszy stażem i to zepsuje
  • bo jest piątek
  • bo są na kacu
  • bo ich wk.. team lead
    ...
0

Może dlatego, że intuicyjnie uczymy się przez powielanie schematów? Tak więc skoro każdy kurs czy lekcja zaczyna się od rzeczy elementarnych jak ify i pętle i na tym opiera się nauka. Natomiast dobry kod polega w dużej mierze na mądrym używaniu bardziej zaawansowanych mechanizmów, którym nikt praktycznie nie poświęca wiele czasu. Nie pamiętam, żebym na studiach czy w książce kiedykolwiek zobaczył dobry kawałek kodu, może częściowo dlatego, że ciężko się popisać dobrym kodem przy rozwiązywaniu trywialnych problemów. Dopiero z czasem i potrzebą doszedlem, że można inaczej. Generalnie uważam, że powinno się odejść od trywialnych i nudnych problemów, a zacząć rozwiązywać realne (nie koniecznie trudne) w prosty sposób (1-2 linijki kodu).
Dla przykładu moja dziewczyna (artystka) uczy się rosyjskiego to pokazałem jej jak napisać konwerter z cyrylicy na nasze i na odwrót – rzecz użyteczna na początku. Podstawianie za pomocą seda to banał, tylko pisać linię poleceń z 60 parametrami niezręcznie, więc pokazałem jak przy pomocy awk wygenerować taką linię poleceń na podstawie listy odpowiedników.

awk 'BEGIN { ORS = " "; print "sed" } { print "-e s/" $1 "/" $2 "/g -e s/" toupper( $1 ) "/" toupper( $2 ) "/g" }' alfabet > pl-ru.sh

tyle na ten temat. Szybko, prosto i użytecznie. Niech żyje *nix :)

1

Typowe 4programmers, wątek główny jak zwykle poszedł się chędorzyć i z tematu początkujących chwalących się spaghetti na githubie zaczeliście biadolić, jak to regualrzy i seniorzy nie mają czasu pisać czytelnie, bo ich terminy gonią. To nieomal Freudowskie.

0

Moim zdaniem fakt pisania nieczytelnego kodu wynika z tego, że mało osób pisze testy. Gdyby był wymóg pisania testów jednostkowych, to od razu programiści mieszający 10 różnych operacji (odpowiedzialności) w jednej metodzie/klasie, wprowadzając do tego jej zależność od 20 innych rzeczy zadaliby sobie pytanie - a może zorganizować to wszystko inaczej ? W trakcie kilku najpoważniejszych projektów, w jakich miałem przyjemność brać udział, najczystszy kod był pisany w kontekście pokrycia warunkowego 81% kodu. Nie wspomnę ilości razy, kiedy musieliśmy dodać nową funkcjonalność, a przy okazji zabieraliśmy się za refaktoryzację w celu polepszenia ogólnej czytelności. A ekipa nie była bardzo seniorska: architekt (19 lat doświadczenia i to nie 1 roku powtórzonego 19 razy), senior (7 lat doświadczenia przez pierwsze 4 miesiące projektu) i 2 juniorów+ (3-4 lata). Sam wymóg pisania testów jednostkowych wymusił na wszystkich refleksję nad organizacją kodu przed jego napisaniem. Niestety, ilu programistów, tyle różnych doświadczeń i często trudno przekonać innych do konieczności i zalet testowania, szczególnie jak się wspomni fakt, że zadanie z JIRY będzie ocenione na 1 punkt więcej.

0

Wymóg pisania testów niczego nie da jeśli nie nauczy się ludzi ich pisać.

0
bartosz25 napisał(a):

Moim zdaniem fakt pisania nieczytelnego kodu wynika z tego, że mało osób pisze testy. Gdyby był wymóg pisania testów jednostkowych, to od razu programiści mieszający 10 różnych operacji (odpowiedzialności) w jednej metodzie/klasie, wprowadzając do tego jej zależność od 20 innych rzeczy zadaliby sobie pytanie - a może zorganizować to wszystko inaczej ? W trakcie kilku najpoważniejszych projektów, w jakich miałem przyjemność brać udział, najczystszy kod był pisany w kontekście pokrycia warunkowego 81% kodu. Nie wspomnę ilości razy, kiedy musieliśmy dodać nową funkcjonalność, a przy okazji zabieraliśmy się za refaktoryzację w celu polepszenia ogólnej czytelności. A ekipa nie była bardzo seniorska: architekt (19 lat doświadczenia i to nie 1 roku powtórzonego 19 razy), senior (7 lat doświadczenia przez pierwsze 4 miesiące projektu) i 2 juniorów+ (3-4 lata). Sam wymóg pisania testów jednostkowych wymusił na wszystkich refleksję nad organizacją kodu przed jego napisaniem. Niestety, ilu programistów, tyle różnych doświadczeń i często trudno przekonać innych do konieczności i zalet testowania, szczególnie jak się wspomni fakt, że zadanie z JIRY będzie ocenione na 1 punkt więcej.

Testować tym łatwiej, im sposób budowy kodu ma więcej ładu i składu i jest podzielony w jakiś spójny sposób, za którym stoi pewien sens (i nie mówię tu o piętrach klas, czy w ogóle o klasach - bo dla wielu fetyszystów OOP to jedyny "czytelny" sposób podziału). Często rozrysowanie sobie schematu tego, co się ma zaimplementować wystarczy, żeby nadać strukturze jakiś sensowny kształt. By potem nie zginąć w gąszczu duplikatów, które trzeba nagle poprawiać. Rypnąłeś się przy sprawdzaniu jakiegoś warunku brzegowego i nie bardzo pamiętasz, czy weryfikowany jest w trzech miejscach czy w trzydziestu? O właśnie przypomniałeś sobie, że w jednej z funkcji zaimplementowałeś ją jeszcze inaczej. A powinna to załatwiać jedna krótka funkcja. A może nagle się okazało, że jednak biblioteka widgetów musi zostać zmieniona, a twój kod wyołuje "na żywca" od zarypania funkcji w stu tryliardach miejsc za każdym razem inicjalizujesz je tymi samymi wartościami i strukturami, poprzeplatanymi właściwymi dla głównej logiki aplikacji operacjami i funkcjami. Wspaniale, teraz czeka cię ręczne wydłubywanie ich z istniejącego kodu, bo napisanie regexpu do czegoś takiego jest prawie niewykonalne. Biorąc pod uwagę, że raz były inicjowane stałymi, raz zmiennymi (o matko, po drodze jeszce są one modyfikowane przez coś!), a raz jakimiś magicznymi liczbami. Zanim w ogóle zastąpisz daną linię, będziesz szanowny programisto zmuszony przebadać "co miałeś na myśli". A można było po prostu zebrać to wszystko do kupy w jednej funkcji z odpowiednim zestawem parametrów. Nawet jakby po zmianie biblioteki, trzebabyło zmienić jej listę parametrów, to nie będzie to już jak wydłubywanie tony rodzynek z bagna.

1 użytkowników online, w tym zalogowanych: 0, gości: 1