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.

0

Jeśli ustaliliście podejście X to nawet leader powinien z tego korzystać jeśli jednak ze względu na hajs, terminy etc padła decyzja robić byle było to powinien was uświadomić o tym, w końcu pewnie jest jakimś pomostem między wami a biznesem? W sumie pewnie najlepiej było by bardziej rozsądnie zarządzać długiem ale z drugiej strony to mvp.

1

@ToTomki:
Ale tak sobie myślę, że tym tokiem rozumowania powinniśmy wszędzie używać GOTO bo dla wielu jest czytelniejsze i każdy to zna :D

Mam realne argumenty za tym, że jednak warto poświęcić czas na zgłębienie wiedzy i jednak jej wykorzystywanie. Przykładowo w priv projektach nie rzucam nigdy wyjątki i zwracam błędy po prostu poprzez obiekty Either i dopiero mapuje je na jakieś http statusy w warstwie restów. Czyli de facto nie korzystam z instrukcji GOTO, którą jakby nie patrzeć jest rzucenie wyjątku. Do tego nie używam adnotacji i dynamic proxy springa - wszystko funkcyjnie. Jak coś mi się wysypie to najczęściej na etapie kompilacji.

Mam o wiele mniej bugów w swoich projektach, a kod może jest mniej czytelny dla większości ludzi, bo nie znają funkcyjnych bibliotek i nie wiedzą, że się da bez adnotacji.

W większości firm nie do przepchnięcia nierzucanie wyjątkami, ale chyba rozumiesz o czym mówię.

4

Niestety są tacy ludzie, którzy uważają się za Bogów kodowania i jak się im zwraca uwagę, że coś robią źle to nic do nich nie dotrze.
Kiedyś współpracowałem z gościem, który miał 8 lat mniej doświadczenia (sam miał rok) i nic do niego nie przemawiało.
Logiczne argumenty, powoływanie się na autorytety, na dokumentację, nic nie działało.
Nie próbowałem tylko "ad persona" (może by podziałało, ale nie czułbym się z tym dobrze).
Głupi nie był, ale do niczego nie dało się go przekonać, bez względu na to jak oczywiste było, że jest w błędzie i ilu szanowanych ludzi mu to mówi.
Jedynie co do niego przemawiało, to że naprawiło się bug-a, którego by autorem, albo nie był w stanie sam naprawić, ale szybko mu to przechodziło w niepamięć.

Jedyne lekarstwo to ignorować, a jak się nie da to zmienić pracę (jeśli pracodawca nie dostrzega problemu).

Przez +10 lat spotkałem się z 2 takimi przypadkami.

8

Też kiedyś miałem tak bardzo rygorystyczne podejście, natomiast ono z wiekiem bardzo mi złagodniało. Naszą rolą jako programisty jest tworzenie rozwiązań które dostarczają wartość biznesową, a nie perfekcyjnego kodu który nie istnieje. Oczywiście fajnie by było gdyby wszyscy trzymali się przyjętych standardów i można było czytać kod innych jak swój, no ale do tego trzeba mieć naprawdę zgrany zespół. Zresztą dobry kod to jest pojęcie bardzo uznaniowe, więc o ile nie mamy na to twardych dowodów, liczb, testów, przykładów a jedynie argumenty poparte autorytetem, no to zwykle gra nie jest warta świeczki. Żaden projekt nie upadł i nie upadanie przez to że ktoś sobie napisze klasowy komponent w reacie, użyje optionali wbrew temu po co powstały, użyje for zamiast foreach. To są rzeczy które nie mają wielkiego wpływu i nie warto się o nie dochodzić.

3
Bambo napisał(a):

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

Ok, ale TechLead czy kogo tam macie powinien jasno uświadomić biznes, że dowiezienie wcześniej wiąże się z długiem technicznym.

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.

Jak tak pisze bo jest szybciej to trochę ma rację.

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.

Tu raczej powinien napisać coś w stylu: "Wiem, że inaczej się umawialiśmy ale biznes goni a ja po robocie nie mam czasu ogarniać tych hooków"

Byle tylko dowieść wymagania nawet z kodem wątpliwej jakośći.

Ktoś chce szybko mieć MVP bo chce zobaczyć czy w ogóle projekt ma sens i ma w dupie SOLID. Trzeba znaleźć sweet spot pomiędzy zadowoleniem devów, że piszą czysto a biznesem który chce zarobić.
title

1

To ja jeszcze tylko dodam od siebie, też tak kiedyś myślałem - ale ten senior głupi, nie stosuje optionali, robi jakieś głupie null checki, iteruje po pętli foreachem zamiast np. mapem czy innymi lambdami.
Ale po jakimś czasie takie rzeczy to tylko malutki szczegół implementacyjny. Prawdziwy problem przychodzi, jak zakodzenie czegoś już nie jest banałem, a trzeba zrobić coś więcej niż czysty CRUD czy przelotówka na bazę. I wtedy dopiero widać, dlaczego ktoś jest seniorem.

2

Jak długo ten kod aktywnie pożyje?
Po 5 latach zmieni się prawie cały i to może ze 2 razy?

Czy za rok dla klienta będzie pracować inny zespół albo klient wróci do normalnego funkcjonowania na starych zasadach i ze starym systemem, a wasz projekt fajnie, że zrobił co miał zrobić, zdążyliście na czas (i w określonym budżecie) i na tym koniec tego projektu?

Na przykład robicie projekt na cito Lato 2020 pod koronawirusa i zmienne decyzje państw UE.

  1. Na 1 czerwca możecie dowieźć coś pokracznego i nie do utrzymania na dłuższy czas.
  2. Możecie zrobić projekt który da się utrzymywać i będzie elastyczny przy następnej pandemii. Dostarczacie "Lato 2020" najwcześniej na sierpień.

Koder będzie się upierać przy pkt. 2 ewentualnie jakieś ustępstwa i termin na lipiec.
Biznes z takim teamem koderów do jesieni zdechnie.

*Szybko
Tanio
Dobrze

Do wyboru max 2.*

Może tech-lead to tech-lead dlatego, że rozumie potrzeby biznesu a nie na zasadzie prostego przeliczenia 2 lata więcej expa od kodera?

2

Jak Ci się nie podoba siedzenie i patrzenie jak ktoś ustala co masz robić to zarekrutuj się do innej firmy na leada albo przejdź do innego teamu na leada a nie narzekaj tutaj na forum.
Najwyraźniej firma chce leada, który da więcej hajsu kosztem długu technicznego.

2

ja mam znowu inny problem z programistą, z którym pracuję. Jest dość przyzwoitym devem, ale dostaje ciarek, jak zaczyna pisać funkcjonalność i spędzamy sporo czasu nad doborem najlepszej możliwej nazwy klasy i jakby tu od razu ten kod zoptymalizować pod każdym względem i najlepiej jakby to było wszystko generyczne. Nie wiem, widocznie mam za niski dan i szczerze nie rozumiem takiego podejścia.
Wolę napisać funkcjonalność i ją przetestować pod każdym względem, dopiero jak mam pewność że wszystko działa, to robić refactoring, optymalizacje, clean code, itd. Czuję się spokojniejszy, jak oddaje działający kod, nawet jeśli jest tam nawalone 30-40% linijek więcej, niż jak mam oddać niekompletną funkcjonalność.

3

Jeżeli kod jest łatwo refaktorowalny, to niech tam nawet będzie 30 ifków jeżeli trzeba oddać na wczoraj

8

Jak macie wszystko otestowane, to możecie pisać brzydko a potem ew. poprawicie. Jak nie piszecie testów to bez znaczenia jak ładny kod napiszecie, ciężko będzie go utrzymywać w dłuższej perspektywie (nie spotkałem się z czystym kodem który po czasie nie wymagał refaktoryzacji, a w świecie js to już w ogóle gdzie nowe wersje libek pojawiają się co kilka dni).

Przy czym nie polecam unit testów wszędzie pisać z pokryciem na 90%. Całość pokryta funkcjonalnymi (z sensem, przypadki brzegowe + najważniejsze biznesowe), unity tylko wtedy gdy piszesz jakiś fragment i chcesz szybko sprawdzić czy działa tak jak tego oczekujesz (TDD). Backend jest zazwyczaj łatwo testować, chyba, że korzystacie z zewnętrznych usług. Front trochę ciężej ale są już fajne frameworki do tego jak np. cypress.

Druga sprawa to zespół, jeżeli np. 5 na 6 osób nie zna danej technologi, czy nie posiada konkretnych umiejętności wymaganych do pisania w proponowany przez Ciebie sposób - to nie możesz im narzucać swoich racji tylko musisz się dostosować i ew. nakierowywać ich na nowsze rozwiązania krok po kroku (bardzo, bardzo powoli).

Ostatnia to jak kiedyś wspominał @jarekr000000 - jesteś w stanie pisać naprawdę ładny, czysty kod pokryty testami - pod warunkiem, że ten projekt robi dużo $, wtedy jest na to czas bo są zasoby. Jak robicie jakiś MVP który nie zarobił jeszcze $1 to nie ma czasu na takie praktyki, co jest przykre ale prawdziwe - no chyba, że to jakiś projekt pod korpo gdzie już mają dużo $ i chcą go od początku dopieszczać - dlatego też unikam software house`ów, pracuję tam gdzie jest projekt z długim utrzymaniem i robi dużo $.

4

Wygląda że mamy odmienne rozumienie czym jest MVP.
Wg mojej wiedzy to nie jest coś co prezentuje się na pokazach.
Albo sprzedaje jako kod referencyjny.
To nie jest też projekt uczelniany gdzie się pieści każdą linijkę.

MVP ma po pierwsze się nie wywalać, po drugie spełniać wymagania funkcjonalne ważne w dniu oddania.
Chcesz robić kod którym potem będzie można się pochwalić w CV? To rób sobie coś w domu.

MVP, co równie ważne, musi być łatwo modyfikowalne.
A więc nie wtykasz w to nie wiadomo jakie patterny, nie robisz kompaktowych jednolinijkowców i nie uwspólniasz kodu dwóch pętli bo mają podobne (ale różne) zakresy.

0

@semicolon: przestalibyście już przywoływać ten problem z null? Bo jak null to błąd za miliard, to pewnie niewłaściwe ify to narobiły błędów za X miliardów w oprogramowaniu, więc idąc tą logiką należy prędzej unikać ifów. Jak ktoś zdaje sobie sprawę z faktu, że jakiś typ może strzelić null, to pisze odpowiednią logikę do tego.

9

Pewnie mam spaczoną wizję przez wykonywaną pracę ale z mojego (podkreślam mojego) doświadczenia wygląda to tak że tzw dobre praktyki itp do prawdziwej pracy ma się tak jak romanse i uniesienia miłosne do szarego małżeńskiego życia.
Nic tak kobietom nie ryje bani jak pogoń i tęsknota za idealną miłością a w przypadku programistów jak tęsknota za idealnym czystym kodem i architekturą.

Tymczasem (jeszcze raz podkreślę to tylko moje doświadczenie) soft powstaje ad hoc bo ktoś znalazł nisze, potem duży biznes to kupuje i inwestuje w rozwój biznesowy produktu a nie w rozwój techniczny. Czasem soft który kosztuje koło miliarda dolarów jest taką łatą na łacie że masakra.
Jaki to był dla mnie szok, że firma ciesząca się estymą ma jeden z produktów z gui z lat 90 tych I to kompletnie nieintuicyjny.
Jak pojawił się krasz to pytanie czy to poważny krasz czy nie. Poważny krasz to taki który występuje w scenariuszu biznesowym a niepoważny gdy klika się po apce randomowo.
W czasach młodości w jednej firmie nawet zostało przeze mnie zrobione wyliczenie ile kasy się trwoni. Kierownik przyjął to do wiadomości i tyle, średnio się tym przejął, czyli po prostu zlał to wszystko.

Może z tym całym it jest tak jak w tym kawale o generale co miał powodzenie u kobiet
29 na 30 dostaje w twarz, ale i tak wychodzę na swoje.

Teraz tzw dobre praktyki uskuteczniam w domu, warto je znać bo przydają się na rozmowach. W pracy szczerze napisze, czasami po napisaniu kodu trzeba sobie ręce umyć (bo brak czasu a ficzer dawno sprzedany i to na działać nie wyglądać) , ale w końcu tzw brudna robota jest najbardziej popłatna ;-)

Ps. Jak ktoś z szanownych ma inne doświadczenie to gratuluję i zazdroszczę. Jeśli można proszę o polecenie. Chociaż z drugiej strony kto by chciał z takim skrzywieńcem robić w miejscu gdzie jest pięknie :-|

1

Ja podszedłbym do tego z zupełnie innej strony. Zabrzmi to może sarkastycznie (sory) ale trzeba sobie odpowiedzieć na pytanie "dlaczego?". I to mega szczerze, bez owijania w bawełnę.

  • dlaczego chcę pisać dobry kod, skoro nie jest to docenione ani wymagane przez biznes? Trzyma mnie pasja, ego, sumienie czy coś innego? Może lepiej olać sprawę, być jak reszta zespołu, nie wyróżniać się, klepać 8h dziennie if na ifie i cieszyć się życiem po pracy, skoro inni mogą?

  • dlaczego irytuje mnie, jak starsi ode mnie stażem są "mniej profesjonalni" ode mnie, nie piszą testów, nie używają wzorców, nie znają dobrych praktyk? Dlaczego chcę być lepszy od nich, dlaczego celuję wyżej, mimo iż nikt tego nie docenia? Może lepiej olać sprawę, nabijać lata doświadczenia i zmieniać pracę co X lat za większy hajs?

Kluczem jest poznanie swoich motywacji, dopiero potem można rozmawiać. Bez tego dyskusja w ogóle nie ma sensu.

1
Markuz napisał(a):

Jak macie wszystko otestowane, to możecie pisać brzydko a potem ew. poprawicie

W przypadku MVP może i tak - jeśli klient wie że MVP to napisana na kolanie kupa spaghetti. W innym przypadku nigdy się takiego kodu nie poprawia bo nie ma na to czasu, chęci oraz wraz z czasem wokół problematycznego kawałka rozrastają się zależności utrudniające naprawienie.

Bolesną dla niektórych prawdą może być to, że można pisać całkiem dobry kod od samego początku. W taki sposób żeby był czytelny, w pełni testowalny, łatwy do rozszerzenia. Jeśli nie ma czasu na pisanie testów - ok. To MVP - mogą być niedoróbki. Ale te testy będzie można w przyszłości łatwo napisać.
W poprzedniej firmie byłem częściowo w podobnej sytuacji. "Seniority" głównego projektu było zakochane w ifologii i spaghetti. Na szczęście na bardzo długi czas trafiłem do innych gdzie mogłem pisać jak chciałem. Tam mimo ciasnych deadlinów udało się nie tylko dowieźć projekty na czas ale i można było z nimi bez problemu pracować dalej rozwijając bez najmniejszych kłopotów. Miałem też szczęście pracować w nich z ludźmi, którzy mimo początkowej niechęci do pisania czystego kodu (wynikającej z długotrwałej współpracy z osobami odpowiedzialnymi za projekt flagowy) dochodziły w końcu do wniosku że dodanie ifa albo zmiennej nie zawsze jest dobrym pomysłem.

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.

Takie narzędzia można wprowadzać do toczącego się projektu po rozmowie z ludźmi i ogólnej aprobacie albo będąc na pozycji pozwalającej na wymuszenie jakichś standardów. Jeżeli reszta ma uwagi autora w głębokim poważaniu to tak samo chętnie będą korzystać z jego innych inicjatyw.

Poza tym, MVP o którym mowa może być częścią dużego i złożonego projektu który jest napisany równie dobrze. Wtedy można sobie włączać co się chce tylko po to, żeby po pierwszym uruchomieniu rozpłakać się i wyłączyć narzędzie samemu :D

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żeli potrzeby biznesowe wpływają na strukturę kodu to jest już bardzo źle. Biznes definiuje zakres zadania i kryteria akceptacyjne ale nie jest od tego, żeby przejmować się ilością providerów, globalnymi zmiennymi czy innymi niskopoziomowymi, technicznymi aspektami kodu. Od tego jest zespół programistyczny i jeśli tenże zespół nie jest w stanie przewidzieć możliwych konsekwencji swojego lenistwa to jest po prostu słaby.

dlaczego chcę pisać dobry kod, skoro nie jest to docenione ani wymagane przez biznes? Trzyma mnie pasja, ego, sumienie czy coś innego? Może lepiej olać sprawę, być jak reszta zespołu, nie wyróżniać się, klepać 8h dziennie if na ifie i cieszyć się życiem po pracy, skoro inni mogą?

Np dlatego, że jeśli projekt który robisz to nie jest stronka w php dla warsztatu Zdzicha spod 10-tki to może się zdarzyć że to właśnie ty będziesz utrzymywać ten projekt przez np następne 4 lata. W takim przypadku pisanie spaghetti można porównać tylko z załatwianiem potrzeb fizjologicznych do talerza z którego zamierzasz tuż po tym zjeść.

Nie rozumiem tego pisania o "braku parcia biznesu na dobry kod". Biznes jest od biznesu, od programowania jest programista.
Tak samo inwestor chce zawsze zbudować coś najtaniej. Gdyby architekci i inżynierzy słuchali bezkrytycznie inwestora to budowa nie dotarłaby nawet do wykonania fundamentów.

2

Pytanie czy istnieje jakaś firma która robi wszystko idealnie, zgodnie ze sztuką. Jeszcze takiej nie widziałem.
Pamiętaj też, że praca to praca - dopieszczaj własne projekty, rób open source, to ma więcej sensu niż denerwowanie się na tego typu sytuację. Ty rób dobrze, a jeśli inni nie chcą to trudno.

2

Wszystko sprowadza się do magicznego trójkąta: kasa - jakość - zakres. Można wybrać dwa - trzeci zawsze będzie odstawać. Z reguły kasa (czyli też czas) jest ograniczona, więc wybierasz albo zakres albo jakość. Nie da się dwóch na raz. Języki programowania rozwijają się, składnia i możliwości są coraz lepsze. Tą samą rzecz można zrobić na coraz więcej sposobów. Trzeba wybrać ten zrozumiały, najefektywniejszy, ale w granicach rozsądku. Od pewnego czasu kieruję się złotą zasadą: good enough. Jeżeli coś działa i spełnia swoją rolę to OK. Ważniejsze dla mnie jest aby dany element można było łatwo zmienić, poprawić i ulepszyć jak dojdzie do takiej potrzeby. To kto czego użyje to tylko detal, oby był łatwo wymienialny.

1

@Bambo: nie chce mi się czytać całego tematu ale taki jest poziom większości - nie ma pojęcia co robi ani większej wiedzy. To jest poziom większości masy i przeciętności a masa ciągnie w dół. Nie wiem może znajdziesz firmę w której zaczniesz się spełniać ale moim zdaniem naprawdę ludzi którzy ogarniają jest może 2% i trudno na nich trafić w pracy, trudno wgle trafić w pracy na prace w której panuje naukowa atmosfera i luz bardziej towarzyszący nauce i wielkim odkryciom zamiast korporacyjnemu [CIACH!]. Na twoim miejscu nie skupialabym się na tym i nie próbowała realizować w pracy. W pracy głównie chodzi o to abyś pod koniec miesiąca dostał jak największy przelew tracąc przy tym jak najmniej siebie, jak najmniej nerwów i zdrowia. W tym momencie nie potrzebnie się tylko denerwujesz. Olej to i naprawdę nie oczekuj w pracy rocket science - to jest średnie miejsce do spełniania się jeżeli jest się bardzo dobrym technicznie. Lepiej wyluzować, nie walczyć z tym i olać podnoszenie poziomu a realizować się w domu np. jakimś własnym projektem albo np. spróbuj stworzyć jakiś startup czy produkt do google play. Tak będziesz się mniej irytować, przelew będziesz mieć na koncie a prywatnie będziesz mógł odkrywać swą pasje i coraz to lepsze rzeczy. Jeżeli uważasz ze umiesz coś lepiej to to pokaz i stwórz swój własny biznes a później jak Ci to wypali i będziesz kosić dobry hajs to daj mi 5% udziałów za ten pomysł. Łatwiej Ci będzie stworzyć samemu firmę i być szefem niż przedzierać się od code review team leada a potem coraz wyżej ku poprawie jakości.

2

Kolejne MVP pisane na szybko, które nie pójdzie do kosza tak jak powinno tylko bedzie rozwijane kilka lat? :D

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