Czy zdarza wam się wrzucić w repo wulgaryzmy?

3

Pytam, bo jestem świeżo po rozmowie z przełożonym. Okazało się, że zacommitowałem do repo klienta print "ku*a"; :D
To mój pierwszy taki przypadek w ciągu moich 5 lat pracy, a jak wiadomo pierwsze razy są najgorsze i teraz siedzę i palę się ze wstydu, ale jednocześnie jestem ciekaw czy wam też się takie coś zdarza/zdarzyło? Jeśli tak to jak często?
Wiadomo - nie powinno się robić rzeczy, które mogą nam przynieść wstyd, ale mylić się i być sfrustrowanym po 3 godzinach nieskutecznego debugowania jest rzeczą ludzką i każdemu może się zdarzyć. Mam nadzieje, że klient i przełożony szybko o tym zapomną :D

0

Czasem się zdarzało (po czasie jest się z czego pośmiać) ale to i tak zależy od podejścia klienta i przełożonych.
Jeden się zaśmieje a inny zrobi akcję jakby się świat kończył.
Sam miałem sytuację kiedy, testowałem świeżo postawione WebApi i jako respond dostałem komunikat "ch*j ci w d**e, ssij mój socket" XD, bo zapomnieliśmy to poprawić przed deploy-em :D
Niby nic wielkiego, ale byłem wtedy zsharowany z klientem :D po minucie konsternacji z mojej i klienta strony on wybuchł śmiechem.
Z tym klientem akurat wyszliśmy na plus, bo szybko zamówił u nas kolejne aplikacje (stwierdził, że równe z nas chłopaki :D).

6

nie używam dup w kodzie komercyjnym, więc nie grozi mi ich zakomitowanie

1

Dziwnie mi udzielać porad dla @_cwel bo i sam nick jak i problem jest troszkę trollingiem. Mimo wszystko commita da się nadpisac. Można też wrzucić fixa jako odrebny commit.

1

nie raz się zdarzyło, w jednej firmie dla której robiłem nawet sam właściciel mi opowiadał jak to jeden gość zrobił sporo alertów "dupa-debuggingu" no i poszło to na proda także userzy mieli alerty typu "dupa 2" :D

2

Kiedyś pracowałem w firmie w której kolega przepchał dupę do raportu generowanego raz na dobę i widocznego w aplikacji. Prezes osobiście musiał jechać do Klienta i przepraszać za sytuację.

Samemu nawet nigdy nie wpadłem na pomysł żeby wpisywać takie coś podczas debugu, jeśli już to jakieś 'testX' czy inny nieszkodliwy ciąg znaków.

1

Mi się czasem zdarzyło, i szczerze mówiąc, nie widzę w tym nic złego. "d*pa" gdzieś w UI w aplikacji, że klient to widzi, to jest mega słabe - albo gdzieś w logach, w danych. Ale jeśli jest tylko w repo, w kodzie źródłowym i nie wyjdzie "na swiat" to moim zdaniem to nie jest nic strasznego.

Lepsze to niż wrzucić zmienną globalną.

3

A żeby to raz. H^je, ci^py, XD to standard podczas debugowania :D

screenshot-20230623122417.png

1

Ostatnio wrzucałem cały plik konfiguracyjny z setkami przekleństw - No ale to na potrzeby taska. Niemniej satysfakcja była, że można bez problemu wrzucić zmiany a nawet dopisałem kilka swoich :D A tak to nigdy d**y w debugowaniu, zawsze jakieś foo,boo,zoo,doo

1

Nie wiem czy tutaj juz o tym wspominal, ale mozesz sobie zrobic git hooka, ktory wylapie keywordy :)

0

Kiedyś kolega mi wyłapał console.log('dupa') na CR.

I tak większość klientów nie wie, co to znaczy, więc 🤷🏻‍♂️

0

Nigdy. Nie używam takich słów do debugowania, jeśli już to zwykłe test, czy inne losowe ciągi znaków.

0

Rożne rzeczy widziałem w priv repo i w open source. Kiedyś była dupa w kodzie ScyllaDB (nie mam czasu robić teraz searcha przez całą historię, niech ktoś!).

Jeden hindus z którym pracowałem zawsze walił na początku każdego pliku który stworzył ASCII grafikę wychwalającą wielkość jego członka ego. Nie dało się przetłumaczyć, proceder skończył się gdy gość odszedł po kilku latach...

Generalnie code review ucieło tego typu śmieszki i hihi... Ale w czasie testów nadal się zdarza. Kiedyś na staging narobiłem Dup i ujów, na moje nieszczęście w tym samym czasie marketing robił zrzuty ekranu z przykładowego projektu - który o dziwo okazał się być naszym testowym projektem - na szczęście marketingowiec był na tyle ogarnięty żeby zapixelować :D

A teraz praktyczna rada: napisz sobie w Git commit hook'a który będzie blokował wszystkie polskie wulgaryzmy.
Tutaj jest przykład: https://gist.github.com/skwashd/8732878

I będzie po sprawie...

1

Wulgaryzmy nie, ale zdarza mi się w testach używać nazwisk celebrytów np. Assert.Equal("Bartosz Walaszek", result.FullName);

1

Jak dupa-debuguję (określam tak wszelkie prymitywne rozwiązania typu var_dump czy console.log), to raczej wpisuję trudne do wymówienia polskie słowa - gdybym coś spushował nie takiego to będą to "kłaczki" np., a że jestem jedynym Polakiem w zespole, to i tak nikt nie ogarnie.

Ale generalnie robię review swojego własnego kodu przed spushowaniem, już nawet nie przez d**y, tylko czy nie zrobiłem sobie jakiegoś "mocka", typu wyłączyłem sprawdzanie czegoś czy jakieś operacje ifem, żeby przyspieszyć weryfikację źle działającego fragmentu dłuższego flow.

Ale pamiętam jak dawno temu znalazłem w jakimś CMS robionym przez znajomego szwagra kolegi bratanka globalną sól do haseł, coś w stylu: jeb**iewp**dędupacyckich*j111!!!

3

Jak robię dupa debugging to zawsze stosuję do tego numer linii kodu.

echo 'linia:' . __LINE__;

Natomiast w jednym projekcie było sprawdzenie wszelkich wulgaryzmów na pipleine po tym jak ktoś skutecznie kilka razy wypchnął console.log('dupa') na proda.

0

@jurek1980: takie coś niewiele mówi co się wydarzyło, jak nazywam coś dupami to wiem która dupa odpowiada za jaki efekt

6

Jeżeli ktoś wrzuca przypadkiem wulgaryzmy do repo, to bardzo źle to świadczy, bo:

  1. nawet nie przegląda tego co robi zanim commitnie/pushnie
  2. nikt nie robi review? a nawet jeżeli robi, to tego nie zauważył? no lipa w obu przypadkach.
0

Raz mi się zdarzyło wypchnąć wulgaryzm podyktowany desperacją, ale na szczęście został wyłapany na CR. Przynajmniej jest się z czego pośmiać.

1

Nie wiem po co printować coś, co nie niesie ze sobą żadnej informacji, więc też tego nie wrzucę do repo.

2
somekind napisał(a):

Nie wiem po co printować coś, co nie niesie ze sobą żadnej informacji, więc też tego nie wrzucę do repo.

Czasem używając jakichś frameworków które robią magie i dopiero w runtime się dowiadujesz czy coś się odpali czy może nie spełnia jakiegoś wymogu i printujesz żeby wiedzieć czy w ogóle kod został odpalony.
Albo debugując kod wielowątkowy gdzie wszystkie wątki muszą iść razem i nie możesz po prostu postawić breakpointa. Można wyklikać żeby breakpoint się odpalił warunkowo albo żeby wypisał coś na konsoli, albo dowiedzieć się ile razy się metoda odpala w profilerze zamiast w konsoli i ogólnie użyć narzędzi do tego przeznaczonych ale to zajmie kilkadziesiąt sekund a nawet kilka minut a "print(dupa)" zajmuje 2 sekundy.
Serio nigdy nie wstawiłeś tymczasowego debug.print nigdzie do kodu?

Ja się sparzyłem jeszcze w podstawówce gdzie pisaliśmy na informatyce jakieś stronki w HTML/JS na IE6 i nazwę funkcji do poruszania elementem nazwałem dla żartu "ruchaj" a nauczyciel mi to wytknął z politowaniem na twarzy. Od tamtej pory w kodzie nie piszę niczego przez co bym się wstydził gdybym zapomniał tego usunąć.

0

Dupa debugging raczej nie stosuję, praktycznie zawsze staram się zawrzeć we wiadomości jakieś minimum przydatnej treści, typu starting thingX, thingX done albo chociażby numer linii w pliku źródłowym.

Zdarzyło mnie się wrzucić w repo wulgaryzmy w komentarzach do kodu, gdy musiałem pisać jakieś akrobatyczne workaroundy na błędy w bibliotekach czy inszych API, których używaliśmy.

1
obscurity napisał(a):
somekind napisał(a):

Nie wiem po co printować coś, co nie niesie ze sobą żadnej informacji, więc też tego nie wrzucę do repo.

Czasem używając jakichś frameworków które robią magie i dopiero w runtime się dowiadujesz czy coś się odpali czy może nie spełnia jakiegoś wymogu i printujesz żeby wiedzieć czy w ogóle kod został odpalony.
Albo debugując kod wielowątkowy gdzie wszystkie wątki muszą iść razem i nie możesz po prostu postawić breakpointa. Można wyklikać żeby breakpoint się odpalił warunkowo albo żeby wypisał coś na konsoli, albo dowiedzieć się ile razy się metoda odpala w profilerze zamiast w konsoli i ogólnie użyć narzędzi do tego przeznaczonych ale to zajmie kilkadziesiąt sekund a nawet kilka minut a "print(dupa)" zajmuje 2 sekundy.
Serio nigdy nie wstawiłeś tymczasowego debug.print nigdzie do kodu?

Wiele razy. Ale zawsze coś sensownego, dającego informację o kontekście, nigdy dup czy innych wulgaryzmów.

3
_cwel napisał(a):

Pytam, bo jestem świeżo po rozmowie z przełożonym. Okazało się, że zacommitowałem do repo klienta print "ku*a"; :D
To mój pierwszy taki przypadek w ciągu moich 5 lat pracy, a jak wiadomo pierwsze razy są najgorsze i teraz siedzę i palę się ze wstydu, ale jednocześnie jestem ciekaw czy wam też się takie coś zdarza/zdarzyło? Jeśli tak to jak często?

Nie zdarza mi się, bo jak już to printuję jakieś "AAAA", "BBBB" czy "Ala ma kota"

0

Kiedyś na projekcie spotkałem się ze stałą, którą ktoś nazwał "TOO_OLD_TO_BE_ALIVE" zamiast np "MAX_AGE" i zostało to ciepło przyjęte i z tego co wiem nie zmieniło się do teraz :D

0

nie, mam kilka stringow testowych ktore zazwyczaj uzywam, nawet gdyby sie wymknely to sa neutralne, a w razie W szybko poznam ze to moje.

2

Pisząc pracę inżynierską dałem promotorowi wersję w której zapomniałem wyłączyć d**y. No i leciały ładne komunikaty: "tworzę d**y", "dupa1", "dupa2"
Pisałem aplikację dla jednego urzędu. Wysyłając im wersję beta zapomniałem wyłączyć wyświetlanie pewnych okien dialogowych. No i potem dostałem maila z zapytaniem co to za wyskakujące okna z komunikatem "i się wyjebało"

0

a zdarza się wam

int cunt = 0;
 ... 
cunt ++;

We współczesnych IDE to łatwe, tylko jedna literka różnicy

0

Dla mnie to nieprofesjonalne.
Mogę napisać sto innych rzeczy to po co mam pisać akurat wulgaryzmy.
Pokląć sobie mogę, ale nie muszę tego wrzucać do kodu i ryzykować zacommitowania.
Kolega mi kiedyś opowiedział historię z pracy w wiodącym polskim portalu internetowym, kiedy "udało mu się" pewne niecenzuralne słowo wyświetlić na prodzie (nie na głównej stronie).
Podobno myślał, że robi to na środowisku testowym, na szczęście dla niego zorientował się po jakiejś minucie i żadnych konsekwencji nie było.
To było wiele lat temu, więc mechanizmy code review w obecnym rozumieniu jeszcze nie funkcjonowały.
Jak stwierdził nauczyło go to, żeby nigdy więcej nie pisać takich rzeczy w kodzie.

1

Mnie to zastanawia jaki to ma sens logiczny.

Dobra program się wywali widzimy stacktrace i wiemy, że coś na tej linijce kodu w tej funkcji się wywaliło.
Czyli randomowe print już nie są potrzebne.

Teraz żeby zrozumieć co poszło nie tak to przed tym wywaleniem, to powinno się wyświetlić jaki był stan zmiennych, czyli albo breakpoint albo jakieś printy z kluczowymi zmiennymi.

Wpisywanie jakiś śmieciowych danych w print to trochę śmierdzi jakąś głupotą, która nic nie rozwiązuje?

Albo jeszcze lepiej zacznijcie testy pisać, a nie że wszyscy deklarują jak to nie testują kodu profesjonalnie, a potem anyway wpiszę print żeby sprawdzić czy te któreś z tych funkcji się nie wykonała, a potem w następnym poście na forum opisują jak to testowanie jest ważne w projektach i jak bez tdd nie da się żyć, a potem kod nie testowalny testują printem czy się wykonuje <facepalm>

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