Czy zdarzyło się wam, że dyskutując o rzeczach technicznych, gdy argumentujecie rzeczowo jak coś powinno wyglądać, a jako kontr argument usłyszeliście:
"To twoja opinia"
Jeszcze tym zrozumiał taki argument, jeśli chodziło by o coś mojego własnego wymysłu, ale parę razy usłyszałem to, gdy narzekałem na tak oczywiste rzeczy jak:
liczby magiczne
za długie i skomplikowane funkcje
za wiele argumentów funkcji
A dziś usłyszałem to, od gościa, który się chwalił, że pracował przez 8 lat dla MS, a była to odpowiedź na mój komentarz pod definicją lambdy, która miała powyżej 7 (siedmiu) argumentów i miała ponad 40 linii (dużo if-ów).
Zawsze jak słyszę ten "argument", to załamuję ręce i próbuję tłumaczyć, że to nie jest moja opinia i staram się podpierać źródłami godnymi zaufania (np to).
Niestety reakcja zwykle nie jest satysfakcjonująca.
Jak wy sobie radzicie, z tym wytrychem, który tak naprawdę jest zawoalowaną odpowiedzią: nie mam argumentów i nie przyznam ci racji lub nawet mam gdzieś twoje argumenty?
Niby ktoś, kto tak mówi ma rację (bo wszystko jest "czyjąś opinią"), ale ja tam wolę jednak jak ludzie mówią "to jest moja opinia", czyli sami się przyznają do tego, że są subiektywni, a nie wykorzystują oczywistej oczywistości do walki z innymi poglądami.
No i kaman, jak ktoś ewidentnie nie ma argumentów, poza tym, że "ja tak lubię robić" to równie dobrze mógłby przyznać się do tego i powiedzieć:
Ok, ja lubię liczby magiczne, i lubię pisać długie i skomplikowane funkcje.
Taki jest mój styl, taka moja pieprzona subiektywność. Tak się nauczyłem i tak piszę. Nie widzę w tym nic złego
Bo takie podejście ("to moja opinia") przynajmniej dopuszcza to, że kogoś możesz przekonać do zmiany zdania.
A przerzucanie piłeczki i mówienie "taka jest twoja opinia" to takie dziecinne obrażanie się i nie przyjmowanie krytyki, coś jak "jesteś głupi".
No chyba, że to druga strona nie ma stosownych argumentów.
Bo powiedzmy, że ktoś będzie chciał przecisnąć jakiś dogmat, np. to, że Scrum jest najlepszą metodyką i wszyscy powinni pracować w Scrum, to jeśli taka osoba nie ma większych argumentów, to sorry, ale trzeba czasem go sprowadzić na ziemię i powiedzieć, że "taka jest twoja opinia". Żeby w ogóle to wiedział.
skreśliłem, bo w sumie przeciwko Scrumowi można wysnuć masę konkretnych argumentów i nie potrzeba sprowadzać do subiektywności. Ale nie chce mi się wymyślać innego przykładu.
Są narzędzia do pomiaru Code Quality - jeśli z nich nie korzystacie, to może doprowadź do jednorazowego testu (tak niby z ciekawości), rozegraj to tak, żeby w ogóle nie trafiało w kontekst Waszej wymiany zdań i ciesz się wysokim wynikiem 4.7/10 ;). Potem jako zespół przeanalizujcie raport.
Moim zdaniem koleś, którego przywołałeś jako przykład, nie czyta, nie interesuje się i jest niereformowalny - bo Ameryki przecież nie odkryłeś tymi postulatami. Dyskusje z nim powinieneś traktować jako ciekawe zjawisko, nic więcej. MS to akurat ostatnia firma, którą bym kojarzył z podążaniem za standardami jakości.
MS generalnie pisze dobry kod. Przynajmniej kiedyś tak się na 4p uważało :) -
WeiXiao2018-10-05 22:36
Bardziej mi chodziło o to, że lubią robić rzeczy po swojemu, chociaż to się powoli zmienia - wyjście na Github, jakieś open source, podbicie do różnych społeczności. Ale tak dla przykładu - do ostatniego projektu musiałem wrzucić bibliotekę od MS i to w mojej karierze jedyny przypadek z jakim się spotkałem, że port w connection stringu podaje się po przecinku i spacji za hostem, zamiast dwukropka. Może mało jeszcze widziałem. -
roSzi2018-10-05 22:45
@roSzi: może po prostu obsługuje taki, ale ze średnikiem też daje rade. Nie wiem co to ma do jakości kodu, ale :) -
WeiXiao2018-10-05 22:54
Z perspektywy użytkownika Office Portal, MS Teams, Skype for Business (tu akurat jest w miarę w miarę) i inne nigdy mnie nie powalały, wszędzie te kręcące kropeczki loadingu, czasem brak komunikatu, czasem komunikat od czapy, jakieś to wszystko takie średnio dopracowane. Ale życzę im jak najlepiej. -
roSzi2018-10-05 23:00
No tak, bo Oracle jako JEDYNE rozwiązana rynku, której wymaga JAWNEGO commita jest znaczny bardziej intuicyjny. :D -
somekind2018-10-06 01:25
Ale to jest twoja opinia - z definicji. Ty uważasz, że funkcje są za długie i to jest twoja opinia. On uważa, że nie są i to jest jego opinia. W swojej zarozumiałości zakładasz, że tak bardzo masz rację, że to nie jest dla ciebie opinia, a prawda objawiona - a na potwierdzenie przytaczasz opinię kogoś innego, kto ma być wyrocznią, czyli podasz linka i to znaczy, że masz rację bo pod tym linkiem napisano, że ją masz.
Pytasz jak "sobie radzimy", no z tego co powyżej piszą to nijak, tylko na zasadzie przeciągania liny. Moja racja jest najmojsza. Ja wiem lepiej, a w Microsoft nie wiedzą. Zapuścmy jeszcze jakieś narzędzie z d**y i ono wykaże, że moja opinia to prawda najmojsza najlepsza.
rozumiem, że w twojej firmie nie ma żadnych stadardów? ok, podaj nazwę, będziemy wiedzieli co omijać :D -
mr_jaro2018-10-05 21:54
ale standardy przecież to też zopiniowany sposób działania i przyznanie, że jeden sposób arbitralnie będzie lepszy (np. ruch uliczny prawostronny/lewostronny, albo spacje/taby). -
LukeJL2018-10-05 21:59
Problem jest w tym, że on się nie mylił z tą opinią, a raczej użył tej oczywistości, jako wymówki (coś jak "głowa mnie boli, nie mam siły na takie dyskusje"). -
LukeJL2018-10-05 22:01
@LukeJL: tak, ale przez tyle lat ile jest programowanie z jakiegoś powodu części rozwiązań się nie stosuje, bo są m.in nieczytelne. -
mr_jaro2018-10-05 22:01
@kulson - promujesz jakiś turbo-relatywizm i to jeszcze aroganckim tonem. Za czymś się trzeba w życiu opowiedzieć, jeśli mamy mieć coś na kształt postępu, co nie znaczy, że nie można się mylić. Autor sugeruje, że zamiast merytorycznej wymiany poglądów słyszy tylko taki tekst na odczepne. Odnosi się przecież do rzeczy z punktu widzenia programisty fundamentalnych, jak to, czy funkcja łamie zasady SOLID. Za tym wszystkim stoją dziesiątki lat empirycznych doświadczeń. Niestety ciągle jest za dużo ludzi, którym one wiszą i potem mamy takie produkty od 7-miu boleści za pół bańki -
roSzi2018-10-05 22:40
Czy funkcja łamie, czy nie łamie SOLID to też jest kwestia relatywna - kwestia oceny konkretnego przypadku. Czyli znów opinia, wszyscy znają te zasady, a opinie mogą być różne -
kulson2018-10-05 22:44
No jak bym słyszał debatę o łamaniu konstytucji ;). Tak, podlega to wykładni i ocenie - która może być mniej lub bardziej oczywista - ale trzeba dyskutować i wykazywać swoje racje, a nie olewać kumpla z zespołu. -
roSzi2018-10-05 22:48
Może być tak, że autor jest zarozumiały, ciągle mu coś się wydaje i ciągle zawraca dupę, wtedy dostaje odpowiedź typu "to twoja opinia". Skoro zdarza się mu to tak często, to albo pracuje wśród samych ignorantów, albo nie ma racji. Stawiam na to drugie. -
kulson2018-10-05 22:51
To uczucie, gdy kozaki z internetu spotykają się z prawdziwym światem biznesu, gdzie znakomita większość ludzi ma w dupie ich uber code i studia a liczy się generowanie kasy.
@kulson: popatrz na moje przykłady. Ty naprawdę uważasz, że to jest moja opinia? No to popatrz na linka jakiego podałem. To jest dowód, że nawet jeśli uznać to za opinię to nie jest ona moja, ale opinia ludzi z pierwszej ligi naszej branży. A biorąc jeszcze pod uwagę rzeczowe uzasadnienie, to nie jest opinia, tylko stwierdzenie faktu jak wygląda dobra praktyka programistyczna.
Opinia to coś subiektywnego, jeśli podda się ją rzeczowej analizie dobrze uargumentuje i udowodni, to przestaje być subiektywną rzeczą i nie jest już opinią, ale faktem.
Przykład, nietechniczny: ktoś się źle klnie na całe gardło, ja mówię mu że to jest niekulturalne zachowanie. On odpowiada że to tylko moja opinia i będzie dalej robił jak chce. Czy naprawdę uważasz, że faktycznie, to tylko moja opinia, czy ogólnie przyjęta norma społeczna.
Ogólnie przyjęta norma społeczna to nadal opinia tylko większej ilości ludzi. W jakimś innym środowisku może być to np. mile widziane :D -
tdudzik2018-10-06 20:27
@tdudzik: Klnięcie ma z definicji i założenia nie być akceptowalnym społecznie, więc niestety to nie jest niczyja opinia a zgodność z funkcją jaką ten element języka pełni. -
TomRiddle2018-10-07 19:12
O rany kiedyś z tym strasznie walczyłem i miałem dużo trudnych i toksycznych przypadków. Nawet cały zespół przeciwko sobie.
Robienie metryk tak jak to napisał @roSzi, działa - pozwala przeciągnąć na swoją stronę sojuszników. Ludzie chyba lubią takie gierki i się wciągają (i można sobie zrobić metrykową patologię, ale to inny temat). W kilku zespołach dzięki metrykom dużo mi się udało osiągnąć , przy czym jeden to na początku była totalna patologia(nawet szkoda opisywać i tak nikt nie uwierzy -wyznawcy gorliwi copy paste i hashtable oriented programming).
Ale też to były czasy javy 1.3 i , 1.4 i wtedy działały Checkstyle, PMD i inne narzędzia, (miedzy innymi liczą Cyclomatic Complexity i inne metryki). Było mniej, więcej przyjęte (np. w Checkstyle) co jest dobrym kodem i mało kto sie kłócił, które reguły sa dobre, a które warto wyłączyć.
Teraz to bardziej pokitrane. Przez kod funkcyjny jest różnie, dużo metryk nie ma sensu (nawet CC w kodzie czysto funkcyjnym jest do duszy, potrafie zrobić mega skomplikowany kod bez jednego ifa ..., który ma idealne CC = 1). Przez rewolucję Clean Code - dużo reguł jest przestarzałych i jest więc nawet antymetrykami, antypatternami (checkstyle potrafi w defaultowej konfiguracji przyczepić się do braku JavaDoc do geterów).
Więc nie jest już tak łatwo.
Szukam artykułów z sieci i podaje linki - w celach edukacyjnych. (ile razy wrzuciłem artykuł Olivier Gierke o field injection to już nie pamiętam, o checked exceptionach itp. o nie robieniu w JSFie...)
Wrzucam i czasem kogoś przekonam (czasem to trwa). najgorsze, że w sieci do każdego artykułu znajdziesz antyszczepionkowcaów. Pewien plus, że jeśli oponent jest nieczytający to jest szansa, że nie będzie umiał znaleźć.
Nie do przecenienia jest też fakt, że jest mi łatwiej, bo jestem stary i mam brode - mam automatycznie +10 do autorytetu w sprawach IT.
Przy okazji: - może się okazać, że moja i Twoja opinia o liczbach magicznych jest różna.
Przypomniałem sobie, jak ... nie tak dawno temu zapisałem się na to forum... aby nauczyć się dskutować z ludżmi mniej zaawansowanymi. Bo o ile dogadywałem się zawsze z doświadczonymi programistami i architektami ... to zacząłem mieć problem z juniorami, przepaść w warstwie językowej (btw. widzę postępy).
Przeczytałem ten artykuł: http://olivergierke.de/2013/11/why-field-injection-is-evil/. Kluczowym argumentem (poza testowalnością) jest:
Unikaj wstrzykiwanych pól bo może to prowadzić do "wstrzyknięcia nulla" a co za tym idzie twoja klasa będzie miała niepoprawny stan i zrobi klientowi kuku.
Nie widzę jednak "mocy" tego argumentu. Przecież implementacje DI takie jak IoC Springowy umożliwiają zapewnienie sobie, że pole musi zostać wstrzyknięte (nie null). Możesz nieco rozwinąć temat?
(P.S. podrzuć ten artykuł o checked exceptions :) ) -
watek2018-10-05 22:51
@jarekr000000: nie tak dawno temu zapisałem się na to forum... aby nauczyć się dskutować z ludżmi mniej zaawansowanymi czuje się atakowany :) -
WeiXiao2018-10-05 23:47
@jarekr000000: Akurat testowalność to jeden z najsłabszych argumentów. W django wystarczy, że zrobisz testy endpointowe (które nie rzutują na zapis kodu) i wtedy na 99.99% nikt nie wymaga zapisu testowalnego kodu, bo i po co skoro projekt ma testy? -
nohtyp2018-10-06 16:32
@nohtyp: nie wiedzę gdzie jest problem, jeśli jesteś w stanie efektywnie testować to jest git. W springu (którego uwielbiam), też się da względnie łatwo robić testy endpointów. ( i wtedy jak w django - nie ma problemu). Jakkolwiek, dużo łatwiej nadal się robi testy mniejszych izolowanych jednostek (np. serwisów) i to całkowicie przeważa. -
jarekr0000002018-10-06 19:48
Przykład, nietechniczny: ktoś się źle klnie na całe gardło, ja mówię mu że to jest niekulturalne zachowanie.
Co ten przykład ma pokazać? To znów jest twoja opinia. Ktoś inny może widzieć to inaczej i mieć inną opinię.
@mr_jaro co innego ustalone standardy w firmie, które są arbitralnie narzucone w projekcie, a co innego jak kazdy kto chce może cię pouczać i twierdzi że tylko on ma rację. Asertywna odpowiedź zamiast "Spie****" to "to jest twoja opinia"
Kiedyś na starcie jednego projektu zespół niemiecki oświadczył nam, że Oni mają wysokie oczekiwania wobec jakośc i kodu i mają reguły. Spoko... jakie? Otóż metody nie mogą być dłuższe, niż 50 linijek (rok 2012 to był). Cisza była długa i krępująca, nie wiedzieliśmy co powiedzieć. Powiedzieliśmy, że nam sie reguła podoba, ale czy by nie mogłobyc zamiast 50 - dać 10. Widzieliśmy potężną konsternację i w końcu ich czołowy architekt oświadczył, że tak się przecież nie da nic napisać. Po negocjacjach stanęło na 20. (dało się z tym przeżyć, nawet fajny projekt wyszedł.). -
jarekr0000002018-10-05 22:39
to tylko potwierdza, że jest to opinia bazująca na jakimś tam experience. najwidoczniej software engineering w niemczech = lol -
WeiXiao2018-10-05 22:42
W poprzedniej pracy jeden z naszych ekspertów napisał implementację pewnego algorytmu w metodzie, która miała 1000 linijek. Koleś był mega mózgiem, miał doktorat z fizyki i stwierdził że napisanie tej metody było jedną z najtrudniejszych rzeczy jaką kiedykolwiek robił. Myślę, że gdyby ktoś wprowadził wtedy regułę, że metody mają mieć nie więcej niż 20 linijek, ta metoda (kluczowa) nigdy by nie powstała, a co za tym idzie cały projekt. -
GutekSan2018-10-06 01:50
@GutekSan: mam takie uczucie, że algorytmika i dobre praktyki / clena code nie idą w parzę :P Jakiś ciekawy musiał być ten algo - jak długo mu to zajęło? -
WeiXiao2018-10-06 01:55
@GutekSan: piękny przykład anegdotyczny. Jeżeli wam takie metody w kodzie nie przeszkadzają to luzik. Jak przeszkadzają to można ekspertowi przydzielić programistę do sprzątania. Programista + ide wspierające extract method potrafi zaskakująco szybko takie coś ogarnąć. Czasem upokarzająco sprawnie, zwłaszcza jak jeszcze samo znajdzie, że kilka sekcji pasuje do wzorca. W projektach, gdzie pracowałem takie 1k potworki żyły na ogół do pierwszego w nich buga. -
jarekr0000002018-10-06 07:09
Bardziej niż długość metody przeszkadzają długie pętle i wielokrotne zagnieżdżenia. Jeśli kod jest czysto imperatywny i pozbawiony wielkich pętli to długość metody przestaje być problemem. Oczywiście można ją rozbić na mniejsze kawałki, ale wtedy taki kod: zróbA(); zróbB(); zróbC(); zróbD(); ... też nie wygląda zbyt ładnie. -
Azarien2018-10-06 11:33
@jarekr000000: teoretycznie ja i moi koledzy byliśmy tymi "programistami do sprzątania" całego projektu, który był w ten sposób napisany. Część rzeczy dało się uporządkować, ale akurat tego potworka nie. Sam autor po pewnym czasie zaczął się w nim gubić i choć generalnie był super pomocnym człowiekiem, to w tej kwestii po prostu nie chciał przegryzać się przez to jeszcze raz. Niestety nie było alternatywy dla tej metody - ten potworek musiał żyć. -
GutekSan2018-10-06 18:59
@Azarien - ten argument o płaskim kodzie słyszałem ileś razy. Jakkolwiek, w konkretnych przypadkach zwykle okazywało się, że i tak mimo, że płaskie to są tam jakieś sekcje tematyczne i po wydzieleniu na metody łatwiej je ogarnąć i łatwiej widać błędy (np. nieustawione parmetry , błędy copy paste itp). -
jarekr0000002018-10-06 19:53
@GutekSan: czyli w sumie nie wiem czy twój argument dobitnie nie pokzauje potrzeby sprzątania, puty jeszcze autor kojarzy co robił. Zdażyło mi się już rozgrzebać kluczowy dla firmy najważniejszy magiczny spaghetti batch( w drugim tygodniu pracy...). Przerażenie w zespole było duże. Zrobiłem nawet przy tym buga. Ale dopisałem testy (mimo, że sięnie dało), a mój bug wyszedł na review, bo batch stał się ogarnialny. Zwykle zresztą nie mam szacunku dla takich potworków i rozgrzebuje (przy okazji bugów). Wychodzi to zaskakująco dobrze, choć drobne nauczki bywają. -
jarekr0000002018-10-06 20:08
@jarekr000000: zdarzyło mi się pracować przy projekcie w którym wielkie metody były normą, a jednocześnie kod był jakby z kamienia - refaktoryzować niczego nie lza, zwłaszcza jeśli to odziedziczony kod (świeży jeszcze nie zastygł do końca, to można przerabiać). odżywała czasami dyskusja jako coś można by zrobić lepiej, ale zwykle nic z tego nie wynikało bo zasada "ma być jak jest" okazywała się nadrzędną. -
Azarien2018-10-06 20:23
@Azarien: Mam prostą zasadę, jeśli poprawiam buga w takiej magicznej metodzie i znajdę gdzie tego ifa wstawić, to znaczy, że musiałem choć trochę zrozumieć jak metoda działa, na tyle, żeby zrobić choć miminalny refaktoring i coś wydzielić. Dodatkowo, wiem, że skoro poprawiam buga, to ktoś to bedzie restestował. To jest dobry moment na poprawki. Ta metoda (w zasadzie zasada skauta) zaskakująco szybko czyści kluczowe kupy w kodzie. Choć jakieś zakurzone dramatyczne metody, w których nic się nie dzieje - pozostają takie na wieki. -
jarekr0000002018-10-06 20:31
@jarekr000000: idee o których piszesz brzmią ładnie, ale w praktyce nie jest takie proste. W biznesie panuje wyścig na dostarczanie działających prototypów - nie ma wtedy czasu na sprzątanie. Na co komu posprzątany kod, który i tak trafił do kosza ze względu na rezygnację klientów spowodowaną opóźnieniem? Z kolei po jakimś czasie posprzątać już się po prostu nie da. Im dłużej taki potworek działa, tym mniej opłaca się go naprawiać, bo działa i jest dość dobrze przetestowany w praktyce. -
GutekSan2018-10-07 20:54
@GutekSan nie pierwszy to już raz na tym forum dowiaduje się, że żyję w jakiejś innej praktyce. Może faktycznie jestem jeszcze zbyt młody i nie wszytko widziałem. W moich projektach staram się wymusić dość dobry kod, po to żeby nie było opóźnień, bo kiespki kod zwykle wali po głowie i to w najmniej oczekiwanych momentach. Nie widze, że by to był jakoś ewenement. Mój biznes te w kilu różnych firmach woli langsam aber sicher. Wyjątki widziałem, ale to były raczej patologie - januszsofty i januszprojekty. -
jarekr0000002018-10-07 23:20
@jarekr000000: nie, to raczej ja pracuję w takim obszarze, w którym, jak sądzę, każdy zarobiony dolar kosztuje dużo pracy i wiedzy, w porównaniu z innymi obszarami IT. Skutkuje to nieco innymi priorytetami i stosowaniem innych standardów i praktyk. Moje przykłady nie są po to by obalać tezę o konieczności dbania o jakość kodu, tylko raczej by pokazać, że istnieje niewielki procent problemów, w których stosowanie programistycznych dogmatów, którym ufa się tu bezwarunkowo, nie sprawdza się. -
GutekSan2018-10-07 23:32
@mr_jaro co innego ustalone standardy w firmie, które są arbitralnie narzucone w projekcie, a co innego jak kazdy kto chce może cię pouczać i twierdzi że tylko on ma rację. Asertywna odpowiedź zamiast "Spie****" to "to jest twoja opinia"
Standardy w firmie nie biorą się z księzyca. Albo narzucają je germańscy oprawcy ( i wtedy możemy tylko płakać), albo to zespoły je tworzą. I tu jest właśnie problem. Chcemy się dogadać co do regul, a dostajemy wielce konstruktywne spieto jest twoja opinia.