Radzenie sobie z innymi programistami

3

Hej, mam ostatnio trochę irytujące sytuacje w pracy. Jestem typem programisty, który stara się być świadomym technologii jakie używa i zawsze poczytam dokumentacje, good practises, blogi, forum, popytam ludzi doświadczonych w danej technologii - nie ufam bezgranicznie tutorialom.

Mamy obecnie sytuacje, gdzie musimy jak najszybciej dociągnąć wersję MVP do końca, bo biznes goni. I to jest zrozumiałe.

Mam jednak sytuacje, gdzie robiąc review naszemu team leadowi widzę, że kod działa, biznes dostaje to co chce, ale kod jest strasznie źle napisany (np javowe optionale stosowane tak jak null checki z metodami ifPresent() oraz get()). Jak piszę uwagi odnośnie tego, to dostaję odpowiedź, że wymaganie działa, więc nie traćmy czasu na robienie sztuki.

Drugi przykład był taki, że w powiedzieliśmy sobie teamowo, że używamy w React funkcyjnych komponentów i react hooków skoro tak rekomenduje facebook. Poświęciłem sporo czasu na ogarnięcie tego, zrozumienie jak zarządzać stanem, długie godziny rozkmin jak poprawnie używać tych react hooków itd. Robię teraz te komponenty funkcyjne i wszystko fajnie działa, kod wygląda lepiej. Robiłem ponownie review, gdzie był zrobiony przez team leada komponent klasowy a nie funkcyjny, więc napisałem, że postanowiliśmy inaczej .. dostałem odpowiedź, że żal tracić czasu na przerabianie dla samej sztuki bo nie ma innych profitów. Nie wspomnę o tym, ze przerabianie komponentu polegało na tym, że kodu NOWEGO zostało dopisane 98% całości .. to co było zrobione to zwrócenie JSX bez logiki.

Ja prywatnie nie mam nic do tych ludzi, są niezłymi programistami, kumają czacze, ale po prostu szlag mnie trafia jak ktoś się uważa za leada czy seniora bo ma 1-2 lata expa więcej i jest w projekcie dłużej rok, a nie promuje w zespole chęci rozwoju i jakiegoś takiego szerszego spojrzenia. Byle tylko dowieść wymagania nawet z kodem wątpliwej jakośći.

Nie daje mi spokoju to, że praktycznie nie mam argumentów przemawiających na pisanie dobrego kodu skoro wymagania biznesowe działają mega spoko na słabej jakości kodzie. Można by argumentować to długiem technicznym, ale kurde .. to nie jest źle zaprojektowany kod tylko napisany albo wg starego stylu mimo innej rekomdancji autorów liba albo nieidiomatyczny (np. optionale niezuwane w stylu funkcyjnym) albo narzędzie użyte po to, bo pozwala coś łatwo zrobić, ale generalnie jego zastosowanie jest inne.

Nie wiem, nie macie podobnych sytuacji ? Może faktycznie olać pisanie dobrego kodu .. ale z drugiej strony jak ktoś poświęci czas na ogarniecie poprawnego sposobu używania danej technologii czy libki to ten kod jest o wiele lepszy, czytelniejszy, zwięźlejszy i piszę się go krócej de facto .. ale no to nie przetłumaczysz czasem.

8
że żal tracić czasu na przerabianie dla samej sztuki bo nie ma innych profitów.

Trzeba konkretnie i to z liczbami. Ja wprowadzając nową technologię czy refaktoring nie robiłem dla sztuki - zawsze jest wiele przeciwników zmian. Konkretne benchmarki "ta metoda jest 5x szybsza", "przez złą jakość kodu mieliśmy tyle a tyle defectów prowadzacych do takich a takich opóźnień". Wprowadź automatyczne narzędzia - lintery kodu, sonaru quby, testy statyczne. Wprowadzasz nową technologię - napisz poradnik krok po kroku co muszą robić, zrób sesję na której pokazujesz jak to robisz i nagraj to itp.

Ale jeżeli nie ma żadnych profitów..to po co, nie lepiej zająć się jakimś projektem na boku? ;) Mnie też boli kod innych ale dopóki działa a ja np. nie mam głosu w projekcie to mogę tylko zgłosić to jako uwagę w PR. Wyrób sobie dobrą opinię, wprowadzaj zauważalne usprawnienia, stań się ekspertem do którego ludzie będą się zgłaszać to Twoje uwagi na temat jakości kodu będą wysłuchiwane i będziesz mógł wymuszać utrzymanie standardów nawet jeżeli nie będzie łatwo przekładalnego zysku dla biznesu.

7

są niezłymi programistami

Z twojej opowieści wynika co innego.

Nie daje mi spokoju to, że praktycznie nie mam argumentów przemawiających na pisanie dobrego kodu skoro wymagania biznesowe działają mega spoko na słabej jakości kodzie

To ze kod "działa" akurat nic nie znaczy. Kod pisze się dla ludzi do czytania/zmieniania a nie żeby działał na komputerze ;) Argument nazywa się dług techniczny

to nie jest źle zaprojektowany kod tylko napisany albo wg starego stylu mimo innej rekomdancji autorów liba albo nieidiomatyczny (np. optionale niezuwane w stylu funkcyjnym) albo narzędzie użyte po to, bo pozwala coś łatwo zrobić, ale generalnie jego zastosowanie jest inne.

To jest źle zaprojektowany kod :) Podałeś właśnie definicje słabego kodu.

Anyway: nie ma sensu kopać sie z koniem. Idź do normalnej firmy.

7

Mam jednak sytuacje, gdzie robiąc review naszemu team leadowi widzę, że kod działa, biznes dostaje to co chce, ale kod jest strasznie źle napisany (np javowe optionale stosowane tak jak null checki z metodami ifPresent() oraz get()). Jak piszę uwagi odnośnie tego, to dostaję odpowiedź, że wymaganie działa, więc nie traćmy czasu na robienie sztuki.

wszystko fajnie działa, kod wygląda lepiej.

A może po prostu tak Ci się wydaje, że jest lepiej. Im dłużej programujesz tym dostrzegasz więcej opcji, możliwych konstrukcji do użycia, szczególnie sexy "best practices", wzorce i inne srebne toole, które stanowią nie małą okazję do nadużyć. Takie intelektalne szaleństwo, rozumiesz - skąd wiesz czy nie wpadłeś w to teraz? Zastanowiłeś się chociaż czy robisz jakieś biznesowo trudne zadania? Jeśli nie to czy Twój kod ciężko byłoby wyjaśnić innemu juniorowi? Albo inaczej czy junior byłby w stanie to zrozumieć, czy musiałby robić długie rozkminy?

Nie daje mi spokoju to, że praktycznie nie mam argumentów przemawiających na pisanie dobrego kodu

Brak argumentów oznacza, że nie wiesz co robisz. Nie wiesz nawet dlaczego tak robisz. Być może robisz tak bo tak teraz piszą w dokumentacji reacta, być dlatego, że taka jest moda, ale u podstaw jest brak świadomości co z czego wynika, dlatego najpierw rozpoznaj PROBLEM, dlaczego coś jest złe.

Pamiętaj wszystko co używasz raz jest dobre, a raz może być złe. Poczekaj nim zaczniesz innym mówić jak mają pisać (zwłaszcza, że od niedawna robisz tego reacta!). Natomiast w review zamiast pokazywać palcem co mniej lub bardziej fajne zastanów się jaki wyjdzie problem. Pokaż problem - zapytaj czy świadomie podejmujemy decyzje, która uniemożliwi nam zrobienie ważnego testu, czy świadomie stawiamy na jednego providera, czy świadomie uzależniamy resztę kodu od globalnej - bo jeśli tak to, to jesteś szczęściarzem masz konkretne wymagania, piszesz konkretny kod i tak ma być. Takie są potrzeby biznesowe i super design nigdy nie powinien przyćmić celu do jakiego się dąży.

Jeśli jednak problem o którym piszesz nigdy się nie pojawi to ktoś tu system niepotrzebnie komplikuje, uważaj, bo tym razem to możesz być TY! :) Natomiast jak pojawi się problem to polecam pomóc w temacie, zamiast obrażać się przedstaw sposób jak można odkręcić dana rzecz najtańszym sposobem - rozwiązywanie biznesowych problemów to postawa jaka chciałbym widzieć u spoko programistów.

Inaczej nawiąż współpracę z helionem i pisz książki o tym jak powinno się pisać, może poprawisz jakiś kawałek tego świata, może to jak piszesz rzeczywiście jest lepsze - dlaczego miałbyś kopać się z koniem? A i też konferencje, podcasty to też spoko opcja. Pomyśl o tym, bo to też ciekawy kierunek :-)

1

Nie wiem, jakie stoją z ty projektem wymagania. Ale jak jest MVP, to może rzeczywiście nie warto sie rozwodzić, nad czymś, co ma 10% szans przeżycia. Może nie masz całego obrazu sytuacji, a ich decyzja wynika z czegoś innego, zwłaszcza jak uważasz ich za dobrych programistów.

1

@semicolon:
@Tomek Pycia

Ale mi nie chodzi o stosowanie hiper nowych rozwiązań, które można powiedzieć są wręcz hipsterskie albo dość trudne do opanowania.

Mi chodzi o takie oczywistości typu, że jak ktoś już używa optionali to żeby je używał zgodnie z tym po co one powstały i słuchał się chociażby środowiska skoro rzuca ono warningi.
No raczej stosowanie optionali z ifPresent() i get() nie powoduje, że coś nie działa, ale jest użyte niezbyt zgodnie z ich przeznaczeniem.

Tak samo react - funkcyjne vs klasowe. Dla mnie oczywistymi argumentami zarówno jeśli chodzi o te optionale i użycie funkcyjnych jest czytelnośc kodu, jego zwięzłość, testowalność.

Mi chodzi bardziej o kontargumenty na to, że działa i biznes dostaje to co chce.

A też użycie POPRAWNIE optionali oraz funkcyjnego komponentu skoro sam react to rekomenduje przecież nie jest nawet zainwestowaniem dodatkowego czasu .. To jest zrobienie tego zgodnie z zaleceniami autorów :D

2

A jesteś w stanie podać argumenty przeciwko ich podejściu inne niż "środowisko wypluwa błędy", "optionale nie po to powstały", które faktycznie mają wpływ na późniejsze funkcjonowanie systemu? Jego utrzymanie? Po prostu na pieniądze?

0

@semicolon: przykład z optionalami:

final Optional<Long> optional = Optional.of(2L);

        if(optional.isPresent()) {
            System.out.println(optional.get());
        } else {
            System.out.println("No value");
        }

        optional.ifPresentOrElse(
                System.out::println,
                () -> System.out.println("No value")
        );

Sposób z ifami wykorzystuje Optionale niezgodnie z ich zastosowaniem. To działa, ale po co w takim razie ktoś używa optionala jak może użyć null check ? To takie trochę bawienie się w Optionale bo weszły w Javie 8 i są fajne, ale jednak nie tak jak powinny. Siana to Ci więcej nie zarobi, ale dla mnie jest mniej czytelniejsze .. wolałbym null check zwyczajny.

5

Oj, kolego, uwaga, uwaga. Może ja się mylę i nie zasugerowałeś tego, ale chyba widzę mały problem. Zwięzły to dla większośći ludzi zdecydowanie nie synonim zwrotu "bardziej czytelny" ;).

4

Ja tam dałem sobie spokój z nadmiernym przekonywaniem - przekazuje swoją opinię, trochę podyskutuje, ale nie naciskam. Jak miałem racje i słaby kod się mści, to mniej więcej po jakimś roku ktoś "wyżej postawiony" (lub grupa programistów) wpada na dokładnie ten sam pomysł i zmiana jest wprowadzana. Jak kod się nie mści, to najwyraźniej moja uwaga była "sztuką dla sztuki", lub była błędna i zostaje zapomniana.

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