•  

    pokaż komentarz

    Dla mnie najgorszym antypaternem jest "for future use" czy "to be future-proof". Ewentualnie spekulatywna generyczność,czyli zakładanie potrzeby generyczności ("for future") w obszarach które tego nie potrzebują.

    •  

      pokaż komentarz

      @PDCCH: to chyba tylko jeden projekt masz za soba i nie widziałeś do czego zdesperowany nienachalnie intelektualny programista jest zdolny

    •  

      pokaż komentarz

      to chyba tylko jeden projekt masz za soba

      @polska_partia_programistow: Aktualnei jakieś 20 lat w branży. 10 lat aktywnego kodowania, ostatnie 10 bardziej "ogarnianie"

    •  

      pokaż komentarz

      @PDCCH: najgorszy antypatern to jest budowanie czegoś bez "future use", czyli kawał gównianego kodu którego nie da się nijak rozszerzyć bez szambonurka, potem szybciej jest przepisać cały moduł niż go przerabiać i kręcić się w kółko naprawiając bugi które tam wybuchają bo się czegoś dotknęło

      najlepsze jest oczywiście rozpoznanie takiego kodu, które często następuje w momencie kiedy już stracono masę czasu na próby przeróbek i quick fixów :D bo przecież nikt nie przepisze całości ot tak bo mu się kod nie podoba

    •  

      pokaż komentarz

      potem szybciej jest przepisać cały moduł niż go przerabiać i kręcić się w kółko naprawiając bugi które tam wybuchają bo się czegoś dotknęło

      @Ligniperdus: Takich też uwielbiam. Krzyczą "Przepisać to wszystko! jakie to jest zj!$!aane! Nie bede w tym grzebau!" No i przepisują. Specy-fikcji zwykle nie ma lub nie jest ona zbyt aktualna, więc przepisywacz przepisuje według tego co mu się wydaje. Z resztą, nawet gdyby była i ze złota ta specyfikacja, to przepisywacz nie będzie zawracał sobie głowy zrozumieniem tego jak to ma działać. Przepisywacz interesuje się tylko co tam w najnowszym standardzie C++ dodali i zastanawia się jak to zrobić aby koniecznie tego użyć w tym co przepisuje, aby udowodnić swoją zajebistość. Nie będzie przecież zawracał sobie głowy zrozumieniem działania systemu, on tu przecież jest programistą nie mus rozumieć jak to wszystko dziala. No i przepisał. Faktycznie, ładne to, lepsze na pierwszy rzut oka od tego starego, nawet testy jakieś się pojawiły. Jest postęp.
      No i potem taki kawałek po zintegrowaniu z resztą systemu trafia na testy. Testy już całego systemu. No i zaczyna się, bład na błedzie. Tu jakiś przypadek nieobsłużony, tam się wysypuje w innym corner case itp. Przepisywacz z początku trochę nie dowierza ale po rzuceniu paru bojowych okrzyków naprawia, z nieco już mniejszym entuzjazmem. Czas mija, kolejne dedlajny padają niczym choinki w młodniku pod wojskowym starem 266. W końcu jest. Trochę nadgodzin i weekendów dalej, kilkaset litrów kawy przekształconej w mocz i kod i wygląda na to ze jest Testownia stwierdza że już może być, menedżment oddycha z ulgą, świat uratowany. Tylko że ten piękny, nowoczesny i błyszczący i - co najważniejsze - przepisany komponent wygląda jak produkt metabolizmu ssaka naczelnego. Pierwotny piękny design po doimplementowaniu "na szybkości" tego co zostało pominięte na początku tonie w gównie. Znowu mamy kulkę gówna. No ale teraz jest to nasze, własne, lepsze, bo przepisane. I jakie nowoczesne, użyliśmy wszystkich nowości które się w standardzie pojawiły.
      (tak to trochę w stylu pasty napisałem obserwując mniej lub bardziej z boku poczynania ambitnych kolegów "przepisywaczy")

    •  

      pokaż komentarz

      @polska_partia_programistow: Zajebiste to jest. Nie wiedziałem że wyróżniono ich aż tyle ;)

    •  

      pokaż komentarz

      @PDCCH: bo tak samo jak nie jest sztuką napisać gówno, tak samo nie jest sztuką przepisać coś tylko dla przepisania
      cała sprawa żeby przepisać z pojęciem co się robi

      jeżeli masz tylko złe doświadczenia to szkoda, może kiedyś trafisz na kogoś kto ogarnia

    •  

      pokaż komentarz

      @PDCCH wiesz, z jednej strony "premature optimalization...", z drugiej ja się właśnie męczę z projektem który sobie ktoś wymyślił że przepisze bo starej wersji się nie da rozwijać (co jest akurat prawdą). Tak jak mówisz, dokumentacji nie ma i trzeba robić na wyczucie, ale wszystko jest w miarę logiczne. Problem taki, że wcześniejsi deweloperzy podchodzili do tematu właśnie na zasadzie "zrobię to co teraz muszę i nic ponad to", przez co mam teraz masakryczny problem w naprawie tego projektu bo jedna poprawka to zmiana 10 klas i 4 widoków do tego baza na db first więc muszę robić migracje, naprawiać konflikty na bazach, dopisywać constrainty itp do wszystkiego co dawno powinno być zrobione. Więc z jednej strony ok- nie można zakładać za dużo na przyszłość, ale pisanie zamkniętego kodu bez możliwości jego rozwoju to jest jeszcze większy dramat i dlatego w zespole jest potrzebny porządny architekt a nie juniorek któremu coś się wydaje bo postawił kilka stron na wordpressie i on wie lepiej.

    •  

      pokaż komentarz

      jeżeli masz tylko złe doświadczenia to szkoda, może kiedyś trafisz na kogoś kto ogarnia

      @Ligniperdus: Wiesz, ja programistą jako takim byłem 10 lat temu, ale szczerze powiem że nie lubiłem tego jakoś specjalnie. Z programowania to najbardziej lubiłem naprawianie bugów w starych systemach w których nikt juz nie chciał grzebać ;)
      Teraz bardziej zajmuję sie ogarnianiem systemowym, całkiem sporych systemów gdzie jest sporo SW ale jescze więcej całkiem ciekawego HW. Tak że poczynania programistów obserwuję sobie z boku, czasem im doradzając, często niestety na zasadzie "baco, spadniecie" ;)

    •  

      pokaż komentarz

      @PDCCH: w pewnej firmie którą znam... z roku na rok w kolejnych projektach klepane jest bardzo podobne oprogramowanie... i przy każdym kolejnym projekcie ludzie "odkrywają koło na nowo"... to jest dramat... rynek jest przepełniony ludźmi którzy się do tego nie nadają...

    •  

      pokaż komentarz

      To jest chyba lepsze niz strona z paternami

      @polska_partia_programistow: Zapomiałeś o cytatach innego Pana:
      http://harmful.cat-v.org/software/c++/linus

    •  

      pokaż komentarz

      @Osrakek69: nie mialem za duzo styczności z c++, tyle co na wykopie czasem wpada w stylu 20 sposob na alokacje pamięci. Troche to dziwi ale co mi tam, niech maja różnorodność

    •  

      pokaż komentarz

      Aktualnei jakieś 20 lat w branży. 10 lat aktywnego kodowania, ostatnie 10 bardziej "ogarnianie"
      @PDCCH: Przepraszam za wścibkość, ale u jakiego pracodawcy robisz, że takie anty-praktyki zdają się normalnością? Pytam co by wiedzieć kogo unikać... No bo bądźmy szczerzy, nie ma nic gorszego od tworzenia kodu niezdatnego do rozszerzania. Przecież żaden projekt nie jest napisany raz na zawsze. Trzeba go utrzymać i rozwijać. Co wtedy? Jak sobie z tym radzisz?

      Ja w poprzedniej pracy odziedziczyłem jeden moduł "pisany na teraz". Za każdym razem kiedy musiałem do niego zajrzeć to zaczynałem od melisy. Bo po co zrobić kod "future proof" jak można walnąć babola, w którym każda durnota jest deklarowana w 10 różnych miejscach? Niech Ci co przyjda po Tobie się martwią...

    •  

      pokaż komentarz

      No ale teraz jest to nasze, własne, lepsze, bo przepisane. I jakie nowoczesne, użyliśmy wszystkich nowości które się w standardzie pojawiły.

      @PDCCH: ... oczywiście do czasu gdy trzeba zmienić/dodać jakaś funkcjonalność do modułu i ktoś kolejny (bo zespół w międzyczasie się przetasował) podejmuje decyzję "przepisujemy!" ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      No i potem taki kawałek po zintegrowaniu z resztą systemu trafia na testy. Testy już całego systemu. No i zaczyna się, bład na błedzie. Tu jakiś przypadek nieobsłużony, tam się wysypuje w innym corner case itp.

      @PDCCH: jeżeli to jest prawdziwie to rzeczywiście podaj proszę firmę aby unikać.

    •  

      pokaż komentarz

      @Nicolai: Myślę że nie do końca o to chodzi. Chodzi o umiar i rozsądne przewidywanie przyszłości. Czy jest sens robić wszystko tak żeby było super-duper-extra uniwersalne? Po iluś projektach wiesz w którym kierunku mogą ewoluować. Ja zazwyczaj piszę w ten sposób, że jeśli ewentualna przebudowa danego fragmentu może być dużym kosztem, to od razu piszę go w 'uniwersalny' sposób. Jeśli mam jakąś prostą rzecz, to nie bawię się w to do czasu pierwszej rozbudowy - wtedy od razu przepisuję kod tak, żeby był uniwersalny. Nie trwa to długo, bo przecież dlatego go zostawiłem :).

    •  

      pokaż komentarz

      oczywiście do czasu gdy trzeba zmienić/dodać jakaś funkcjonalność do modułu i ktoś kolejny (bo zespół w międzyczasie się przetasował) podejmuje decyzję "przepisujemy!" ( ͡° ͜ʖ ͡°)

      @powaznyczlowiek: Oczywiście, dokładnie tak jest i tym samym cykl się zamyka. "Z gówna powstałes i w gówno się obrócisz" można by rzec... ;)

    •  

      pokaż komentarz

      jeżeli to jest prawdziwie to rzeczywiście podaj proszę firmę aby unikać.

      @vitek6: to polecam zmianę branży bo tak jest wszędzie xD

    •  

      pokaż komentarz

      @powaznyczlowiek: u mnie tak nie ma. Tetsuje się dużo wcześniej i ciągle.

    •  

      pokaż komentarz

      @PDCCH:

      Ewentualnie spekulatywna generyczność,czyli zakładanie potrzeby generyczności ("for future") w obszarach które tego nie potrzebują.
      przeraża mnie że masz za tą wypowiedź 40 minusów...

      Uwielbiam zwłaszcza jak, zazwyczaj juniorzy, tworzą np. interfejs dla klasy która ma jedną jedyną implementację i potem typowy dialog:
      - "po co ten interfejs?"
      - "no żeby móc zrobić kilka implementacji"
      - "a ile masz implementacji?"
      - "jedną"
      - "to po co interfejs?"
      - "no żeby łatwiej pisać testy"
      - "ile testów napisałeś dla których musiałeś napisać alternatywną implementację tego interfejsu?"
      - "zero"

    •  

      pokaż komentarz

      @Ligniperdus: W pełni się zgadzam , jak zaczynałem obecny projekt miałem taką sytuację. Po 2 tygodniach walki postanowiliśmy pisać wszystko od 0 bo wprowadzanie zmian mijało się z sensem.

  •  

    pokaż komentarz

    A na mnie się często krzywo patrzyli, że mam p$$?%%%ca by kod był maksymalnie czytelny bez jakichkolwiek komentów xD

    •  

      pokaż komentarz

      @evolved: Dobre. Niemniej jednak nie twierdzę, że nie należy stosować w ogóle komentarzy, ale jak kod wymaga za dużo komentarzy to znaczy że strukturalnie coś jest z nim nie tak.

    •  

      pokaż komentarz

      @lonegamedev: ja na co dzień obserwuję w pracy jak działa efekt dunninga-krugera. do szefa "Trzeba zrobić to porządznie bo później będzie problem... " szef: "nie będzie".. pół roku później.. szef: "jest duży problem"... itp itd..
      Najgorsze jest wprowadzanie zarządzania agile przez niekompetentnych ignorantów nastawionych na osiąganie własnych subiektywnych celów... (czytaj kierowników dbających o statystyki i o własną dupę/wizerunek- ch$! że całe oprogramowanie w firmie to jeden wielki śmietnik i ze atmosfera w firmie sie pogarsza) .

    •  

      pokaż komentarz

      @mrares: kolejny beciak programista, dlaczego dajesz komuś do wyboru że zrobisz coś kiepsko? Lub jak coś takiego widzisz to nie interweniujesz, ja jak byłem TL to zawsze takie tematy ucinałem jak jakiś członek zespołu zaczynał takie dyskusje, bo nie chce mi się potem wpadać w spiralę chwilówek przez to że jakiś członek zespołu nas zadłużył, bo myślał że się komuś takim zachowaniem przypodoba lub uzyska aprobatę (tak naprawdę to zyskuje łatkę ale popychadła / bety). Potem Polacy się dziwią jak to jest że jemy sól wypadową, padlinę, lub że jacyś szeregowi pracownicy wybili wszystkie ryby w rzece bo jakiś przełożony kazał.

      Następnym razem jak będziesz w warsztacie u mechanika, to pomyśl czy szef mu kazał zrobić to porządnie "bo potem będzie problem jak klient się zabije bo koło odpadło lub hamulec się zepsuł - ale być może się wymigamy", czy było dużo klientów i trzeba było na szybko zrobić :-).

      Jak ktoś chce mnie do czegoś takiego zmusić to zawsze daję prostą prośbę, że proszę o danie tego polecenia służbowego na piśmie. Ale do czegoś takiego to trzeba mieć jaja. Jasne czasami trzeba pracę zmienić, ale jak się ktoś sparzył to dość szybko potem jest w stanie odfiltrować toksyczne firmy.

      I tak na wypadek jakbyś myślał, że Tobie takie uległe zachowanie nie szkodzi to się mylisz. Nikt sensowny, chyba że naprawdę zmuszony okolicznościami nie chce pracować z ludźmi którzy ulegają takim presją. W odwrotną stronę też to działa, jak nie ulegasz takim naciskom, i przy tym dobrze pracujesz to jak ktoś znajdzie fajną pracę to kogo poleci jak myślisz taką uległą osobę, czy kogoś kto pisze dobry kod mimo nacisków i nie ulega takim głupim presją?

      Pozatym jak nie masz praktyki w pisaniu dobrego kodu, czy pola do rozwoju, plus jeżeli ulegasz takim presją to wszyscy koledzy mają Cię za kiepskiego lub nie będą Cię polecać, bo mają dość kodu który klepiesz na szybko pod presją. Z życia Ci podam przykład że parę dni temu odmówiliśmy kolesiowi pracy mimo że w rozmowach był ok, bo ktoś kto u nas pracuje i jest dobry, powiedział że z X nie chce pracować. I gość został odrzucony.

      Dodatkowo trzeba też pomyśleć, na jakiej trajektorii jest ktoś kto się na coś takiego zgadza, jak dla mnie jest to trajektoria wypalenia zawodowego, i nabywania doświadczenia w stylu mam 10 lat doświadczenia, tj 10 razy 1 lata doświadczenia w pisaniu kiepskiego kodu w taki sam sposób, bez poprawy itd. A potem zdziwienie skąd się wzięły słynne cytaty że Każdego specjalistę można zastąpić skończoną liczbą studentów najczęściej jednym.

      Jak jeszcze pracowałem u kogoś to przez parę ostatnich lat nigdy nie chodziłem na żadne rozmowy kwalifikacyjne do randomowych firm, nie było mi to potrzebne. Nie mówiąc o tym że oferty z polecenia miały trochę inne widełki niż te z ogłoszeń, i nie trzeba było się bawić w bullshitowe zadanka itd. Tylko rozmowa o tym co się zrobiło, co chcą żebym dla nowej firmy zrobił i czy kasa się zgadza. Nie mówiąc już o własnym biznesie, każdy klient pyta a ile to kosztuje i czemu tak drogo, czy nie dało by się zrobić na szybko, itd.

    •  

      pokaż komentarz

      ulegają takim presją
      ulegasz takim presją
      ulega takim głupim presją


      @Jaslanin:

      Zapamiętaj sobie np. taki przykład na przyszłość (wiem, że pomieszane liczby mnoga i ujemna, ale chodzi o pokazanie różnicy):
      Celownik (komu? czemu?): kobietom
      Narzędnik (z kim? z czym?): z kobietą

      Ulegają (komu? czemu?) presjom.

      http://pl.wiktionary.org/wiki/presja

    •  

      pokaż komentarz

      ulega takim głupim presją

      @Jaslanin: presjom ( ͡~ ͜ʖ ͡°)

    •  

      pokaż komentarz

      @Jaslanin: Stary masz dużo racji ale nie każdy kod mysi być piękny - tu trzeba jasno rozróżnić kod, który będzie żył latami od prowizorki do jutra. Czasem jest tak, ze trzeba zrobić prowizorkę i tyle - - ty powiedz p$?#?!?e nie robię a firma dostanie po dupie.

      Wiadomo mówię o sytuacjach wyjątkowych, których na co dzień da się uniknąć natomiast raz na jakiś czas może się zdarzyć grubszy fuckup, który ktoś musi polatać a nie się zastanawiać czy nie dało by się przypadkiem lepiej rzeczy ponazywać.

      Z punktu widzenia biznesu czasem ma po prostu przechodzić testy a co jest w środku ma drugorzędne znaczenie.

      Czasem taniej i lepiej będzie przepisać całość w kolejnej iteracji niż spóźnić się o dzień.

      Ogólnie jeżeli przyjmiesz założenie, że kod jest do wyrzucenia a liczy się dostarczana funkcjonalność otworzą ci się oczy na nowe rozwiązania.

    •  

      pokaż komentarz

      @Wrath_of_the_Tyrant ciekawe czy kod równie dobry jak znajomość polskiego

      Bo na razie się dowiedzieliśmy że ten miras ma bardzo silnom psychikę, zajebiście silnom ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @lonegamedev:
      Nie wiem czemu Cię tak zminusowali. Nie ma nic bardziej wkurzającego nic bezsensowne komentarze. Np. komentarz typu "Save something" nad wywołaniem metody save, albo // Check if something enable nad if(something.Enable)

    •  

      pokaż komentarz

      kolejny beciak programista

      @Jaslanin: jak piszesz z perspektywy korpo to spoko, ale inaczej to wygląda w startupie na pierwszych etapach rozwoju, gdzie dostarczenie jakiegoś ficzera konkretnemu klientowi na czas może oznaczać być albo nie być.

      Wiadomo, to samo dotyczy bugów ale o idealnie zaprojektowanym i przemyślanym kodzie można często zapomnieć, nie wspominając o tym że jakiś moduł się rozwinął w stronę której nie szło przewidzieć, a przepisywanie go od zera byłoby znowu samobójstwem. Narastanie długu technicznego to naturalne i często nieuniknione zjawisko, które trzeba łagodzić refaktorowaniem w momentach kiedy jest spokojniej, i dobry TL to zaplanuje.

  •  

    pokaż komentarz

    Ciało gnije od głowy.
    Najgorsze co można mieć to zespół zdolnych/ambitnych programistów którzy znają dobre praktyki i się ich przymusza do robienia fixów na szybko, po łebkach, byle by działało, bo termin już dawno jest ustalony przed estymatami.
    Tak niestety bywa najczęściej.
    Złe praktyki to akurat można wyplenić w średnio dużym zespole, bo wystarczy żeby jedna-dwie-trzy osoby były ogarniętymi seniorami.
    Niestety nic nie pomaga jeśli zarządzanie projektem ssie i się wszystko robi na pałę, byle zdążyć na wczoraj.

  •  

    pokaż komentarz

    Gość ma jednocześnie rację, ale jej nie ma. Nie podaje przykładów do swoich twierdzeń, więc już punkt pierwszy jest zły - otóż rozbijanie metod na kilka mniejszych metod jest pożądane, ponieważ pozwala uporządkować kod. Dzięki temu patrząc na główną metodę i NAZWY metod które wykonują się w jej ciele widzisz od razu co się dzieje. Nazywanie tego spaghetti code jest o tyle błędne, że to własnie BRAK podziału na mniejsze metody prowadzi do spaghetti - czyli do jednej wielkiej metody która ma w sobie wszystko i odnaleźć się w niej to istna sztuka. I teraz sa dwie strony medalu - otóż dobry programista powinien wiedzieć kiedy metodę rozbijać na mniejsze czynniki, a kiedy przestać to robić. Tak czy siak, przykład średnio udany.

    •  

      pokaż komentarz

      @Mave
      Ileż razy ja się naogladalem super klas co robią wszystko i mają po 1k+ linii kodu. Tego się nie da czytać. A jak jeszcze do tego wrzucone są wątki, które jakoś komunikują się z innymi, równie wielkimi klasami to idzie się tylko pociąć.

      Jak dla mnie jeśli klasa ma 1k+ linii (jestem programistą mobilnym w androidzie) to poza nielicznymi przypadkami jest to błędnie napisana klasa. No i jeszcze komentarze typu

      // Calculate distance from A to B
      int calculateDistance(int a, int b){}

    •  

      pokaż komentarz

      @Mave: no właśnie strasznie się zdyskredytował jak nazwał to spaghetti codem. Może to jest taki kanał "typowy tech lead", który pierniczy nt. rzeczy o których nie ma pojęcia.
      Ten przykład z bitami zamiast kilku booli też z dupy, albo z ery C. Pisząc w Javie, PHP, JavaScripcie nie widziałem ani razu takiego pomysłu.
      Używanie rekurencji zamiast iteracji w prostym forze? Nie widziałem nigdy tak szalonego pomysłu.
      Przykład z wieloma zmiennymi jest prawie dobry, ale c%@%%wo to wyjaśnił.

      Chyba nie chciał bym takiego tech leada.

    •  

      pokaż komentarz

      @Mave: @soomal: @ukradlem_ksiezyc:

      Wszystko do przesady jest zle, jak mam miec funkcje co w srodu wykonuje 5 operacji ktore sie dal latwo ogarnac wolalbym miec to w jednym miejscu niz w 5.

    •  

      pokaż komentarz

      Ileż razy ja się naogladalem super klas co robią wszystko i mają po 1k+ linii kodu

      @ukradlem_ksiezyc: Kiedyś odziedziczyłem projekt z Indii, gdzie metoda Page_Load w ASP.NET miała 1700 linii kodu, klasa 4500 linii

    •  

      pokaż komentarz

      @snup-siup: ja odziedziczyłem projekt w Javie, gdzie ktoś robił GUI w swingu na jakimś kreatorze, który zostawia komentarze typu "nie dotykaj bo zepsujesz". Niby nic takiego, ale całe GUI (okno główne, wszystkie karty i wszystkie dialogi i inne okna) były zawarte w jednym pliku, który miał ponad 11 tysięcy linii kodu ( ͡° ͜ʖ ͡°). Prawdziwe combo, jeżeli wziąć pod uwagę, że nazwy zmiennych to Button1... Button80 ( ͡° ͜ʖ ͡°). Zanim zacząłem coś robić, to samo doprowadzenie tego do stanu używalności, rozdzielenie dialogów, okien, oraz kart w oknie głównym na osobne pliki, ogólnie przepisanie połowy kodu zajęło około miesiąca.

    •  

      pokaż komentarz

      @snup-siup: Co ty wiesz o Hinduskim kodzie... My mieliśmy klasę na 30k linii, jeden wielki switch zawierający pierdyliard ifów, a wszystko to robiło za słownik do jakichś kodów...

  •  

    pokaż komentarz

    najłatwiej rozp$?$@@%ić firmę od środka spuszczając się nad devops i programując pod devops. zrobić wszystko pod kubernetes, jakimiś gównoskryptami w shellu połączyć, żeby się jakoś trzymało, do tego gitlab ci i jesteś nie do wyrzucenia z firmy, bo nikt tego bajzlu nie ogarnie. a jak ktoś się będzie czepiał, to zjeb go jak burą sukę i powiedz, że to jest best-practice i google tak robi. nawet jak ni c!@!$ nie potrzeba ci tego, bo twoje serwisy uciągnęłoby raspberry pi...