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?

17
  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.
  1. Regularnie proś o podwyżki.

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

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

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

  5. Regularnie przypominaj o długu technologicznym

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

  7. 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".

  8. 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/praca-z-zastanym-kodem-najlepsze-techniki-michael-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

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.

14

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ą.

3
twoj_stary_pijany napisał(a):

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?

Ja tu nie widzę warunków tylko mapę/słownik

0

Program 2, gdzie tutaj jest złamanie SRP?

def run_workflow(*args, **kwargs) -> None:
    process-resources(*args, **kwargs)
    compile(*args, **kwargs)
    process-test-resources(*args, **kwargs)
    test-compile(*args, **kwargs)
    test(*args, **kwargs)
    # dodajmy jeszcze do wszystkich tych akcji pre i post albo wymyślmy najróżniejsze akcje
    package(*args, **kwargs)
    install(*args, **kwargs)
    deploy(*args, **kwargs)
4

powalczę ale jak widzę brak reakcji, ciągnące się spotkania z podniesionym głosem "bo heh jakieś ut czy code guidlense są nam nie potrzebne hehe jestem team ledem" to daje sobie spokój. Posiedzę dopóki pensja mi odpowiada a później gdzie indziej. Czasami walka z złymi nawykami nie ma sensu bo się nie da z powodu oporu materii żywej.

2

Podcieram lzy zlotowkami i mowie sobie, ze dlatego tyle placa bo potrzebuja kogos zeby walczyl z tym syfem.

7

Jedna sprawa to czy kod jest kiepski czy nie (przy czym to nigdy nie jest binarne), natomiast druga to umiejetność argumentowania i przekonywania. Jednak w codziennej pracy ważne są również relacje. Na temat danego kawałka kodu, w jaki sposób go ulepszyć (i czy w ogóle warto to robić!) można dywagować godzinami (co w wielu przypadkach jest czasem straconym)

I teraz - IMO lepiej dla pracy zespołowej (a wiec w dłuższej perspektywie i dla wyników zespołu), aby ludzie zgodzili się co do kodu good enough średniej jakości (roboczo 3+/4 w skali szkolnej) niż jeden hero developer ma forsować rozwiązanie, które nawet obiektywnie jest najlepsze, ale nikt inny się pod nim nie podpisuje.

Można nawet pójść bardziej kontrowersyjnie - czysty kod zabija radość z pracy i efektywność zespołu :) Clean code considered harmful.

3
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.

To czy kod jest słaby czy absolutnie nie taki jaki sam bym napisał to dwa różne od siebie stany

jarekr000000 napisał(a):

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 punkt.
Jak dla mnie w projekcie może być kupa, do tego można się przyzwyczaić w czasie zdobywania doświadczenia. Ważne jest natomiast nastawienie zespołu. Jeśli jest jakieś parcie na poprawianie syfu (choćby małe) to nawet da się przyjemnie pracować. Szczególnie jeśli w jakimś czasie uda się ten projekt wyciągnąć ze stanu urągającemu godności do jako-takiego albo i lepiej.
Jeśli jednak każą pisać kiepski to uciekaj jak najdalej. Chyba, że płacą wyjątkowo dobrze a sam nie będziesz czuł do siebie obrzydzenia.

3

Można nawet pójść bardziej kontrowersyjnie - czysty kod zabija radość z pracy i efektywność zespołu :)

A niby w jaki sposób to pierwsze? Bo drugie w pewnym sensie jestem w stanie zrozumieć. O ile jakiś uber fanatyzm jest zły, to o tyle dbanie o jakość kodu w granicach rozsądku jest praktycznie zawsze sensonsowna. Dla przykładu, nikt nie spiera się o to czy 3 czy 4 zależnosci w jakimś serwisie biznesowym to za dużo tylko częściej jest czepianie się o 20...

3

Nie do końca widzę problem. Praca jest od zarabiania pieniędzy a nie zbawiania świata. Jeśli płacą dobrze i na czas to reszta mnie nie interesuje. Świat można zbawiać po godzinach pisząc swój kod "tak jak Pan Jezus powiedział".

2

Świat można zbawiać po godzinach pisząc swój kod "tak jak Pan Jezus powiedział".

Po kij mam pisać dobry kod po pracy jak moge w pracy? Co mam klepać kod 12 godzin na dobe? xD

Nie do końca widzę problem. Praca jest od zarabiania pieniędzy a nie zbawiania świata. Jeśli płacą dobrze i na czas to reszta mnie nie interesuje.

Dobra - to co jeśli będziesz miał bug produkcyjny i będzie ciśnięcie na już a Ty masz totalnie chjowy kod i nie wiesz jak to naprawić? Czy wtedy te zbawianie świata wczesniej nie ułatwiłoby Ci zwyczajnie życia?

4

Jeśli płacą dobrze i na czas to reszta mnie nie interesuje.

@ledi12: nie zgodzę się. I nie chodzi o zbawianie świata i ratowanie firmy poprzez czyszczenie kodu na przepiękny. Chodzi raczej o komfort pracy.

Tak samo jak budowlaniec powinien mieć porządne narzędzia i strój, tak i u programisty są potrzebne jakieś zasady BHP. I nie chodzi tylko o dobrego kompa, ale też o jakoś tego, nad czym ma siedzieć. O wiele lepiej się pracuje na kodzie, który jest po prostu dobry. Zmiany trwają o wiele krócej, trudniej popełnić błąd, mniej człowiek się męczy dodając nowe funkcje itp.

Więc o ile masz rację, że nie ma co robić misji ratowania świata i nawracania wszystkich na piękny sposób pisania, to jednak to, nad czym pracujesz powinno Cię interesować.

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