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

0

Dołączacie do nowego projektu, jako doświadczona jednostka, która swoje widziała i przeżyła i w niejednym projekcje już była.

Mimo zapewnień, okazuje się, że kod w projekcie jest trochę na odwal się - trochę trzyma standardy ale w większości nie i jest generalnie absolutnie nie tak, jakbyście to sami napisali.

Firma dobrze płaci, ale boli was to, że musicie się dostosować do tego syfu - całego teamu nie przegadacie, a szczególnie nie jako nowi.

Jak sobie z tym poradzić? Jak schować do kieszeni ten wewnętrzny głos, który mówi wam, że ten kod to syf i zamiast tego skupić się po prostu na robieniu i dostawaniu za to pieniędzy?

16
  1. Zawsze programuj wg zasady skauta.

  2. Regularnie proś o podwyżki.

  3. Regularnie na standupach o ile takowe macie, mów, że to, to i tamto jest źle zrobione.

  4. Pokaż wszystkim, że dobry kod sam sie obroni - pisząc takowy.

  5. Wskazuj na Code Review u innych miejsca gdzie popełniają błędy.

  6. Regularnie przypominaj o długu technologicznym

  7. W razie przedłużającego się czasu na dowiezienie czegoś, zwalaj winę na kiepską jakość kodu (o ile to faktyczna przczyna).

  8. Każdą z powyższych uwag, w miarę możliwości zgłaszaj tak, żeby było "na papierze", także po daily napisz z 5 zdań do PM'a "Ej słuchaj, po raz kolejny zgłaszam, że to to i to jest do poprawy".

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

Moje doświadczenia wskazują, na to że możesz mieć troszkę słabą samoocenę. Jesłi wiesz na 100% że ktoś robi coś źle zgłaszaj to. Ja raz trafiłem do firmy, gdzie miałem już jakąs tam wiedzę, od razu postanowiłem się nie szczypać, a że robię to po ludzku (tzn kulturalnie) to bardzo szybko dostałem podwyżkę, a starsi stażem pogramiści pytają mnie często o moje zdanie, zwracają uwagę na moje uwagi przy PR i stosują się do porad.
Tak więc, nie bój się mówić prawdy.

13
justadev napisał(a):

Mimo zapewnień, okazuje się, że kod w projekcie jest trochę na odwal się - trochę trzyma standardy ale w większości nie i jest generalnie absolutnie nie tak, jakbyście to sami napisali.

Żaden projekt nie jest taki jak bym sam napisał. Nawet ten, który sam napisałem jakiś czas temu.

Firma dobrze płaci, ale boli was to, że musicie się dostosować do tego syfu - całego teamu nie przegadacie, a szczególnie nie jako nowi.

Ale jesteś przekonany o wyższości swoich przekonań nad resztą świata? Masz na to mocne dowody. Znasz historie tego projektu?

Jak sobie z tym poradzić? Jak schować do kieszeni ten wewnętrzny głos, który mówi wam, że ten kod to syf i zamiast tego skupić się po prostu na robieniu i dostawaniu za to pieniędzy?

Zawsze możesz po godzinach w ramach rozrywki przepisać ten projekt tak, żeby był po twojemu. Możesz też iść do psychologa. Albo robić swoje od 8-16 najlepiej jak, umiesz i nie przejmować się rzeczami, które nie są zależne od ciebie.

2

Ja od siebie dorzucę prowadzenie notatek z komentarzem do danej funkcji/kodu/rozwiązania. Jeżeli się uchował ktoś dłuższy stażem w firmie, to taka krótka rozmowa wokół danego zagadnienia i jego rozwiązania pozwala czasami na wyrozumiałość, czasami po prostu zrozumieć dlaczego ktoś tak wtedy zrobił, a czasami we dwóch/dwoje pośmiejecie się z tego kodu lub wspólnie złapiecie się za głowę.

Czasami jak coś dotyczy ogólnych biznesowych spraw wokół kodu, to chętnie dzielę się nimi z nowymi osobami, które są wprowadzane do projektu. Mają już jakiś komfort i wtedy pytają już z prośbą o ewentualne doprecyzowanie, rozwinięcie.

2
axelbest napisał(a):
  1. Zawsze programuj wg zasady skauta.

  2. Regularnie proś o podwyżki.

  3. Regularnie na standupach o ile takowe macie, mów, że to, to i tamto jest źle zrobione.

  4. Pokaż wszystkim, że dobry kod sam sie obroni - pisząc takowy.

  5. Wskazuj na Code Review u innych miejsca gdzie popełniają błędy.

  6. Regularnie przypominaj o długu technologicznym

  7. W razie przedłużającego się czasu na dowiezienie czegoś, zwalaj winę na kiepską jakość kodu (o ile to faktyczna przczyna).

  8. Każdą z powyższych uwag, w miarę możliwości zgłaszaj tak, żeby było "na papierze", także po daily napisz z 5 zdań do PM'a "Ej słuchaj, po raz kolejny zgłaszam, że to to i to jest do poprawy".

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

Moje doświadczenia wskazują, na to że możesz mieć troszkę słabą samoocenę. Jesłi wiesz na 100% że ktoś robi coś źle zgłaszaj to. Ja raz trafiłem do firmy, gdzie miałem już jakąs tam wiedzę, od razu postanowiłem się nie szczypać, a że robię to po ludzku (tzn kulturalnie) to bardzo szybko dostałem podwyżkę, a starsi stażem pogramiści pytają mnie często o moje zdanie, zwracają uwagę na moje uwagi przy PR i stosują się do porad.
Tak więc, nie bój się mówić prawdy.

@axelbest Punkty 3, 6, 8 moim zdaniem świadczą o braku doświadczenia, pamiętaj, że programista ma rozwiązywać problemy zespołu a nie dokładać nowe bez samodzielnej próby ich rozwiązania. To tak jakbyś przypominał domownikom o wyniesieniu śmieci zamiast je po prostu wynieść samodzielnie.

@justadev Skąd pewność, że ich rozwiązania są złe a Twoje dobre? Czy jest czas na przepisanie całego projektu na Twoje rozwiązania? Czy te rozwiązania które proponujesz nie staną się "złymi " za rok czy dwa?

Ogólnie polecam ksiązkę https://helion.pl/ksiazki/pra[...]-feathers,prazav.htm#format/d - może po przeczytaniu rozwieje kilka Twoich wątpliwości.

7

Jak sobie z tym poradzić? Jak schować do kieszeni ten wewnętrzny głos, który mówi wam, że ten kod to syf i zamiast tego skupić się po prostu na robieniu i dostawaniu za to pieniędzy?

Ale dla czego chcesz go chować jeśli masz ambicje i kompetencje do wprowadzania zmian? Tak jak było wspomniane wyżej stosuj zasadę skauta, sugeruj poprawki podczas review, sugeruj zmiany zespołowi itp. Do tego rób listę rzeczy które uważasz że należy poprawić (oraz propozycje jak to zrobić), i wspominaj je przy każdej nadarzającej się okazji. Sam miałem podobną sytuację kiedy zmieniłem pracę i nawet pisałem o tym na mikroblogu. Jeśli ludzie z którymi pracujesz są chociaż trochę ogarnięci i chcą pracować z lepszym kodem/procesami, to na Twoim przykładzie przekonają się że warto.

7

@Markuz:
napisałeś:

@axelbest Punkty 3, 6, 8 moim zdaniem świadczą o braku doświadczenia, pamiętaj, że programista ma rozwiązywać problemy zespołu a nie dokładać nowe bez samodzielnej próby ich rozwiązania. To tak jakbyś przypominał domownikom o wyniesieniu śmieci zamiast je po prostu wynieść samodzielnie.

no to lece, bo mam tu troszke odmienne zdanie, może to wynika z firm, w których pracowałem, może z tego, że tam gdzie te rady stosowałem sytuacja w kodzie poprawiała się znacznie.

  1. Regularnie na standupach o ile takowe macie, mów, że to, to i tamto jest źle zrobione.

Czyli jak ktoś Ci da zadanie, w którym zobaczysz, ze połowa kodu który masz użyć jest do pupy, to będziesz wolał dłubać przy tym teraz i przy następnych zadaniach czy będziesz wolał zgłosić coś w stylu:
Ej sluchajcie, robilem takie zadanie, musialem uzyc X i Y, z racji tego ze X jest źle napisane, to czy nie mozemy przynajmniej wrzucic do backloga zadania na poprawe tego. Zastrzegam też sobie, że jeśli w przyszlosci wpadnie mi zadanie które będzie dotyczyło X - to najpierw zrobie ten fix z backloga.

  1. Regularnie przypominaj o długu technologicznym

Rozumiem, że będziesz w pełni akceptował np zmienne typu "button25", i w razie potrzeby osoba, która napisała taki kod zawsze i szybko wyjaśni Ci czym jest ten przycisk. Bo to mi wskazuje, że chyba chcesz się uczyć kodu w projekcie na pamięć np majac metody "giveMeSomeInt()..... return "siedem to liczba". Bo to jest dług techniczny i predzej czy później się zemści.

  1. Każdą z powyższych uwag, w miarę możliwości zgłaszaj tak, żeby było "na papierze", także po daily napisz z 5 zdań do PM'a "Ej słuchaj, po raz kolejny zgłaszam, że to to i to jest do poprawy".

Czyli nie zgłaszać nic? Bo ja miałem kilka sytuacji z takim tekstami szefostwa/PM'ow

  1. PM: Wiedziałeś o tym? To czemu nie zgłaszałeś?
  2. Szef: zgłosiłeś to już? Ok, to skoro PM tego nie ogarnął przez miesiąc to czemu mu nie przypomniałeś o tym? Mogłeś mi to zgłosić że PM nie reaguje.

I wisienka na torcie czyli najlepszy dla nas scenariusz:
Szef/PM: Ej czemu to nie działa od dwóch miesięcy? Kto za to odpowiada? Czemu to nie było zgłaszane?
Pracownik: Ty za to odpowiadasz, bo zgłaszałem to 3 razy mailowo, za każdym razem nie dostałem odpowiedzi, albo pisałeś mi że zajmiesz sie tym "w przyszlym tygodniu" / "po urlopie" / [setka innych powodow]
Szef/PM: No tak.... to przepraszam najmocniej.

no chyba że wolisz słownie przekazywać te informacje, to wtedy nie zdziw się, że jakiś szef/pm - powie Ci tak:
Co? Nic mi takiego nie mowiles, ja tego nie pamietam

Odnośnie smieci - spoko, tylko pomyśl, że kontener masz 20km stąd i wyniesienie ich nie zajmie 5 minut. Za ten czas ktoś musi zapłacic, więc nie Ty decydujesz o tym, kto albo kiedy ma je wynieść. A śmieci (o dziwo dobry przykład) z dnia na dzień, będą śmierdzieć coraz bardziej, utrudniając pracę nie tylko Tobie.

9

@Aventus: Dokładnie.
Najbardziej przeciwni takim zmianom są najczęściej osoby, którym już się nie chce rozwijać. Ile razy zwracałem uwagę komuś nawet na jakąś najmniejszą pierdółkę - to Ci ogarnięci mówili spoko, już poprawiam, a Ci mniej ogarnięci mówili "Ale to musi tak zostać, poprawie następnym razem" (no i taka gadka była przy każdym CR).

Różnica między jednymi a drugimi jest taka, że Ci pierwsi już po drugim takim CR nie popełniali taki błędów, a Ci drudzy robili je za każdym razem i jeszcze mieli za złe, że ktoś odważył się zwrócić im uwagę.
Po tym mozna też poznać dobrego deva, bo jeśli np senior obraża się na to, ze mu junior zwrócił na coś uwagę - to mamy słabego seniora.

Mamy też przypadki, gdy ktoś czegoś nie potrafi, boi się przyznać, że nie umie i nie jest skory by poprosić o pomoc - to też błąd, który trzeba wyeliminować.

Oczywiście każdy ma prawo do obrony swojego kodu :) - więc normalne jest, ze czasami zdarzają się odchyły.

9

Mam duże doświadczenie w produkcji kodu o wątpliwej jakości, więc po prostu dostosowuję się do projektu.

4

Firma dobrze płaci, ale boli was to, że musicie się dostosować do tego syfu

A myślisz, że dlaczego programiści dobrze zarabiają?

Ja to widzę tak, że kiepska jakość kodu wraz z innymi czynnikami (np. skomplikowane wymagania biznesowe) to właśnie coś, za co programiści biorą tyle kasy. Ten brudny kod musi tam być, żeby było co naprawiać, refaktorować i żeby programiści byli potrzebni.

Natomiast nikt ci nie broni pisać i otaczać się czystym kodem w swoim wolnym czasie, np. tworząc projekty open source.

Jak sobie z tym poradzić?

Można zmienić pracę, może kod będzie lepszy w innej. Ale kod w żadnej firmie nie będzie idealny, wszędzie będą patologie. Chyba, że to nowy projekt, ale wtedy też zaraz by się pojawiły, sam byś je napisał. Każdy pisze trochę brzydki kod i im więcej osób w projekcie, tym szybciej się zrobi totalny burdel. Później ten burdel jest naprawiany ("zróbmy refaktor", "przepiszmy na nowo"), ale zwykle się to odbywa tak, że są fiksowane jedne patologie, a wdrażane inne. Programowanie komercyjne to zwykle feature-driven development (albo business driven development), więc czysty kod i dobra architektura nie jest najważniejsza.

Poza tym wiele programistów po prostu nie jest w stanie pisać super kodu, bo nie mieli dobrych przykładów, a sami też nie pomyśleli, jak zrobić coś lepiej, a po prostu piszą, jak wszyscy wokół, czyli w najlepszym wypadku średnio dobrze (plus często im się wydaje, że coś jest dobrze napisane, bo np. implementuje jakiś modny wzorzec, a w rzeczywistości można byłoby to zrobić lepiej).

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