Clean code - codzienność czy utopia?

Chciałbym zapytać programistów z doświadczeniem komercyjnym z jakim kodem mają do czynienia na codzień i jak ma się sprawa w odniesieniu do założeń SOLID lub clean code oraz jakości kodu w szerszym sensie. Koncepcje Agile powstały dobre pare lat temu, "Clean Code" ma juz 10 lat na karku. Przesłuchałem ostatnio pare wystąpień Uncle Bob'a i zastanawiam się, na ile zasady o których mówi, stanowią codzienność w pracy zawodowej programisty. Skoro założenia nie są nowe, czy trzeba o nich przypominać? Nie powinny być standardem?

Sam jestem rzemieślnikiem i w mojej działce ogólny trend idzie w stronę jak najniższej ceny i jak największej "wydajności" , co można osiągnąć jedynie zaniżając jakość. Nie spotkałem się z tym, by znane nazwisko z branży kładło tak duży nacisk na propagowanie dobrego stylu.

Jak to wygląda u Was? Jaki kod tworzycie i z jakim musicie pracować na codzień? A dokładniej, czy rynek wymaga od Was "wydajności" , czy jakości? Czy jest jakaś tendencja zależna od wielkości firmy, typu branży, typu technologii?

Ogólnie, to tak to wygląda z reguły:

Apptekarz napisał(a):

Chciałbym zapytać programistów z doświadczeniem komercyjnym z jakim kodem mają do czynienia na codzień i jak ma się sprawa w odniesieniu do założeń SOLID lub clean code oraz jakości kodu w szerszym sensie. Koncepcje Agile powstały dobre pare lat temu, "Clean Code" ma juz 10 lat na karku. Przesłuchałem ostatnio pare wystąpień Uncle Bob'a i zastanawiam się, na ile zasady o których mówi, stanowią codzienność w pracy zawodowej programisty.

Ja tam nie widzę jakiegoś wielkiego wpływu Martina na SOLID w moim życiu. Agile też z SOLID nie ma nic wspólnego, no chyba, że na zasadzie kontrastu (SOLID - dobre, przemyślane praktyki, Agile - bezmyślna dezorganizacja utrudniająca pracę)

Skoro założenia nie są nowe, czy trzeba o nich przypominać? Nie powinny być standardem?

O tworzeniu czystego kodu nie ma sensu przypominać, bo większość programistów nigdy SOLID nie stosowała, więc zwyczajnie nie ma im czego przypominać.

Jak to wygląda u Was? Jaki kod tworzycie i z jakim musicie pracować na codzień? A dokładniej, czy rynek wymaga od Was "wydajności" , czy jakości? Czy jest jakaś tendencja zależna od wielkości firmy, typu branży, typu technologii?

Pracuję w firmie, w której oprogramowanie jest produktem. Niska jakość kodu jest zagrożeniem, bo może ona spowodować utratę klientów.
"Wydajność" przez obniżenie jakości to raczej model działania agencji interaktywnych i outsourcingu projektów.

I wtedy przychodzi termin projektu i wszystkie piękne założenia typu jakość, testy idą w pizdu...
I w praktyce wygląda to tak że napisałeś coś w miarę dobrze, ale wiele można poprawić.. tylko kto za to zapłaci :D

A tak naprawdę to najwięcej zależy od projektu i budżetu na niego. Im większy projekt i budżet, tym dużo większe prawdopodobieństwo na lepszy jakościowo kod.

@Mjuzik: dlatego lepiej nie pracować u pośrednika robiącego projekty tylko bezpośrednio w produkcie. Jeśli coś i tak jest ciągle rozwijane, to czas dostarczenia jakiegoś ficzera nie jest tak istotny, a jeśli nad głowa nie wisi kontrakt z karami, to deadliny nie są potrzebne w ogóle.

O ile kod spaghetti łatwo rozpoznać i jasno można stwierdzić że nie tak to powinno wyglądać, o tyle samo SOLID i Clean Code to już bardzo grząski grunt- tam gdzie jeden programista będzie widział dobrze napisany kod/architekturę, drugi będzie widział coś do poprawy. I ten pierwszy niekoniecznie musi się z tym zgadzać.

Ot weźmy chociażby S z SOLID- Single Responsibility Principle. To czy klasa ma jedną czy już więcej odpowiedzialności to bardzo subiektywna kwestia, i sami ludzie promujący te idee mówią wprost że to nie jest proste i po dziś dzień bywa że nie są pewni lub zwyczajnie te zasady łamią (i tu znów kwestia sporna czy do złamania zasad faktycznie dochodzi).

@Aventus dokładnie, często widać takie rzeczy np. podczas kłótni seniorów nt które podejście jest lepsze, jak sie powinno robić itp. I teraz pytanie, czy my nie chcemy stworzyć programistycznego świata zbyt idealnego? Oba rozwiązania są dobre i oba będą dobrze działać, więc po co poświęcać czas na kłótnie "czy to na pewno jest SOLID i clean code?."

jest coś takiego jak trójkąt projektu, czyli zakres-czas-koszt, tutaj dostosowuje wartości do siebie szukając najlepszych proporcji zarówno dla klienta jak i firmy

Apptekarz napisał(a):

Sam jestem rzemieślnikiem i w mojej działce ogólny trend idzie w stronę jak najniższej ceny i jak największej "wydajności" , co można osiągnąć jedynie zaniżając jakość. Nie spotkałem się z tym, by znane nazwisko z branży kładło tak duży nacisk na propagowanie dobrego stylu.

Można napisać kod wydajny i czytelny. Jest chyba bardzo niewiele przypadków, gdzie mamy naprawdę duży skok wydajności kosztem czytelności i dotyczy to chyba jakiegoś low-levelowego kodu w branży embedded, gier komputerowych lub ewentualnie HFT. W aplikacjach użytkowych (czyli większość rynku) dodanie narzutu rzędu paru nanosekund to nie jest zwolnienie, które zauważyłby człowiek i warto się skupić na czystym kodzie.

Jak to wygląda u Was? Jaki kod tworzycie i z jakim musicie pracować na codzień? A dokładniej, czy rynek wymaga od Was "wydajności" , czy jakości?

Na co dzień staram się trzymać reguł "Clean Code" przy tworzeniu nowego kodu. Jeżeli kod w review nie spełnia wg mnie reguł "Clean Code" to odrzucam review. W obecnym projekcie mam trochę starego kodu sprzed kilku lat i tam czasem te reguły są niestety łamane. Podczas utrzymywania tego kodu, większość wprowadzanych zmian spełnia już te reguły, a jeśli jest czas na refaktoring i dana klasa ma odpowiednie pokrycie testami, to robimy refaktoring. Jeżeli nie ma pokrycia, to istnieje spore ryzyko, że po zmianach coś się zepsuje i będzie to stanowić problem.

Parę lat temu na jakiejśtam ewaluacji/ocenie w firmie zarzucono mi pisanie kodu niskiej jakości i tak mi to siadło na ambicję, że przeczytałem książki na ten temat i teraz mam tak zrytą banię, że nawet głupie skrypty w bashu dla własnego użytku piszę zgodnie z regułami "Clean Code" i dodaję do nich testy jednostkowe ;-).

Czy jest jakaś tendencja zależna od wielkości firmy, typu branży, typu technologii?

Wg mnie, jeśli zespół programistów jest dobry, to tacy ludzie będą tworzyć dobry i czysty kod niezależnie od wielkości firmy, branży i technologii.

Clean code nie jest utopią. Ludzie, którzy nie trzymają się tych reguł albo ich nie znają, albo ich nie rozumieją albo są nieprofesjonalni. Wystarczy spojrzeć sobie na rozmaite popularne projekty open-source i zobaczyć jak tam wygląda kod, pokrycie testami i jak ludzie nad tym pracują. Da się, tylko trzeba mieć doświadczenie, wiedzę i być ogarniętym.

Niby nie; ostatnio mam do czynienia z kodem któremu brakuje S i praca z nim bywa karkołomna. Także jestem skłonny stwierdzić, że clean code to codzienność, ale bywa, że wpadnie kawałek kodu słabo zorganizowany, który przypomni, że na co dzień ma się do czynienia z przyjaźniejszym kodem.

Wydaje mi się, że w mniejszym lub większym stopniu o kod się dba (prawie) wszędzie. Wyjątkami są janusz-softy, totalnie chore terminy (czyli pewnie janusz-softy), no i drużyny scrumowe złożone w całości z juniorów lub studentów (tutaj dopiero jest zabawa - przeżyłem na własnej skórze. i tak - janusz-soft :D).
W normalnej stytuacji kod przed staniem się taką "oficjalną ostatenczą wersją" jest sprawdzany przynajmniej przez jedną osobę, musi przejść testy automatyczne, przejść testy statyczne na czystość kodu i dopiero wtedy zostaje dołączony do istniejącej całości.
Raczej nie zdarzają się straszne buble, często dyskutuje się nad kontrowersyjnymi rozwiązaniami.
Jak ktoś ma inaczej, to polecam uciekać stamtąd.

Dzięki wszystkim za odpowiedzi. Naszkicowaliście tutaj całkiem optymistyczny obraz, co nie ukrywam, że mnie cieszy.

@Aventus Uch, pierwsza praca: janusz-soft. Obiecywano wiele, co miesiąc. 90% projektów unijnych. Z początku było nawet dobrze, właściwie byłem zachwycony. Ale trafiłem na falę odejść seniorów i nie było się od kogo uczyć po miesiącu. Zaczęło się robić niemiło. Seniora zatrudnić trudno, a hajs się musi zgadzać. Małe projekty były dosłownie ciągnięte przez juniorów.
W ciągu 2-3 miesięcy z ~7 programistów zrobiło się ze 20 - oczywiście studenci i ludzie w pierwszej pracy.
Kiedy tylko Janusz zauważył, że jako-tako daję radę od razu mianował mnie turbo seniorem wszystkiego i przydzielił same ważne zadania w dziwnych projektach.
Czasami kodziłem sobie sam z miesiąc, nikomu nie przeszkadzając.
O CI czy CD nikt nie słyszał. Czasami, jeśli w projekcie był prawdziwy senior, to się takie rzeczy działy, ale nikt nikomu nie wyjaśniał po co, jak i dlaczego.
W sumie po co komu Continuous Delivery kiedy nie ma się zamiaru niczego Deliverować :-D
Code review sam sobie robiłem - przecież nie będzie ktoś z innego projektu w mój kod wchodzić...
Miałem zaszczyt nawet od a do z "robić" dużą platformę związaną z kopaniem kryptowalut - łącznie z giełdą i innymi cudami.
Termin: 2 miesiące. Ustalony przed wyestymowaniem projektu. Właściwie nawet nie znałem potrzebnych technologii kiedy zaczynałem.
Załoga: Ja (Senior Wizard Madafaka Developer + Project Owner + nie znam nawet nazw), 2 juniorów mojego pokroju, no i bat szefa na plecach.
Planujemy. Ale nikt nie zna technologii. W sumie nawet nie mamy dokładnych założeń projektowych.
Jest termin, kilka nie technicznych haseł i ja - cały na biało.
Pot, krew, łzy.
Więcej łez.
Robiliśmy chociaż code review. Ale co to za cr, kiedy ocieniający wie często mniej niż ty sam :-D
Z jakiegoś powodu czułem się jako ten odpowiedzialny za całość - chyba dałem się wrobić. No i to ja dostawałem opieprz za terminy, bugi, cholera wie co jeszcze. Planowaliśmy w GODZINACH, nie w STORY POINTACH. W końcu wiadome musi być na kiedy się wyrobimy, co to za durna miara story pointy. Każde niedoszacowanie - opieprz.
Testów brak - szkoda czasu (no czasami udało mi się oszukać i coś dopisać, ale na prawde różnicy to nie robiło praktycznie kiedy się bug trafiał).
Na koniec zostałem sam, bo w innych projektach był potrzebny ktoś ogarnięty do pomocy (czytaj moich dwóch wiernych braci juniorów).
Sam planowałem, sam groomowałem, sam implementowałem i sam dziwiłem się dlaczego to jeszcze działa.
Projekt upadł, czego na pewno nikt się nie spodziewał. Tzn. tak myślę - zrobiłem (prawdopodobnie najgorsze w życiu) mvp i odszedłem. Wątpię żeby ktoś w to dalej brnął.
To był mój ostatni projekt - uciekłem.
I oczy mi się otworzyły szerzej niż kiedykolwiek już pierwszego dnia nowej pracy.
I to zdziwienie ludzi kiedy się tłumaczę jak potłuczony po pierwszym sprincie, że nie wiem dlaczego to zadanie spadło, robiłem co mogłem, walczyłem jak lew.
A Ci, że "spoko, to normalne, zadania spadają". "Przecież nikt Ci głowy nie urwie".
Jak to? :O
Firma istnieje. "Programują" dalej.

@TakiTamPiekarz: Wielkie dzieki za odpowiedz. Jedno tylko sie nasuwa na mysl czytajac to- "O kutwa, niezly hardcore". Az mnie naszlo na zalozenie tematu aby ludzie dzielili sie doswiadczeniami z janusz-softow :)

Jedyne do czego tak naprawde moge dodac komentarz to kwestia code review- oczywiscie w Twoim przypadku wszyscy byliscie swierzakami wiec ciezko mowic o dzieleniu sie doswiadczeniem, ale code review przez mniej doswiadczona osobe samo w sobie nie jest zle. Wiecej o tym napisalem tutaj: Brak code-review dla Juniora - odchodzić? (ostatni post w watku).

Apptekarz napisał(a):

Skoro założenia nie są nowe, czy trzeba o nich przypominać? Nie powinny być standardem?

Z tego że jakieś założenia nie są nowe nie wynika że powinny być standardem, bo gdyby tak było, standardem byłby COBOL.

Z tego że jakieś założenia nie są nowe nie wynika że powinny być standardem, bo gdyby tak było, standardem byłby COBOL.

COBOL to język programowania, SOLID, clean code itp. to pewne reguły używania języka programowania. Dosyć uniwersalne jak myślę.

Moim zdaniem jeśli podstawą danych założeń jest ułatwienie stworzenia produktu wysokiej jakości, a w dodatku założenia są w miarę uniwersalne, powinny być standardem. Dotyczy to wszystkich dziedzin, w które zaangażowania jest praca twórcza. Obstawiam, że cześć z Was się z tym zgodzi. Zaskoczyło mnie jednak, że w programowaniu jest to czymś, do czego przywiązuje sie wagę nawet na wczesnym poziomie zaawansowania zawodowego... W odróżnieniu do innych branż z którymi miałem styczność.

Apptekarz napisał(a):

Zaskoczyło mnie jednak, że w programowaniu jest to czymś, do czego przywiązuje sie wagę nawet na wczesnym poziomie zaawansowania zawodowego... W odróżnieniu do innych branż z którymi miałem styczność.

1. Użytkownicy tego forum to zdecydowanie nie jest próbka reprezentatywna.
2. Wielu ludzi głosi, że pisze piękny kod, ale prawda jest taka, że po prostu nie mają właściwego punktu odniesienia.

Ja nie wiem co gorsze, czy ludzie, którzy piszą brzydki kod, czy ludzie, którzy są fanami wszelkich "dobrych praktyk" i piszą na siłę tak, żeby te "dobre praktyki" zachowywać. I pisz kod, który jest na siłę "dobry", że aż w rezultacie zły.

• przekombinowany (np. mnóstwo niepotrzebnych abstrakcji, coś co zawiera prostą logikę, ale napisane jest w najbardziej okrutny sposób, w 20 różnych plikach, żeby tylko się zajarać myślą, że się pisze ładne wzorce, nawet jeśli wcale nie są potrzebne).

• dobry pozornie, ale i tak wadliwy (np. ktoś przeczytał, że enkapsulacja to zło, więc robi wszędzie gettery i settery, które niemal tak samo łamią enkapsulację). Albo np. ludzie, którzy usłyszeli, że testowanie jest dobre, więc testują kod do poziomu, w którym każda choćby najmniejsza metoda ma własny unit test i testy odzwierciedlają niemal w 1:1 implementację, a takie coś ciężko utrzymywać (bo każda zmiana jakiegoś szczegółu implementacyjnego = zmiana testu). Czyli takie cargo cult. Naśladuje się coś, ale nie wie po co to jest. Jak ci nuworysze OOP, którzy wszędzie jadą na dziedziczeniu bo myślą, że "OOP polega na dziedziczeniu".

• zbyt rygorystyczny - np. ktoś nigdy nie zrobi copy-paste, bo to grzech. Mimo, że w pewnych sytuacjach duplikacja kodu jest lepsza od zbyt wczesnej abstrakcji https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction . Albo nadmierne rozwlekanie PR i kłócenie się godzinami o nazwę każdej zmiennej w commicie czy o to, że gdzieś są 2 entery zrobione zamiast jednego...). To niszczy produktywność. https://en.wikipedia.org/wiki/Law_of_triviality

Co nie znaczy, że nie należy starać się pisać dobrze. Tylko moim zdaniem trzeba również pamiętać o:

• KISS, YAGNI (żeby nie tworzyć nie wiadomo jakich przeinżynierowanych tworów)
• właściwym, głębszym zrozumieniu problemów, jaka dana rzecz ma rozwiązywać (np. testowanie). Problem w tym, że to jest proces, do którego dochodzi się czasem latami.
• pragmatycznym podejściu i odwagi do łamania zasad (albo przymykania oczu na to jak ktoś łamie) jeśli w danej sytuacji bardziej opłaca się złamać jakąś zasadę.