Po co są zasady clean code'u, skoro nikt się ich nie trzyma?

No cześć,
Ostatnio coraz więcej ludzi pisze o tym, że zasady clean code'u są do d**y. Dlaczego? Bo w żadnej firmie/januszsofcie/korpo nikt się ich nie trzyma. Zastanawiam się cały czas dlaczego, skoro to poprawia czytelność kodu i ogólnie łatwiej się przy nim pracuje, szczególnie gdy mamy za zadanie utrzymanie starego kolosa. Powody są na pewno różne - czy to z lenistwa, braku umiejętności (chociaż w to bardzo wątpię), a nawet obiło mi się o uszy, że czasami za mało płacą na takie udogodnienia xD Czy Wy w swojej całej karierze pracowaliście w projekcie, w którym były/są zachowane owe zasady? Ile przykładacie uwagi do tworzonego kodu? Czy dbacie o jego "wygląd"? Pozdro :P

To chyba u Ciebie nikt się tego nie trzyma. Pracowałem w firmach gdzie nie było standardów, wiec wdrazalem swoje pomysły, w innych były gotowe standardy code style'u, wiec trzymalem się wg reguł.

Odnośnie czystości kodu to wystarczy mieć zautomatyzowane sprawdzanie code style'u i dorzucić do tego code review. Jak ktoś Ci nazwie zmienna np abc i do tego zrobi 5 zagniezdzonych pętli pomieszanych z ifami to albo automat od razu wykryje zbyt duża złożoność lub któryś z reviewerow.

Osobiście dbam zarówno o pisany kod, jak i moje normalne teksty (np tutaj, wiec jak ktoś ma uwagi stylistyczne, ortograficzne, gramatyczne to piszcie śmiało). Dlaczego? Po pierwsze czysty i ładny kod czyta się przyjemnie, czasami dobrze napisanego kodu nie trzeba nawet za bardzo czytać bo od razu wiemy co dany kod robi (np metody givemesth i getCurrentStatus - jest różnica co?)

Czym ładniejszy kod, to i mniejsze ryzyko popełnienia błędu (wciecia, klamerki, zagniezdzenia, nazewnictwo, konstrukcje lub lukier skladniowy, Yoda-style)

Z czasem zauważyłem zależność, że im dłużej się programuje, to więcej kodu się czyta niż pisze. Myślę że i dlatego istnieje takie pojęcie jak "klepacze kodu"

To gdzie ty pracujesz, że nikt się nie trzyma tych zasad?????

Zasady są po to żeby je łamać tak jak drzewa i kończyny.

Podobno były skrajne przypadki, że firmy plajtowały bo po jakimś nie były w stanie zmieniać funkcjonalności (kodu) swoich produktów bezpiecznie i w sensownym czasie. Stąd powstała idea, że kod, jego postać ma znaczenie. Zasady clean code są pewnym przemyśleniem tematu i opisem jakie właściwości ma kod, żeby aplikacje można było rozwijać i dostosowywać do przyszłych potrzeb.

Spotkałem się z plotką, że niektórzy nie stosują praktyk clean code bo ich nie dotyczą, bo nie programują w Javie (że w ich językach nie ma czegoś takiego).

Zastanawiam się cały czas dlaczego, skoro to poprawia czytelność kodu i ogólnie łatwiej się przy nim pracuje, szczególnie gdy mamy za zadanie utrzymanie starego kolosa.

Zazwyczaj to ktoś inny tworzy kolosa i inny utrzymuje starego kolosa. Utrzymanie kolosa to nie jest czas w cyklu życia produktu wydzielony na testowanie i refaktoryzacje (... by żyło się lepiej).

Clean code to tylko jeden z elementów rozwoju oprogramowania i akurat nawet w zaniedbanym projekcie mogą nie być aż tak ważne (nie to może boleć najbardziej ;p - może to być jedna z przyczyn dlaczego ludzie się dystansują od praktyk clean code). Praktyki clean code mają konkretny cel związany z długoterminowym rozwojem i utrzymaniem kodu/produktu. Może się okazuje, że te praktyki nie za bardzo pomagają w utrzymywaniu kodu. Jak ktoś twierdzi, że są do d**y to raczej przejaw ignorancji, ale część programistów nie stosuje praktyk, bo nie chcą ich stosować tylko dlatego że dobre praktyki należy stosować a ktoś powiedział, że to czy tamto jest wspaniałe. Nie wszyscy się jarają chociażby TDD jak Wujek Bob.

@krsp: a co ma java do clean code? Przecież to się tyczy każdego języka. W js jest eslint, w php jest cs-fixer itp itd. Trzeba się trzymać odpowiedniego chociażby psr i nie będzie problemu.

@mr_jaro: Ja nie twierdzę, że zasady nie dotyczą innych języków. Z Javą ma tyle wspólnego, że znanym propagatorem jest Wujek Bob i w dużym stopniu propaguje Clean Code na przykładzie Javy. Plotka, bo znam ją z drugiej ręki, dotyczyła jakichś tam ludzi związanych z C/C++ - że oni nie mają tam czegoś takiego jak clean code. Nie, nie musisz wyszukiwać przykładów, że jakieś wsparcie jednak tam jest (i szczerze wieże że jednak temat czystości, jakości kodu jest C/C++ poruszany). Temat wspomina o ludziach co uważają, że clean code jest do d**y; rozszerzyłem temat bo słyszałem o programistach, których temat, nie wiem jak to określić, nie interesuje.

.edit
@mr_jaro jeżeli clean code dla ciebie stosowanie narzędzi, to się zgadzam, że taki clean code jest do d__y. To że masz metryczkę na kodzie to problemem jakiego nie ma to chyba jedynie, że nikt się nie będzie prz****pszał.

Bo czysty kod trudno napisać i mało kto umie robić to dobrze. Prawdziwy czysty kod to nie tylko formatowanie i nazewnictwo. Ciężko jest to zamknąć w zbiorze prostych zasad.

Oczywiście, że nie tylko ale narzędzia już sporo pomagają na poziomie własnie nazewnictwa i formatowania, czesto automatycznie naprawiają jak ktoś zamiast spacji da taba itp, od czegoś trzeba zacząć, a co do reszty jak architektura, podział itp to już inna brożka i wszystko zależy od języka, frameworka, systemu, zasad przyjętych w firmie.

Kod jest kosztem dla klienta, liczy się działający produkt, a nie jaranie się TDD, metrykami kodu, złożonością czy estetyką, ważne jest, aby produkt dało się rozwijać przez czas jego życia, a nie przepisywać w kółko. Stąd biorą się krótkie terminy i klepanie na szybko z nadzieją, że „kiedyś się wysprząta”, ale potem zmieniają się wymagania i pojawiają się nowe, więc nie ma czasu na sprzątanie, tylko trzeba kodzić dalej. Do tego dochodzą realia rynku, można polerować kod wprowadzając wszędzie monady, kategorie i matematyczne abstrakcje, ale jak potem autor odejdzie z pracy, to trudno będzie znaleźć kogoś ogarniającego na jego miejsce.

Czyli clean code jest albo w wielu przypadkach bez sensu, albo jest po prostu ciekawostką. Z resztą nie opłaca się takowego produkować, jeśli zasada jest nieobowiązkowa, bo mało kto będzie się do niej dostosowywał.

Sunnydev napisał(a):

Czyli clean code jest albo w wielu przypadkach bez sensu, albo jest po prostu ciekawostką. Z resztą nie opłaca się takowego produkować, jeśli zasada jest nieobowiązkowa, bo mało kto będzie się do niej dostosowywał.

No widzę, że kolega wyczerpał temat. Nawet nie chce mi się dyskutować. Pozostaje mi jedynie mieć nadzieję, że nie będę miał nigdy "przyjemności" pracować z @Sunnydev. ;-)

Z clean code jest jak z wzorcami i nowymi pomysłami na architektury, wszystko z odpowiednim wyważeniem, tak by:

• klient nie jęczał
• szef nie jęczał
• programista wchodzący do projektu za 2 lata nie jęczał

Czy w mniejszych projektach jako programiści stosujecie/trzymacie się wzorców projektowych lub clean code'u? Są jakieś odstępstwa albo z braku czasu piszecie kod na szybko i potem ew. poprawiacie?

Ja jutro mam rozmowę w firmie w której ponoć bardzo dbają o jakośc kodu. Miałem wczesniej zadanie do wykonania i zwracali uwagę na jakość, akurat ja dobrze o nią zadbałem więc poszło OK :D

Sunnydev napisał(a):

Po co są zasady clean code'u, skoro nikt się ich nie trzyma?

Zacznijmy od tego, że nie ma póki co jakiegoś Głównego Urzędu Kodowania który by mógł narzucić programistom takie czy inne zasady.
Pytanie „po co są zasady” jest dziwne – komuś po prostu wydawało się że jest mądry i swoje mądrości wydrukował w książce, a innym się one spodobały i zaczęli je wprowadzać w życie.
Nie są to też zasady niewzruszone – masz prawo mieć inny pogląd i inne pomysły na dobry kod.

Kod jest kosztem dla klienta, liczy się działający produkt, a nie jaranie się TDD, metrykami kodu, złożonością czy estetyką,
ważne jest, aby produkt dało się rozwijać przez czas jego życia, a nie przepisywać w kółko. Stąd biorą się krótkie terminy i
klepanie na szybko z nadzieją, że „kiedyś się wysprząta”, ale potem zmieniają się wymagania i pojawiają się nowe, więc
nie ma czasu na sprzątanie, tylko trzeba kodzić dalej.

Zdarzyło mi się pracować nad projektem który zmieniał się bardzo dynamicznie: dobrze napisany kod jest dużym ułatwieniem ze względu na częstą konieczność jego modyfikacji, ale z drugiej strony nie ma czasu (ani nie warto) pisać tego zbyt czysto, bo za tydzień trzeba było wywalać pięknie napisany kod z poprzedniego tygodnia…

Może powinniście wreszcie zadać pytanie po co są wzorce projektowe skoro wszędzie pytają, a nikt ich nie używa? :D

Wszystko z logiką i umiarem. Jeśli jest czas, to się trzeba starać z prostego powodu: za miesiąc nie będziesz wiedział o co chodzi ani nie będziesz potrafił się odnaleźć nawet przez głupie błędy w formatowaniu.

Ale jeśli od tego czy oddasz projekt jutro zależy czy dostaniesz przelew, czy nie, to polecę klasykiem:

Ale mądry programista jeśli tylko ma możliwość, to trzyma się przynajmniej jakiegoś minimalnego podzbioru czystego kodu. Nie raz głupie wcięcia uratowały mi zadek przed życiowymi błędami z serii: ta linijka jest tu niepotrzebna.

Zwykle jest tak, że trafia się do starego projektu, w którym wszystko było dokładane "jak najszybciej", więc o zasadach clean code czy testach nie było w ogóle mowy. Potem większość przychodzących do takiego projektu trzyma się zasad tylko przy tworzeniu nowego kodu, a starego nie tyka ("dotkniesz i wybuchnie, nie ruszaj!") albo nawet nowy jest brzydki ("skoro można pisać tak, to po co się męczyć?").

Bo w żadnej firmie/januszsofcie/korpo nikt się ich nie trzyma.

Może czas na zmianę pracy? Ale tym razem na taką, którą trudno dostać :) Zaręczam ci ze są miejsca gdzie słaby kod zwyczajnie nie przejdzie review.

Z 'czystym kodem' jest jak ze 'zdrowym jedzeniem'. Niby nikt nie stosuje, ale jak się chwilę zastanowić...
jeżeli się by zrezygnowało z hasła 'zdrowe jedzenie', to znaczy że należy jeść wszystko co niezdrowe?
W jednym jak i w drugim potrzebne jest doświadczenie i umiar...

Po to są żebyś kupił czyjąś książkę i przeczytał. Jest o tyle lepszy model biznesowy że zasady w przeciwieństwie do frameworków/narzędzi/języków są zawsze takie same więc jak ktoś napisał tą książkę to może odcinać kupony do końca życia :]

"Po co prawo, skoro nikt się go nie trzyma?"
To zdanie ma tyle samo sensu co krzykliwy tytuł tego wątku.

loza_szydercow napisał(a):

... zasady w przeciwieństwie do frameworków/narzędzi/języków są zawsze takie same więc jak ktoś napisał tą książkę to może odcinać kupony do końca życia :]

Nieprawda. Zasady ewoluuja i czasami stają się totalną bzdurą, czasem stają się nieistotne.

Przed clean code:
JavaBeany (o ja prdle, że naprawdę tyle lat się w to bawilismy)
Komentarze (kolejna z rzeczy, którą wyleczył( jeszcze nie do końca) właśnie clean code),

Po clean code:
Całe zasady dotyczące Exceptions handling - obecnie praktycznie nie używam żadnych checked exceptions w kodzie.

Czekam np. aż testowanie jednostkowe ostanie uznane za smell, spokojnie... troche to potrwa.
Tu wchodzi tzw. odwrócona piramida testów, która nic nie ma wspólnego ze zwykła piramidą testów.

Ze wzorcami kod pisze sie wolniej(male i srednie projekty), zdecydowanie wolniej. W technikum szlo napisac forum w PHP w kilkanascie lekcji a dzis zajelo by mi to kilkadziesiat dni z ta sama funkcjonaloscia ale ze wzorcami.

syryls napisał(a):

Ze wzorcami kod pisze sie wolniej(male i srednie projekty), zdecydowanie wolniej. W technikum szlo napisac forum w PHP w kilkanascie lekcji a dzis zajelo by mi to kilkadziesiat dni z ta sama funkcjonaloscia ale ze wzorcami.

Tak, ale potem przy rozwoju zamiast korzystać ze wzorców dodać coś w 8h to grzebiesz się 40h bo się wszystko sypie, bo masę miejsc do zmiany itp :d wzorzec zwalnia cię na początku ale gdy projekt jest rozwijany długo to wzorce ratują du#e.

A co z YAGNI?

@jarekr000000: a ja myślę że to zależy co się testuje. Na przykład masz kalkulator który liczy opłatę na podstawie ilości godzin korzystania z czegoś przy czym to nie jest jakiś prosty wzór liczba_godzin * czas tylko coś bardziej złożonego. Co złego że w tym przypadku zrobi się test? Oczywiście czasami ciężki coś przetestować w ten sposób i zamiast tego testujesz Mockito (hehe) no to rzeczywiście lepiej walnąć inny typ testu. Dobieramy narzędzie do celu

Jak zwykle trzeba uważać co się tu pisze, bo akurat nie miałem na myśli po prostu olania weryfikacji.

Unit testy są po prostu jedną z metod weryfikacji programów:
Ale

1. coraz lepsze są tzw. property based testy (to rodzaj unit testów, ale patrzę na to jak na nowy poziom).
2. w lepszych językach część trywialnych właściwości można wyrazić typami (nawet w javie trochę to idzie).

@jarekr000000: poruszyłeś tutaj temat wyjątków i mówisz, że nie korzystasz z checked exceptions. Podejrzewam więc, że używasz jakieś Try, Either, itp. W związku z tym mam pytanie: w jaki sposób obsłużyłbyś wyjątki w scenariuszu typu rest api do składania zamówień, gdzie potencjalne problemy to np. niedziałający serwis z którymi komunikujemy się przez sieć, błędne dane wejściowe, błąd biznesowy (np. użytkownik jest niepełnoletni więc nie może zamówić alkoholu). Zazwyczaj spotykałem się z podejściem, że wszystkie te problemy rozwiązywało się z wykorzystaniem wyjątków unchecked, ale w zasadzie jest to dość uciążliwy sposób obsługi błędów. Błędy biznesowe to raczej typowa sytuacja i fajnie byłoby w kontrakcie metody explicitly pokazać, że taki błąd jest możliwy. Takie coś można uzyskać korzystając z checked exceptions, ale z drugiej strony to wcale nie jest wyjątkowa sytuacja, tylko typowa. Wyjątkową sytuacją może być niedziałająca usługa i w tej sytuacji znów checked exception wydaje się być najbardziej odpowiedni, chociaż pewnie i tak wszyscy użyją unchecked. Z unchecked jest jednak taki problem, że łatwo możemy przeoczyć możliwość wystąpienia takiego błędu i go po prostu nie obsłużyć.