Jak radzicie sobie z kiepską jakością kodu projektów do których dołączacie?

1

Całego zespołu nie przekonasz, ale próbuj z pojedynczymi osobami, które wydają się być sensowne. Powoli moze tak coś ugrasz.

Jeśli są inne zalety projektu to polecam je wykorzystać, a jak sie skończą to życzę wszystkiego najlepszego w nowej pracy. Zdrowie fizyczne i psychiczne jest najważniejsze.

11

Praca u podstaw.

  1. Robisz porządnie
  2. Jak dotykasz jakiegoś gówna to przy okazji poprawiasz
  3. Ciśniesz na Code Review bez litości
10

Kilka razy padło już tutaj co należy robić aby poprawić obecną sytuację i nie będę się powtarzał...
Zaciekawiło mnie jednak to że trafiając często do projektu, który jest już na rynku jest narzekanie. No i ok. Tylko czy ten ktoś zna cały kontekst tego projektu? Z jakiegoś powodu ta jakość została obniżona - terminy, kasa, jedno i drugie.
Łatwo wejść i osądzać nie znając kontekstu.

Druga sprawa. Czy na pewno taki ktoś stworzyłby lepszy system? Łatwo piwiedziec, że coś wygląda jak g**no, tylko czy taka osoba w tych samych warunkach i mając te same problemy zrobiła by lepiej?

No i na koniec. Chyba w czystym kodzie to było, że robiąc coś staramy się robić dobrze i dodatkowo poprawiamy coś jeszcze. Nie musi być dużo. W ten sposób małymi kroczkami wyciera się to g**no z dywanu i dywan zaczyna przypominać dywan, a nie kuwetę.

Chcesz żeby ludzie zaczęli pisać lepszy kod? Ty zacznij najpierw.

2

<sarkazm>
zmieniam pracę
</sarkazm>

6

Skup się na samo-rozwoju i w miarę możliwości szukaj nowej roboty.

Na razie nie trafiłem na firmę, w której kod byłby ultra-wysokiej jakości. Jeżeli kod trzyma jako-takie standardy, nie macie tam Rybki extends Akwarium ani nie synchronizujecie wątków sleepem, to należy zacisnąć zęby i po prostu robić swoje dobrze. Jak widzisz coś źle napisanego to stopniowo poprawiasz.

Ponadto każdy kod pisany przez innych wydaje się mniej zrozumiały i gorszy niż gdybyś go sam napisał. Po prostu czytając cudzy kod często nie znasz całego kontekstu i wszystkich okoliczności jego powstania (jak również wszystkich przypadków brzegowych).

Każdy nietrywialny projekt ma dług techniczny, więc ważniejsze jest to z kim pracujesz i czy jest nawyk regularnego sprzątania niż to w jakim stanie kod jest dzisiaj. Zmieniając pracę możesz trafić na coś znacznie gorszego.

Czy jeżeli w kilkusetosobowej firmie jakiś programista zrobił w kodzie nawet coś bardzo debilnie głupiego to na pewno Ty się powinieneś zwolnic, czy może jednak autor/recenzent debilnego kodu? Takie rzeczy się zdarzają i dopóki są wyjątkiem a nie norma to zwalnianie się z tego powodu że ktoś inny niż umie pisać zbyt mądre nie jest.

13

Podpowiem Ci co na pewno nie zadziała:

  1. Narzekanie i hejtowanie zastanego kodu, sianie defetyzmu
  2. Nie branie odpowiedzialności za jakość
  3. Wywyższanie się na forum zespołu
  4. Forsowanie swojego zdania
  5. Ciśnięcie ludzi komentarzami na code review, nie pokazywanie jak można zrobić lepiej
  6. Nie dzielenie się wiedzą
  7. Praca solo
  8. Feedbackowanie managerowi, że „ale tutaj jest słabo”
8

Oczywiście kiepski kod to pojęcie względne, tym niemniej - zakładam, że kod kiepski to taki, który sprawia Ci dyskomfort psychiczny, bo umiał byś to samo napisać wg Ciebie dużo lepiej.
Jeśli kod jest kiepski, ale zespół wie, że jest ten kod jest taki i chce go naprawiać to jest bardzo dobrze.
Jeśli kod jest kiepski, ale pozwalają Ci pisać dobry - to jest znośnie.
Jeśli kod jest kiepski i każą Ci pisać kiepski to wtedy nie ma wyjścia - spierniczaj.

W zasadzie to juz na rekrutacji do projektu badam jaki jest stosunek zespołu do kodu:
jeśli zespół jest przekonany, że mają super kod to od razu wychodzę :-) - albo kłamią, albo nic się nie uczą i utknęli w bylejakości.

3

Ogólnie chciałem dorzucić moje dwa grosze - kiedy kod będzie kiepski:

  • Ludzie nie formatują kodu, dopóki nie zmusi się ich wywalaniem ERRORA przy kompilacji, jezeli taki jet
  • Ludzie nie chcą się uczyć w ogóle i zostają przy starych nawykach - np strumienie są używane, ale gdy termin mocniej przyciśnie, to wracają do forów, ifów, słowników i kodu wyglądającego jak imperatywny (mimo, że w C# strumienie są prostsze niż pętle lol)
  • Na CodeReview w przypadku komentarzy jest odpowiedź, że albo poprawią w następnym PR (co zwykle nie następuje), albo że "Terminy gonią" (co paradoksalnie prowadzi do mocnego przekroczenia terminów, bo kod jest nierozwijalny)
  • Ludzie się nie rozwijają, podsyła się im materiały wymagające niskiego nakładu pracy (np 2h prezentacji na YT która tłumaczy temat na tyle, żeby nie robić głupot, np
    , a ludzie cały czas zamiast robić odpowiednik bind robią .Value i tego używają
  • Brak znajomości języka, ludzie z 10y expa nie wiedzą jak działa LINQ, jak traversować ExpressionTree, GC/JIT to czarna magia, do której się podchodzi czarami, nie mają pojęcia o implikacjach zrób GC.Collect()

Osobiście próbowałem z tym walczyć, ale jak jest przewaga betonu, to lepiej się podskilować, żeby nie robić samemu głupich błędów i pochodzić po rekrutacjach - i ważne, sprawdzić tam poziom zespołu, np zadawając im pytania ;).

0

Hipoteza: W dowolnym "nietrywialnym" kawałku kodu. (Czyli powiedzmy dłuższym niż 20 linii.) Nieważne jak porozbijasz na klasy, metody, funkcje - to SRP jest zawsze złamana. — @jarekr000000 5 minut temu

@jarekr000000:

def dispatch_command(command: str) -> type:
    return {
        "up": Up,
        "down": Down,
        "left": Left,
        "right": Right,
        # w sumie 20 takich warunków
        "fire": Fire
    }[command]

Gdzie w tym kodzie złamane jest SRP?

1

@twoj_stary_pijany: Jak na mój gust, to to jest jednolinijkowiec i jest to właśnie kod trywialny.
To, jak jest to sformatowane to już inna kwestia, więc przykład mało adekwatny.

@jarekr000000 to raczej miał na myśli coś, co zawiera faktyczną logikę, z której te "linijki" się biorą.

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