Ciekawi mnie, czy ktoś z was pracujący w jakiejś firmie małej lub większej, napisał kiedyś jakiś kod lub jego fragment dość nieudolnie, nieprofesjonalnie, lamersko i pracodawca lub inny ważny gość zbeształ, wyśmiał was? Czy wszystko skończyło się na krótkiej krytyce?
2
25
1
Ja raz zrobilem static Dictionary i zapomnialem o wielowatkowosci. Wyszlo pare miesiecy pozniej.
2
Ja zawsze jesem nie zadowolony ze swojego kodu i często rozmyślam, jak następnym razem zrobić lepiej :P
2
Na praktykach pisałem trochę ohydnego kodu, ale nikt mnie za to nie beształ (ani nikt po mnie tego nie poprawiał). Było tylko zwrócenie uwagi, że można inaczej, no ale to na tym polegają praktyki, żeby praktykanta czegoś nauczyć.
Inna sprawa jest taka, że pracowałem tylko w małych firmach. W pierwszej firmie po paru miesiącach doświadczenia pisałem lepszy kod niż wszyscy obecni (4 osoby ze mną babrały się kodem), w drugiej byłem jedynym programistą, a zdalne projekty pisane dla nas były ohydne. W bieżącej pracy też mam wrażenie, że Ci dookoła mnie są niedoedukowani, bo czasem ktoś pyta o taki banał, że wstyd i dziw, że cokolwiek spod ich palca w ogóle działa.
Aaa, i sorry za narcyzm, ale taka prawda :P
3
Kiedy masz 2h na napisanie czegoś co wymaga 16h to jakość kodu potrafi nieźle ucierpieć. Zdarza się, notorycznie.
9
"Quality is important, but delivery is importanter". Ale tak żeby ktoś mnie zbeształ to nie.
0
Mi kiedyś się zdarzyło gdy miałem mniejsze doświadczenie napisać z rozpędu dwa bloki try-catch jeden po drugim z czego drugi w pętli zamiast umieścić to w jednym trochę większym. Zwrócono mi tylko uwagę jak to zrobić lepiej.
1
Kiedy masz 2h na napisanie czegoś co wymaga 16h to jakość kodu potrafi nieźle ucierpieć. Zdarza się, notorycznie.
W takich sytuacjach nie pisze się złego kodu i byle jak, tylko stawia się sprawę jasno i klarownie, że programowanie wymaga czasu i nie ma zaginania czasoprzestrzeni. Dane operacje wymagają tyle i tyle czasu, bo muszę zrobić to i to i to.
Do tego stosowanie praktyk TDD - koniecznie.
Inaczej nie jest się profesjonalistą tylko zwykłym pachołkiem któremu każdy może narzucić swoją wolę. Pracuję w korpo i czasy jakie mamy na zadaniach są czasami śmiesznie nierealne. Mało mnie to obchodzi, zawsze stawiam na jakość i piszę kod zgodnie ze standardami. Z mojego punktu widzenia taki kod nawet później pisze się szybciej niż ten wyklepany byle jak.
Moim szczęściem jest też to, że moi przełożeni są dosyć kumaci i jeśli wyjaśniam im, że coś z pewnych względów czasu wymaga, to mówią "trudno... zrób to", ewentualnie negocjują jaką część funkcjonalności mogę zdążyć wykonać w danym okresie.
Dla mnie tłumaczenie się, że "Napisałem slaby kod, bo było mało czasu" jest okłamywaniem samego siebie i brakiem profesjonalizmu.
To programista wie jak pisać kod i musi o niego dbać i brać za niego odpowiedzialność. Musisz mieć niezłe jaja skoro bierzesz odpowiedzialność za kod naklepany na szybko i byle jak bo było mało czasu.
2
W takich sytuacjach nie pisze się złego kodu i byle jak, tylko stawia się sprawę jasno i klarownie, że programowanie wymaga czasu i nie ma zaginania czasoprzestrzeni. Dane operacje wymagają tyle i tyle czasu, bo muszę zrobić to i to i to.
Do tego stosowanie praktyk TDD - koniecznie.
Eee... zależy ile płacą ;)
2
mi najczęściej zdarza się pisać "mejna" żeby sobie na szybko coś sprawdzić/zdebugować i taki kod nie dość, że jest bardzo długi to jeszcze ohydny, ale jest tylko po to żeby sobie coś sprawdzić. Zdarza się potem, że jakiś mądrala przez ramię się gapi i "o k*$%# czemu piszesz to w taki sposób ?!" i potem zlatuje się pół zespołu i debatują jak się kod pisze.
No i czasami jest trochę wstydu przez to bo jak się zleci kilka osób bo jeden zacznie głośno narzekać to potem ciężko mówić, że to z założenia nawet "comitowane" nie będzie.
5
Każdy pisze zły czy suboptymalny kod, to normalne i nie da się tego uniknąć. Inna sprawa nie widzę możliwości bym dostał za to opieprz albo kogoś za to opieprzył. Jeśli ktoś widzi błąd lub brzydki kod to powinien poradzić drugiemu jak zrobić to lepiej, ewentualnie samemu poprawić i zasugerować co jest nie tak, ewentualnie polecić materiały, z których można się dowiedzieć, dlaczego coś jest złe, ewentualnie po prostu podyskutować o tym merytorycznie.
Praca to nie jest szkoła, gdzie ktoś na Ciebie krzyczy, że walnąłeś się w równaniu. Tutaj mamy robić dobrą robotę, a sprawianie komuś dyskomfortu psychicznego nie jest sposobem, żeby na przyszłość powstawał kod lepszej jakości.
1
Jasne, czasami sie zdazy ze prowizorka zostanie bo nie ma czasu albo sensu poprawiac (zwlaszcza wszlekie rodzaju toole ktore z zalozenia maja byc jednorazowe). Do tego czesto jest tak ze jak wracasz do kodu po jakims czasie to sobie myslisz: WTF, pomimo ze jak sie to pisalo to wydawalo sie ze jest super i zrobiony w najlepszy mozliwy sposob.
A co do zbesztania, w poczatkach pracy pamietam jak pisalem skrypty shellowe, wystawilem do review i jeden kolega stwierdzil ze nie ma sensu rozipyswac na kilkadziesiat linijek jak mozna zrobic w dwoch (z tym ze musialem pol dnia siedziec by zrozumiec jak te dwie maja dzialac:) )
Albo pierwsze zadanie w pierwszej pracy (mielenie danych na Linuxow ktorego nie znalem wtedy) i nie wzialem pod uwage znakow specjalnych: efekt system zaspamowal uzytkownikow smieciowymi mailami (bo pipe gdzies uciekl).
Z drugiej strony prawda jest taka, ze na takich wtopach sie najlepiej uczy.
9
Inaczej nie jest się profesjonalistą tylko zwykłym pachołkiem któremu każdy może narzucić swoją wolę. Pracuję w korpo i czasy jakie mamy na zadaniach są czasami śmiesznie nierealne. Mało mnie to obchodzi, zawsze stawiam na jakość i piszę kod zgodnie ze standardami. Z mojego punktu widzenia taki kod nawet później pisze się szybciej niż ten wyklepany byle jak.
Profesjonalizm polega m.in. na tym, że widzi się innych poza czubkiem własnego nosa. Kodu nie pisze się dla samego pisania kodu, tylko na końcu zawsze jest klient, którego obchodzi działający produkt. Decyzja, kiedy pójść na skróty, a kiedy pisać zgodnie ze standardami zwykle nie leży w gestii szeregowego programisty - o tym będzie decydować tech-lead / architekt / kierownik lub ktoś starszy w zespole - programista powinien oczywiście wyłożyć wszystkie za i przeciw, ale ostatecznie musi się dostosować, nawet jeśli nie zgadza się z decyzją. Po prostu szeregowy programista często nie zna całego kontekstu sytuacji (np. nie rozmawiał z klientem albo nie zna szczegółów umowy), aby samodzielnie podejmować takie decyzje. Czasem naprawdę korzystniej jest załatać coś na szybko dla klienta, a poprawić dobrze w koejnej wersji, kiedy będzie więcej czasu, niż mówić klientowi, że nie dostanie czegoś, co było obiecane.\
Natomiast co do tego, że kod naklepany byle jak mści się po pewnym czasie, to jest prawda. Dlatego zawsze trzeba przeznaczyć trochę czasu na sprzątanie / refaktoryzację, aby utrzymywać kod w porządku.
Co do oryginalnego pytania, to nie zdarzyło mi się, aby ktoś mnie zbeształ za zły kod, natomiast kiepski kod piszę praktycznie cały czas i ciągle coś poprawiam w strukturze kodu. Tzn. nigdy nie jestem zadowolony z kodu - zawsze wiem, że coś można zrobić lepiej i każdy kod jest jakimś kompromisem wynikającym z konkretnego czasu na wykonanie zadania, wymagań funkcjonalnych i ich priorytetów, przyjętym poziomem jakości kodu / łatwości jego utrzymania / wydajności itp.
Zdarzyło mi się za to, że raz zostałem zbesztany przez jakiegoś programistę z innej firmy (projekt open source), za to, że napisałem własną strukturę danych na coś, co dało się osiągnąć prościej standardowymi strukturami, ale za to dość dużym narzutem pamięciowym / czasowym w porównaniu z moim kodem. Innymi słowy ktoś uznał mój kod za przedwczesną optymalizację. Do tego stwierdził, że "własnych struktur danych nie powinno się pisać, bo trudno to zrobić dobrze i tam na pewno jest błąd". Błędu, który podejrzewał, akurat tam nie było, natomiast błąd znalazł się w znacznie prostszej i można nawet rzec "trywialnej" części projektu.
0
Ja pracuje w korpo, która działa trochę jak firma outsorcingowa. Nie mamy własnego projektu, każdy z nas jest sprzedawany na określony projekt/ liczbę godzin. Przerabiam jednemu klientowi stary brzydki kod. Pierwotna estymacja (nie moja) 2 tyg dala 2 osób (miały być drobne poprawki) . Projekt ciągnie się 9 ty miesiąc i widać powoli koniec. Deadline jest non stop przesuwany bo klient dorzuca nowe rzeczy lub zmienia zdanie. Wydawało mi się że kończę projekt już jakieś 5 razy... :D jednak zawsze jakiś nowy task się pojawiał. Kod pierwotny wygląda jak spaghetti z dużą ilością sosu ale jakoś trzeba żyć.
1
Jakiś czas temu jak zaczynałem pracę i kierownik robił mi przeglądy kodu żeby sprawdzić na ile ogarniam to napisałem tak kosmiczną metodę że kiedy wróciłem do domu i pomyślałem o tym to zrobiło mi się żal... Obiecałem sobie że poprawię to od razu jak pojawię się w pracy... Niestety był to weekend i cały czas siedziałem jak na jajku modląc się żeby nikt tego nie dojrzał. Oczywiście w pon rano zmieniłem, nikt nie dojrzał a moduł i tak pare dni później został usunięty ;).
0
Krolik napisał(a):
Profesjonalizm polega m.in. na tym, że widzi się innych poza czubkiem własnego nosa. Kodu nie pisze się dla samego pisania kodu, tylko na końcu zawsze jest klient, którego obchodzi działający produkt. Decyzja, kiedy pójść na skróty, a kiedy pisać zgodnie ze standardami zwykle nie leży w gestii szeregowego programisty - o tym będzie decydować tech-lead / architekt / kierownik lub ktoś starszy w zespole - programista powinien oczywiście wyłożyć wszystkie za i przeciw, ale ostatecznie musi się dostosować, nawet jeśli nie zgadza się z decyzją.
To się wszystko i tak rozbija o koszty i potrzebny czas na realizację projektu, niemniej jednak współczuję każdemu kto musi pracować ze spaghetti code bo mu ci wyżej tak każą. Problem polega na tym, że już samo zapoznanie się z kodem pisanym przez kogoś wcześniej, o ile to spaghetti code to może być poważny problem. Kiedyś dla przykładu rozgryzienie co się tak naprawdę dzieje w jakimś kodzie zajęło mi ok. miesiąca, właśnie ze względu na trudny do zrozumienia kod a była to stosunkowo prosta (mało linii kodu) aplikacja desktopowa. Miałem również do czynienia z kodem w dobrej jakości (nazewnictwo, utrzymane standardy) i od groma linii kodu i tu pod względem rozgryzienia tego co się dzieje było o niebo lepiej.
0
W dyskusji widzę kilka wątków.
(1)
Jeśli by spojrzeć na to z punktu widzenia "własnego ogródka", cały czas piszę zły kod :-/ Problem leży jednak w definicji "dobry/zły". Przecież są 2 rodzaje jakości. To co ocenia klient (tzw. duże Q) i to co ocenia zespół wykonawczy/programiści/testerzy/zespół QA/... (małe q).
Jest tak i będzie że małe q będzie poświęcane na rzecz dużego Q. Projekt ma być przyjęty przez klienta w jego kryteriach jakości. Dlatego czasem rezygnuje się z aspektów polepszających jakość wewnętrzną kodu (q) na rzecz dotrzymania terminów, budżetu, zaspokojenia potrzeb, obsługi ryzyk itp... Tak jest i tak będzie. Analogia do produkcji przemysłowej. Możesz kupić coś co jest zrobione tanio, bez projektu lub coś co ma projekt, wsparcie techniczne, serwis itd.
Dlatego przy estymowaniu czasu, zawsze zadaję pytania dotyczące jakości tego co ma powstać. Inaczej piszę prototyp (w innym języku programowania) a inaczej część produkcyjną. Tu niedbałość (i zabijanie małego q) także się mści w postaci długu technologicznego.
(2)
A co do własnego podwórka. Wiadomo że po kilku latach, jeśli się rozwijasz, napiszesz kod do określonych zadań lepszy, bardziej zmodularyzowany i bez błędów które popełniasz teraz (a nawet o nich nie wiesz). Stąd sam szukam różnorodnych rozwiązań aby mieć "w skrzynce narzędziowej" coś do wyboru na większość okazji i przy adekwatnych kosztach, czasie, jakości, łatwości znajdowania błędów. Wg. mojej oceny, to zawsze będzie kompromis "co się da zrobić" przy narzuconych ograniczeniach.
(3)
Problem informacji zwrotnej... Eh.. Jak ktoś mówi że kod "to stek bzdur i bezsens" a później nic więcej nie dodaje oprócz epitetów o pochodzeniu, wielkości elementu między uszami itp. (oczywiście celowo przejaskrawiłem), to nie ma się do czego odnieść. Jeśli są merytoryczne uwagi, poprawne przykłady, odniesienia do poprawnych lub nie konstrukcji, konsekwencje stosowanych rozwiązań, to tylko dziękować jakkolwiek by to "nie bolała programistyczna duma". Z moich doświadczeń wynika że nie ma programisty który zawsze, w każdych warunkach, na każdej platformie i z każdym narzędziem pisze bezbłędny kod. Stąd sam staram się informację zwrotną dawać jak najbardziej merytoryczną bez zarzucania "brudną watą" :-)
0
A czy zdarza się Wam czasem długo zastanawiać nad rzeczami w zasadzie banalnymi?
Jestem początkujący i czasem wpadam w zły sposób myślenia, z którego nie zawsze łatwo wyjść.
A gdy poproszę kogoś by spojrzał na to co robię i podpowie co zrobić to mam gigantyczne "wtf".
1
A gdy poproszę kogoś by spojrzał na to co robię i podpowie co zrobić to mam gigantyczne "wtf".
jeszcze nie tak źle. ja czasami mam problem z przekaniem tego co mam na myśli i to ta druga osoba ma gigantyczne "wtf" ;)
A czy zdarza się Wam czasem długo zastanawiać nad rzeczami w zasadzie banalnymi?
każdemu chyba się tak zdarza.
Jestem początkujący i czasem wpadam w zły sposób myślenia, z którego nie zawsze łatwo wyjść.
no ale lepiej wychodzić i próbować wielu rzeczy, aż w końcu natrafić na dobry niż się całkiem zaplątać i napisać spaghetti code:
https://twitter.com/mariofusco/status/591350093351116800
0
to byl bardzo stresujacy poranek dla kolegow z boksu obok (market data team). goscie dosc niezle panikowali, krzyczeli jeden na drugiego, co chwile odzywaly sie telefony itp. wycena pozostalej do przetworzenia wartosci portfolio skladajacego sie z kilkuset instrumentow w roznych walutach oscylowala miedzy 0 a jakimis kosmicznymi wartosciami blisko zakresu long'a, naturalnie wplywajac na wysylanie nowych zlecen do gield. po jakims tam czasie, gdy okazalo sie ze dane rynkowe sa ok, wrzawa przeniosla sie na nasz zespol. zaczelismy przegladac kod, w module odpowiedzialnym za kalkulacje dokopalam sie do metody odpowiedzialnej za przeliczenia walutowe, kilkadziesiat linijek, wiekszosc operacji na zmiennych o nastepujacych nazwach:
currency1 - waluta instrumentu
currency2 - waluta zlecenia
currency3 - waluta portfolio
currency4 - waluta bazowa (wybierana przez usera)
dostalam polecenie poprawienia tego i wyjasnienia jak to sie stalo ze to weszlo na produkcje. naturalnie zaczelam wyzywac co za idiota to napisal, co za idiota robil review itp.
biorac pod uwage temat watku latwo sie domyslic kto napisal ten kod. blame wykazal tez ze review robil moj szef wiec obeszlo sie bez wiekszej afery.
ostatecznie problem lezal w braku wsparcia dla nowej waluty (CAD), jednak niesmak pozostal :)
czesto jak przegladam swoj kod sprzed jakiegos tam okresu czasu to dostaje rumiencow ;)
0
LukeJL napisał(a):
A gdy poproszę kogoś by spojrzał na to co robię i podpowie co zrobić to mam gigantyczne "wtf".
jeszcze nie tak źle. ja czasami mam problem z przekaniem tego co mam na myśli i to ta druga osoba ma gigantyczne "wtf" ;)
A czy zdarza się Wam czasem długo zastanawiać nad rzeczami w zasadzie banalnymi?
każdemu chyba się tak zdarza.
Jestem początkujący i czasem wpadam w zły sposób myślenia, z którego nie zawsze łatwo wyjść.
no ale lepiej wychodzić i próbować wielu rzeczy, aż w końcu natrafić na dobry niż się całkiem zaplątać i napisać spaghetti code:
https://twitter.com/mariofusco/status/591350093351116800
Ostatnio wygłupiłem sie mając problem z banalnym foreach, if statement i paroma listmai, chciałem sprawić by wszystko przechodziło nawet jak bedzie nullem, ze stresu, że to tak banalne, nie byłem w stanie tego zrobic w krótkim czasie... po podpowiedzi przyjąłem strasznego /facepalma...