Jakość kodu w pracy a prywatnie

Zauważyłem u siebie że w pracy produkuję kod bardzo słabej jakości i jest nieporównywalny z tym który tworzę dla siebie w czasie wolnym
Częściowo wydaje mi się że to przez to że w pracy czuję presję i staram się wszystko zrobić jak najszybciej i najbardziej łopatologicznie tym bardziej że reszta kodu stworzona przez innych już tak wygląda
Po drugie wydaje mi się że robię tak też dlatego że nie chce mi się tłumaczyć komuś jakiejś idei gdy o nią zapyta i tłumaczyć czemu uważam że to słuszne podejście bo mam może mało pewności siebie i nie uważam się za autorytet
Tworzę więc kod podobny który już jest ale jednocześnie wydaje mi się że się cofam w rozwoju

Tak jak mówię - kod tworzony hobbistycznie trzyma dość wysoki poziom, kod w pracy to istne spaghetti

Czy macie tak samo? Może to normalne że człowiek stara się trzymać standardu reszty kodu i lepiej zmienić firmę na taką która zatrudnia w większości specjalistów ergo kod jest lepszej jakości tak żeby nie nabierać coraz więcej złych nawyków?
A może to normalka w firmach i nie ma co liczyć że gdziekolwiek znajdę kod lepszej jakości?

A czy kod tworzony prywatnie zarabia? Jak nie to spróboj na nim zarobić, drastycznie szybko obniży się jego jakośc do poziomu jaki piszesz w firmie jak nie niższego ;)

Staram sie produkowac zawsze takiej samej jakosci kod. Niestety... Czasami nie jest to mozliwe.
Jezeli w pracy nie masz unit testow do bardzo krotki deadline. To sie nie da wyprodukowac ladnego kodu.

Pamietam, ze mialem skonczyc projekt w 18 godzin (nie w 3 dni, w 18 godzin). Kod byl straszny, az balem sie tam co kolwiek ruszac. Ale Projekt oddany pracodawca zadowolony.
Jak nie mam presji czasu to pisze sobie testy i staram sie by ktos zrobil code review (nie zawsze jest taka opcja)

Takze podsumowywujac
Jakosc taka sama gdy warunki sa takie same ;)

W domu zdecydowanie gorszy - mam malo wolnego czasu wiec jesli cos pisze to przewaznie na tzw. szybkosci. Wiec czesto ide na skroty typu zmienne publiczne i globalne, god objecty, duze wszystko majace funkcje, hardcodowanie niektorych rzeczy, brak komentarzy etc. mimo wszystko staram sie zachowac jakas spojna logike, konsystencje i sensownosc nazewnictwa i organizacji kodu.

Inna sprawa ze dziadowski kod nie koniecznie jest szybszy w pisaniu, przyklad konkursy Compo - jesli sie zastanowi chwile nad projektem, rozplanuje sensownie strukture danych, podzieli dobrze na klasy, to potem mimo olania niektorych dobrych praktyk idzie to szybko a kod jest w miare przejrzysty.

.. i dlatego w zespole zgodziliśmy się na filtry które nie wpuszczają kodu do repozytorium release jeśli nie spełni wymagań co do jakości wewnętrznej. Stopniowo "dociskamy śrubę" jak jest czas na polepszenie czytelności w kodzie który już jest. Na razie się udaje. Dwa miesiące temu było ~40% odrzuceń kodu (z różnych powodów nie tylko z powodu jakości wew.), teraz jest ~5%.
Projekt stosunkowo świeży i po przebojach ze spagetti code w poprzednich projektach.
Co do pytania. Kod w pracy nieco gorszy niż prywatny. Staram się jednak by był .... "przyzwoity" :-/

moim zdaniem nie jest normalne trzymanie sie 'standardu reszty kodu'. pewnie z 80% czasu ktory poswiecam na kodowanie w pracy to poprawianie jakosci juz istniejacego kodu. nie bardzo rozumiem podejscie 'to nie moje, wiec co mnie to obchodzi', 'wszyscy robia dziadostwo, to ja tez'. zacznij pisac kod lepszej jakosci zamiast czekac, az ktos inny zrobi to za ciebie :)

edit: odpowiadajac na pytanie - w domu zajmuje sie nieporownywalnie mniejszymi projektami i jest to wylacznie moj wlasny kod, zwykle dopieszczony do granic mozliwosci ;)

fasadin napisał(a):

Staram sie produkowac zawsze takiej samej jakosci kod. Niestety... Czasami nie jest to mozliwe.
Jezeli w pracy nie masz unit testow do bardzo krotki deadline. To sie nie da wyprodukowac ladnego kodu.

Przyjmując takie założenie że masz napisać aplikację i na tym się już kończy (w perspektywie nie będzie chociażby jej rozbudowy) i właśnie te nieszczęsne krótkie deadliny, odpowiedz sobie na jedno zasadnicze pytanie: ile zyskasz przez tą jakość? Jeszcze trzeba by to jasno zdefiniować, bo komuś dla przykładu może się nie podobać Twój kod, choć Ty uważasz że jest OK a Ty np. stwierdzisz że to co ktoś inny napisał można by rozwiązać inaczej.

Problem polega na tym, że przy pewnych założeniach możesz sobie tylko nadać niepotrzebnie więcej roboty, za tą samą cenę (zakładam np. jakieś projekty fixed) a można to było uzyskać mniejszym nakładem pracy. Chociaż z drugiej strony na bazie moich doświadczeń, jakieś 80% czasu to poprawki a np. zastosowanie takiego podejścia jak MVP w takiej aplikacji desktopowej to po prostu znacznie prostsza (choć mimo wszystko bardziej pracochłonna) realizacja projektu. Więc tak się zastanawiam czy nie ma tu jakiegoś istotnego kryterium wyboru, bo tu trzeba by znaleźć jakiś balans w tym wszystkim a niepotrzebna robota to stracony czas.

Pytanie: w pracy nie macie review codu? Jesli ktos u mnie w pracy napisze badziew, to nie dosc ze jest obciach na review (kazdemu sie zdarza, ale czasami sa rzeczy ze az wstyd) to potem i tak trzeba poprawic.

U mnie jest tak, ze pod pewnymi wzgledami kod w pracy jest lepszy, a pod innymi jest gorszy. Kod w domu nie ma komentarzy, najczesciej nie jest przetestowany - najczesciej tylko ja go uzywam, a jesli np. moja dziewczyma to juz wiecej pracy wkladam ale tez mowie 'rob to tak i tak' to bedzie dzialac. W pracy mamy testy (nie do wszystkiego), obowiazkowo dokumentacje itp. Z drugiej strony, w domu nie mam terminow, czesto jest tak ze cos napisze bardzo szybko byleby tylko dzialalo bo chce tego uzywac, i jesli wiem, ze nie jest do do konca 'ladne', to mam czas zeby poczytac, doksztalcic sie i poprawiam. Tego w pracy nie mam - najczesciej robie zeby dzialalo (terminy, terminy, terminy) i jak juz zadziala to trudno jest potem wytlumaczyc ze nalezaloby to 'zrobic porzadnie'. Ale popelnilem tez bardzo duzo dobrego kodu w pracy, bez dokumentacji, i gownianego kodu w domu z doku, wiec reguly nie ma.

WhiteLightning napisał(a):

Pytanie: w pracy nie macie review codu? Jesli ktos u mnie w pracy napisze badziew, to nie dosc ze jest obciach na review (kazdemu sie zdarza, ale czasami sa rzeczy ze az wstyd) to potem i tak trzeba poprawic.

Review ma sens tylko wtedy, jeśli osoba go przeprowadzająca potrafi dobrze programować. Jeśli miłośnik spaghetti robi review miłośniczce godobjectów, to nic dobrego z tego nie wyjdzie.
Najgorzej jest, jeśli pisze się kod lepszy niż reviewer, bo trzeba się z nim użerać, żeby cokolwiek wytłumaczyć. Alternatywną ścieżką w takiej sytuacji jest review polegające na ciągłym przytakiwaniu - z takiego też nic nie wynika.

Poza tym durne reguły stylecopa, kretyńska archiektura, brak znajomości używanych technologii - to wszystko ma duży negatywny wpływ na jakość kodu.

Odpowiadając na pytanie - oczywiście, że w domu piszę lepszy kod niż w pracy. Jeśli ktoś tego nie robi, to znaczy chyba, że się w wolnym czasie nie rozwija.

somekind napisał(a):

oczywiście, że w domu piszę lepszy kod niż w pracy. Jeśli ktoś tego nie robi, to znaczy chyba, że się w wolnym czasie nie rozwija.

Chcesz przez to powiedziec, ze jesli ktos nie pisze w domu kodu wcale, to sie nie rozwija? Albo ze jak pisze taki sam, ale uzywa innych technologii, jezykow itp. to tez nie?

ccboy napisał(a):

Chcesz przez to powiedziec, ze jesli ktos nie pisze w domu kodu wcale, to sie nie rozwija?

Wydaje mi się po prostu, że ludzie, którzy chcą się rozwijać, tworzą coś poza pracą.

Albo ze jak pisze taki sam, ale uzywa innych technologii, jezykow itp. to tez nie?

To jakim cudem może pisać taki sam, skoro pisze w czym innym?

somekind napisał(a):

To jakim cudem może pisać taki sam, skoro pisze w czym innym?

chodzi raczej o architekturę, nawyki i używanie wzorców / antywzorców, a te są w większości niezależne od języka

somekind napisał(a):

ccboy napisał(a):

Chcesz przez to powiedziec, ze jesli ktos nie pisze w domu kodu wcale, to sie nie rozwija?

Wydaje mi się po prostu, że ludzie, którzy chcą się rozwijać, tworzą coś poza pracą.

No nie wiem, ja np. czytam ksiazki, ucze sie jezykow obcych, i tak dalej, wydaje mi sie ze sie rozwijam. Nie programuje zbyt duzo w domu.

Uważam, że nie ma znaczenia, czy piszesz kod w ramach jakiegoś swojego prywatnego projektu w domu, czy piszesz kod w pracy. To tak, jakbyś pytał "Czy jesteście uprzejmi dla innych ludzi tylko w domu, czy w pracy też?". Albo robisz coś porządnie cały czas, albo wcale. Crapware to crapware. Słaby i brzydki kod prędzej czy później się na Tobie zemści, albo zemści się na nieszczęśnikach, którzy będą zmuszeni grzebać w Twoim spaghetti rzucając WTF-ami na prawo i lewo. Jeżeli sam będziesz musiał utrzymywać ten kod, to będziesz tylko coraz bardziej grzązł w bagnie, aż w końcu to bagno Cię wessie i stracisz kontrolę nad tym, co robisz.

Sam staram się pisać dobry kod zarówno w ramach projektów prywatnych, jak i w pracy. W pracy jest nawet trudniej napisać słaby kod, ponieważ są code reviews i wstyd byłoby mi pokazać coś słabego kolegom z pracy. Pisanie dobrego kodu nie przychodzi od razu i pamiętam, że parę miesięcy temu lub np. rok temu pisałem dużo gorszy kod niż teraz. Ważne, żeby wyciągać wnioski ze swoich błędów i nie popełniać tych samych błędów w przyszłości. Są różne publikacje na temat tworzenia dobrego kodu, dobrych praktyk pisania softu. Warto je przeczytać. Jeżeli przeczytasz je uważnie i ze zrozumieniem, to będziesz pisał dobry kod zawsze, albo chociaż będziesz się starał. Warto też zajrzeć w kod popularnych projektów open-source lub zrobić tam swojego pull requesta. Gwarantuję Ci, że jeśli napiszesz coś słabego, niezgodnego z przyjętym standardem, konwencją lub wizją, to w dobrym projekcie nikt tego nie wpuści do repo.

Staram się pisać tak samo dobry kod w pracy jak i w domu, choć kodu w domu piszę ostatnio bardzo mało. Duża część kodu pracowego jest otwarta, a git blame nie zapomina. Do tego robimy obowiązkowy przegląd kodu przed każdą wrzutką czegokolwiek do gałęzi głównej. W przypadku większych zmian, przegląd robi 2 lub nawet 3 recenzentów.

Poza tym jestem bardzo wymagający podczas przeglądów kodu i przeglądy z ponad setką komentarzy i kilkoma rundami się zdarzają. W efekcie czasem potrafi zająć tydzień przegląd czegoś, co zostało napisane w dzień. Ktoś mógłby napisać, że to dość drastyczne i upierdliwe, ale dzięki temu projekt jako-tako trzyma poziom i się nie rozłazi, liczba zgłaszanych błędów jest dość mała, pokrycie testami wysokie (>80%), a kod czytelny i w miarę uporządkowany. Zresztą mimo tego drastycznego podejścia do jakości kodu i tak nadal są miejsca, w których wkradł się chaos, bo czasem trzeba niestety coś zrobić na szybko.

Jak mogę to piszę najlepiej jak umiem.
Problem w tym, że nie zawsze mi wolno zainwestować kilka dni, bo u kierowników bywa podejście typu: Oddaj jakkolwiek aby działało, a martwić się później będzie kto inny.
Były też przypadki kiedy bezsensownie zwiększałem complexity w kodzie z pełną świadomością tego, że tak będzie źle bo np nowy kod nie robi nic czego już inny by nie robił, a tylko spowalnia aplikację i buduje piramidy ifowe, ale cóż słabym duplomatą jestem.

Code review jest fajne, bo jakieś oczywiste bzdury wyłapuje, ale nie oszukujmy się, jak jest 5 osób w zespole i każdy ma na sobie po 10~20 tasków na szybko to nikt się nie będzie jakoś specjalnie wczytywał w kod kolegi, szczególnie, że nie zna założonej logiki.