Wpis z mikrobloga

dalszy ciąg tego wpisu. W skrócie "pożarłem się z 'senior devem' o czystość kodu."

Mój kolega z zespołu, senior dev, popełnił w kodzie parę nowych metod, o długości ok. 20 linijek, w których wymieszał najróżniejsze rzeczy typu tworzenie requesta, obsługa response'a, error handling na różnych poziomach (network, http, zawartość response'a), mapowanie, itd. Na review mu podpowiedziałem, że skoro metoda robi To, To i jeszcze To, to powinien powydzielać do mniejszych metod co się da. Zaczął się rzucać, że on nie lubi takiego stylu, woli jedną "self-contained" metodę, gdzie widać na dłoni wszystko co się dzieje; dla niego wydzielanie metod służy tylko usuwaniu powtórzeń, a nie czytelności; dla niego jest czytelne i go nie obchodzi, że dla innych nie do końca. Gdy już byłem zmęczony dyskusją dlaczego to jest złe, podsunąłem mu rozdział 'clean code' przed nos i kazałem przeczytać. Przeczytał, nie zrozumiał i dalej się rzucał () Trochę smutne, bo w pracy nikt nigdy nie miał takiego nastawienia.

Nie wytrzymałem dłużej i powiedziałem mu, że w moim poprzednim zespole (który siedzi obok) nie przeżyłby jednego dnia z kodem o takim poziomie jakości i że ja nie mam zamiaru tracić czasu na takie dyskusje, ani schodzić poniżej swoich standardów. Będę uwalał wszystkie pull-requesty i nie obchodzi mnie czy będziemy mieć przez to opóźnienia.

Do tego mamy młodego kolegę w zespole - pierwszy tydzień pracy - i był świadkiem takiej dyskusji. Potem się mnie pytał czy tak jest zawsze :0
Stary pojechał dziś na dwutygodniowy urlop, więc pewnie też zaczął wakacje w super nastroju. W przyszłym tygodniu rozmowa z szefem, bo mam już dość, a z tego co się dowiedziałem, nie tylko ja miałem z tym gościem takie jazdy.

#programowanie #pracbaza #cleancode #czystykod #java
  • 18
Będę uwalał wszystkie pull-requesty i nie obchodzi mnie czy będziemy mieć przez to opóźnienia.


@beethoven: Jesteś najgorszym typem programisty. No offence. Koleś dał bardzo sensowny argument a ty sie rzucasz jakby klepał kod bezmyślnie.

Kilka lat pracy z devami z USA nauczyło mnie pragmatycznego podejścia i tego że kod ma działać, dać sie rozwijać i zarabiać. To czy metoda ma 20 linijek czy 5 nie ma abosultnie żadnego znaczenia - ważne
@PanJanuszTrzeci:

ważne jak łatwo się to czyta i czy można to łatwo przetestować.

Ale przecież na pisał że nie jest do końca czytelne.

Polski programista myśli jakby tutaj coś zrefaktorować, gdzie #!$%@?ć najnowszy język czy jakiego użyć frameworka/wzorca podczas gdy programista z USA klepie MVP na ROR (używając god objectów i lazy loadingu) żeby jak najszybciej zaprezentować się klientowi/inwestorowi.

Przecież ciśnięcie MVP to jest co innego niż długotrwałe rozwijanie produktu, gdzie
@PanJanuszTrzeci:
Pracuję w międzynarodowym zespole, gdzie każdy - niezależnie od narodowości - dba o jakość. Pragmatyczne decyzje podejmujemy na codzień, gdy widzimy, że np. na tym etapie nie ma sensu robić tej konkretnej części pięknie i idealnie. W naszym konkretnym przypadku jesteśmy już za etapem prototypowania i piszemy 'core backend' większego systemu, który ma być solidny, łatwy w utrzymaniu i działać przez lata. Dodatkowo, pracujemy w centrali - nie outsourcingu. Nasz
Dodatkowo, pracujemy w centrali - nie outsourcingu. Nasz klient oczekuje jakości i jest skłonny za ną zapłacić. Co więcej - przepisujemy kawałek, który właśnie był napisany szybko i byle jak.


@beethoven: Spoko, tego kontekstu mi brakowało. Jeżeli wszyscy są świadomi że jakoś tutaj staje na pierwszym miejscu to można cisnąć. Przyjąłem założenie że biznes po prostu chce mieć produkt a programiści powinni iść na kompromisy.

Moja rada - jeżeli nie możesz
Koleś dał bardzo sensowny argument a ty sie rzucasz jakby klepał kod bezmyślnie.


@PanJanuszTrzeci: Jak bym nie widział tej zachodnie kreatywności typu metoda robi 20 rzeczy i ma 200-300 linii to bym się zgodził. Wiesz jak kończy się to co piszesz? Plajtą albo bankructwem vid Erricosn tam dokładnie działają jak ty piszesz.
@beethoven: brzmisz jak jakiś junior, co naczytał się zbytnio teorii a teraz kozaczy. W programowaniu sztuką jest podejmowanie masy kompromisów - wiele dobrych praktyk jest niemożliwe do zastosowania np: przez to jak został stworzony framework i jak zostały narzucone metody. Dobry programista rozumie, że nie zawsze warto podążać ślepo za wzorcami i czystym kodem, bo w wielu przypadkach po prostu się nie da. Mi np wiele razy zwracają uwagą, że zamiast
Polski programista myśli jakby tutaj coś zrefaktorować, gdzie #!$%@?ć najnowszy język czy jakiego użyć frameworka/wzorca podczas gdy programista z USA klepie MVP na ROR (używając god objectów i lazy loadingu) żeby jak najszybciej zaprezentować się klientowi/inwestorowi.


@PanJanuszTrzeci: i dlatego potem kod z USA jak przychodzi do normalnych programistów, którzy potem mają za zadanie utrzymać całe przedswięwzięcie jest przepisywany od nowa.

Osobiście widziałem gównokod z USA i "działało", ale w idealnych warunkach
@beethoven: brzmisz trochę jak junior, z którym pracowałem. Gość zrobił merge requesta, gdzie pousuwał wszystkie komentarze w kodzie (oprócz javadoców), bo "czytałem clean code i komentarze są złe, a kod powinien się samokomentować hurr.. durr..". Oczywiście sam nie zadbał o to, żeby kod się samokomentował, on po prostu pousuwał komentarze, a niektóre komentarze, które pousuwał były dosyć istotne bo tłumaczyły, czemu ktoś użył bardziej skomplikowanego algorytmu zamiast prostszego itp.
I właśnie
@virtuti_stulejari: @leoha:
Ech, powtórzę się jeszcze raz. W naszym departamencie dba się o jakość - piszemy stabilne, daleko backendowe, długoterminowe produkty, gdzie jakość jest super ważna i maja być one łatwe w utrzymaniu. Każdy dba o jakość, zwłaszcza goście starsi stażem od wymienionego przeze mnie. Nie są to produkty pod klienta, gdzie ma być szybko naklepane, ale serwisy, które mają działać przez lata.

Dałem mu clean code bo jest najprzystępniejsza
@beethoven Mam wrazenie że stosujesz sztywne reguły bez zrozumienia ich podłoża i sensu. Reguły w Clean Code po pierwszale są opinia jednego człowieka, a po drugie są trafne w jakiejs części przypadków. Każdy projekt ma swoją specyfikę.
Cały czas mówisz o "jakości kodu" ale to właśnie kurczowe trzymanie się ogólnych zasadach o wytycznych i wpychanie ich wszędzie za wszelką cenę obniża ta upragniona przez Ciebie jakoś kodu. Jeśli sporo osób mówi Ci
@Passer93: podałem konkretne i łatwo mierzalne przykłady. W tym wpisie gość naklepał duże metody i nie uznaje rozbijania ich w imię czytelności, czyli woli jedną 20-30 linijkową niż kilka mniejszych. O ile to nie jest algorytm, a logika biznesowa to zwykle da się to rozbić. Jeśli metoda robi „A, B i jeszcze C”, to znak, ze potencjalnie trzeba ją rozbić ma mniejsze. Widziałem mnóstwo legacy kodu, który był naklepany w ten
@beethoven: nie wiem, co robiła ta metoda, więc wypowiadał się nie będę.. Ale 20 linijek kodu funkcja, to nie jest duża funkcja, wręcz max 25 linii kodu w dawnych czasach było brane za dobry wzorzec (bo mniej więcej tyle kodu mieściło się na jednym ekranie).

Robienie 2-3 rzeczy, też niekoniecznie musi być złe, zależy co to są za rzeczy.

Ponieważ za dużo tu zależy, więc ciężko powiedzieć kto naprawdę miał rację...