Czesc czesc, uzywacie SonarLint? Co ogolnie myslicie o tego typu narzędziach? Znacie jakies alternatywy czy sonar starczy do IDE?
0
0
Qodana od Intelijj wygląda fajnie, chodź jeszcze nie używałem
2
stanley123 napisał(a):
Czesc czesc, uzywacie SonarLint?
Nie używam bo nie wspiera ani Scali ani Haskella ani Rusta
Co ogolnie myslicie o tego typu narzędziach?
Lintery? Super sprawa
Znacie jakies alternatywy czy sonar starczy do IDE?
Dla Scali -> Scalafix, Dla Haskella -> hlint
1
Nie używam, głównie dlatego że 10% "porad" od tego typu narzędzi są nie w punkt. Tzn. czasem się zdarzy "rada" od takiego linta, która ja wiem że nie ma sensu. I wtedy albo ktoś kto się nie zna ją doda, mimo ze nie ma sensu, albo trzeba robić ignore'y.
Używam TDD oraz PP do zapewnienia jakości aplikacji.
4
Riddle napisał(a):
Używam TDD oraz PP do zapewnienia jakości aplikacji.
Nonsens, lintery zapewniają dużo więcej:
- jak inaczej sprawdzisz, że jakiś element w bibliotece stał się deprecated po podbiciu wersji?
- w TDD nie wykryjesz wszystkiego. Nie jest możliwe napisanie testów pokrywających każdy branch dla bardzo złożonego softu np. całego kompilatora, więc tak czy owak takie narzędzia są potrzebne
- lintery często wykrywają poza funkcjonalne problemy np. jakieś wycieki albo oczywiste problemy wydajnościowe, tego testy nie wykrywają tak łatwo
- lintery pozwalają na ujednolicenie stylu kodowania. To ważne w np w takich językach jak C++, gdzie jest straszny burdel
1
slsy napisał(a):
Riddle napisał(a):
Używam TDD oraz PP do zapewnienia jakości aplikacji.
Nonsens, lintery zapewniają dużo więcej:
- jak inaczej sprawdzisz, że jakiś element w bibliotece stał się deprecated po podbiciu wersji?
Przez IDE:
- w TDD nie wykryjesz wszystkiego. Nie jest możliwe napisanie testów pokrywających każdy branch dla bardzo złożonego softu np. całego kompilatora, więc tak czy owak takie narzędzia są potrzebne
Podaj przykład takiego case'a, gdzie linter jest w stanie to wykryć.
- lintery często wykrywają poza funkcjonalne problemy np. jakieś wycieki albo oczywiste problemy wydajnościowe, tego testy nie wykrywają tak łatwo
To prawda, i tutaj wchodzi PP.
- lintery pozwalają na ujednolicenie stylu kodowania. To ważne w np w takich językach jak C++, gdzie jest straszny burdel
Okej, mogę się zgodzić że ujednolicenie stylu kodowania to jest coś co linter jest w stanie zrobić. Ale w moich projektach zawsze wystarczyło uzgodnić ustawienia formatowania automatycznego, i potem się umówić że robimy auto-format plików przy commicie. Nic więcej nam nie było potrzebne.
Off-topic
Tylko @slsy, ja napisałem że ja nie korzystam. Jak Ty chcesz używać linterów to możesz, nikt Ci nie broni.
4
Riddle napisał(a):
Przez IDE:
Inspect code to w zasadzie linter dostarczany przez IDE. Jeśli rozmawiamy tylko o linterach dostępnych zewnętrznie to masz rację.
Podaj przykład takiego case'a, gdzie linter jest w stanie to wykryć.
Nie potrafię wskazać nic rzeczywistego. Duże projekky OS i tak używają linterów i fuzzingu, więc nie słyszymy od żadnych CVE, które mogłyby być wykryte przez CVE.
To prawda, i tutaj wchodzi PP.
Co to jest PP? Pair programming? Jak tak to za bardzo nie rozumiem jak to ma działać. Jeśli druga osoba patrzy na kod to pewnie wykryjemy więcej błędów co nie oznacza, że wykrywamy wszystko
Okej, mogę się zgodzić że ujednolicenie stylu kodowania to jest coś co linter jest w stanie zrobić. Ale w moich projektach zawsze wystarczyło uzgodnić ustawienia formatowania automatycznego, i potem się umówić że robimy auto-format plików przy commicie. Nic więcej nam nie było potrzebne.
Formatowanie to też przecież domena lintowania. W wielu przypadkach odpowiedzialność się rozmywa i ciężko powiedzieć co jest linterem a co nie. Przykładowo w takim Ruscie kompilator wykrywa dużo więcej rzeczy niż kompilatory innych języków a formatowanie też jest w zasadzie wbudowane.
2
Uwielbiam narzędzia do analizy kodu, czy to pod kątem ładności, czy bezpieczeństwa. Nie lubię ludzi, którzy nie wiedzą co one znajdują, ale ogarnęli technologię na tyle, żeby zrobić jakieś zrąbane wskaźniki i się przyp... o jakiegoś if'a za dużo, albo podatność na atak w miejscu gdzie ten atak nie może nastąpić.
0
slsy napisał(a):
Riddle napisał(a):
Przez IDE:
Inspect codeto w zasadzie linter dostarczany przez IDE. Jeśli rozmawiamy tylko o linterach dostępnych zewnętrznie to masz rację.Podaj przykład takiego case'a, gdzie linter jest w stanie to wykryć.
Nie potrafię wskazać nic rzeczywistego. Duże projekky OS i tak używają linterów i fuzzingu, więc nie słyszymy od żadnych CVE, które mogłyby być wykryte przez CVE.
No to chyba muszę odrzucić ten argument w TDD nie wykryjesz wszystkiego. Nie jest możliwe napisanie testów pokrywających każdy branch dla bardzo złożonego softu np. całego kompilatora, więc tak czy owak takie narzędzia są potrzebne.
Chyba że znajdziesz przykład.
To prawda, i tutaj wchodzi PP.
Co to jest PP? Pair programming? Jak tak to za bardzo nie rozumiem jak to ma działać. Jeśli druga osoba patrzy na kod to pewnie wykryjemy więcej błędów co nie oznacza, że wykrywamy wszystko
No tak, to jest trade-off, pomiędzy tym co linter znajdzie, a tym co człowiek znajdzie. Faktycznie, czasem lintery mają reguły których człowiek nie zna - to na plus. Ale często też lintery mają głupie zasady, ale zasady które nie działają zawsze. Dodatkowo, człowiek też znajduje rzeczy których linter nie jest w stanie wykryć.
Dla mnie trade-off jest silnie przechylony w stronę człowieka.
To pewnie zależy od programisty, ale dla mnie 95% zasad domyślnie włączonych w linter to followuje je z automatu, i nie potrzebuje toola który mi to sprawdzi. Na palcach jednej ręki mogę policzyć miejsca w których linter faktycznie mi podpowiedział coś czego nie wiem; ale za to dużo więcej case'ów było kiedy linter podpowiadał mi jakiś bez sens.
Rozumiem jednak że jesli ktoś nie jest dobrym programistą, albo np nie zna języka, to taki litner może podpowiadać dużo nowych, fajnych faktów, i wtedy jest dobry.
Okej, mogę się zgodzić że ujednolicenie stylu kodowania to jest coś co linter jest w stanie zrobić. Ale w moich projektach zawsze wystarczyło uzgodnić ustawienia formatowania automatycznego, i potem się umówić że robimy auto-format plików przy commicie. Nic więcej nam nie było potrzebne.
Formatowanie to też przecież domena lintowania. W wielu przypadkach odpowiedzialność się rozmywa i ciężko powiedzieć co jest linterem a co nie. Przykładowo w takim Ruscie kompilator wykrywa dużo więcej rzeczy niż kompilatory innych języków a formatowanie też jest w zasadzie wbudowane.
Nie wiem czy domena lintowania. U nas w projekcie używamy formaterów wbudowanych w IDE i nikt nie narzeka.
4
@Riddle: Ale te narzędzia pilnują nie tylko, żeby kod był ładny. Masz np. detekcję miejsc podatnych na SQL injection, czy inne XSS. Albo ostrzegają o użyciu za słabego szyfrowania. Czy coś z tym zrobisz, to twoja sprawa, zawsze możesz kliknąć ignore.
0
No tak, to jest trade-off, pomiędzy tym co linter znajdzie, a tym co człowiek znajdzie. Faktycznie, czasem lintery mają reguły których człowiek nie zna - to na plus. Ale często też lintery mają głupie zasady, ale zasady które nie działają zawsze. Dodatkowo, człowiek też znajduje rzeczy których linter nie jest w stanie wykryć.
Dla mnie trade-off jest silnie przechylony w stronę człowieka.
Do tego sluzy konfiguracja lintera :)
To pewnie zależy od programisty, ale dla mnie 95% zasad domyślnie włączonych w linter to followuje je z automatu, i nie potrzebuje toola który mi to sprawdzi. Na palcach jednej ręki mogę policzyć miejsca w których linter faktycznie mi podpowiedział coś czego nie wiem; ale za to dużo więcej case'ów było kiedy linter podpowiadał mi jakiś bez sens.
Ja za to domyslnie pisze bezbledny kod i nie potrzebuje testow. Dodatkowo widzialem duzo testow, ktore w rzeczywistosci niczego nie testuja, a tylko betonuja implementacje. Swietna retoryka no nie?
Okej, mogę się zgodzić że ujednolicenie stylu kodowania to jest coś co linter jest w stanie zrobić. Ale w moich projektach zawsze wystarczyło uzgodnić ustawienia formatowania automatycznego, i potem się umówić że robimy auto-format plików przy commicie. Nic więcej nam nie było potrzebne.
No rzeczywiscie lepiej sie umowic na gebe, niz wstawic tego jednego joba wiecej w pipeline i miec pewnosc, ze nikt (zlosliwie lub nie) nie wrzuci czegos co lamie te reguly :D.
A jak do projektu wchodzi nowa osoba to tez latwiej przypominac niz sprawdzac po jobie?
O ile w moim mniemaniu jestes osoba naprawde dobra technicznie, to jak czasem sie na cos uprzesz to potem dyskusja przypomina kopanie sie z koniem.
1
Nie mieszajmy systemów walutowych. Mowa jest o narzędziach do analizy kodu, nie tylko o linterze pilnującym długości linii czy nawiasów.
@Riddle: nie znam szczegółów o wielu innych językach ale w PHP masz standardy PSR. I taki PHPSTORM ma to zapięte poprzez wykorzystanie standardowej paczki bodajże fos csfixer do tego mamy możliwość podłączenia pod IDE PHPStan. No właśnie tylko taki PHPStan ma różne poziomy analizy, zależne od wersji PHP.
BTW możecie mieć w projekcie różne IDE, różne wersje IDE i cały misterny plan....
Widać, że nie używałeś takich rzeczy po prostu jak Sonarqube czy CheckmarX. Zrób sobie skan takiego projektu. Może okazać się, że biblioteka używana w projekcie ma CVE i Twój kod może być najpiękniejszy i przetestowany przez TDD na każdym etapie.
Nieraz przy mergu możesz coś niechcący wyciąć i nawet nie zauważysz. TDD to co innego i już.
3
Oczywiście. Sonarqube Server z dostosowanymi pod nas regułami. Przy każdym PR leci request do Sonara w celu analizy kodu. Jak check nie przejdzie to PR jest blokowany.
Sonarqube nie tylko analizuje składnię, ale też robi security checki, wykrywa code smelle jak duplikacja kodu, złożoność kognitywna, etc.
Skanujemy kod w Pythonie, Terraformie, C# i SQL.
0
jurek1980 napisał(a):
Nie mieszajmy systemów walutowych. Mowa jest o narzędziach do analizy kodu, nie tylko o linterze pilnującym długości linii czy nawiasów.
@Riddle: nie znam szczegółów o wielu innych językach ale w PHP masz standardy PSR. I taki PHPSTORM ma to zapięte poprzez wykorzystanie standardowej paczki bodajże foscsfixerdo tego mamy możliwość podłączenia pod IDE PHPStan. No właśnie tylko taki PHPStan ma różne poziomy analizy, zależne od wersji PHP.
No jest cośtakiego jak PSR i PHPStan.
Ale nie rozumiem co to wnosi do mojej wypowiedzi?
0
Seken napisał(a):
No tak, to jest trade-off, pomiędzy tym co linter znajdzie, a tym co człowiek znajdzie. Faktycznie, czasem lintery mają reguły których człowiek nie zna - to na plus. Ale często też lintery mają głupie zasady, ale zasady które nie działają zawsze. Dodatkowo, człowiek też znajduje rzeczy których linter nie jest w stanie wykryć.
Dla mnie trade-off jest silnie przechylony w stronę człowieka.
Do tego sluzy konfiguracja lintera :)
No widzisz, tylko to się mija z celem. Bo ja chcę dodać do swoich projektów coś, co ma sens. A nie dodać coś co nie ma sensu (defaulty lintera), a potem je blokować (konfiguracją lintera).
Gdyby domyślne reguły lintera były bardzo trafne (np trafiałyby w 99.9% przypadków) to nie miałbym problemów z nimi. Ale tak nie jest. Jak dodam linter w moich programie teraz, to znajdzie powiedzmy 50 "złamań zasad", z czego 40 wcale nie będzie złamaniem, tylko normalnym użyciem, których linter nie jest w stanie skumać. Musiałbym wtedy dodać konfigurację pod to, żeby go wyciszyć- ale co mi to da? To że znajdzie dwie funkcje za długie, albo jedną out of date dependency? No dzięki.
Jak mówiłem. Linter to spoko narzędzie IMO jak znajduje dużo błędów w Twoim programie. Jeśli dodasz linter do pojrketu, i linter znajduje same false-positive, to nie ma sensu go używać IMO. A przynajmniej ja nie używam.
To pewnie zależy od programisty, ale dla mnie 95% zasad domyślnie włączonych w linter to followuje je z automatu, i nie potrzebuje toola który mi to sprawdzi. Na palcach jednej ręki mogę policzyć miejsca w których linter faktycznie mi podpowiedział coś czego nie wiem; ale za to dużo więcej case'ów było kiedy linter podpowiadał mi jakiś bez sens.
Ja za to domyslnie pisze bezbledny kod i nie potrzebuje testow. Dodatkowo widzialem duzo testow, ktore w rzeczywistosci niczego nie testuja, a tylko betonuja implementacje. Swietna retoryka no nie?
Dobry argument - porównanie argumentu z nie używaniem lintera do nieużywania testów. Mam kilka odpowiedzi na to porównanie, nie wiem czy chcemy wchodzi w to.
- Myślę że "zadowolić linter" jest łatwiej niż "zadowolić testy", bo linter to jednak jest narzędzie do statycznej analizy kodu (więc on patrzy co "wygląda źle"). Natomiast testy odpalają kod, i faktycznie go ewaluują, bo testy patrzą na to jak faktycznie kod działa. Z tej uwagi, myślę że całkowicie normalne jest napisanie od strzała kodu który zadowoli linter (to tylko kilka wzorców, często nawet regexp), natomiat trudno jest napisać od strzała kod który działa bezbłędnie, bo nie mamy kompilatora i runtime'u w głowie.
Co do tego że widziałeś że są testy które betonują implementację - No cóż, są takie, jeśli ktoś nie umie pisać dobrych testów, to takie stworzy. Nie wiem co to dodaje nowego do rozmowy?
Okej, mogę się zgodzić że ujednolicenie stylu kodowania to jest coś co linter jest w stanie zrobić. Ale w moich projektach zawsze wystarczyło uzgodnić ustawienia formatowania automatycznego, i potem się umówić że robimy auto-format plików przy commicie. Nic więcej nam nie było potrzebne.
No rzeczywiscie lepiej sie umowic na gebe, niz wstawic tego jednego joba wiecej w pipeline i miec pewnosc, ze nikt (zlosliwie lub nie) nie wrzuci czegos co lamie te reguly :D.
Nie chodzi o to czy to jest job w pipeline czy nie; i nie chodzi o to czy trudno jest coś takiego dodać. Bo faktycznie dodać linter jest banalnie prosto. Chodzi o to że to jest dodatkowa zależność, dodatkowa rzecz o której trzeba myśleć, dodatkowa rzecz którą trzeba wziąć pod uwagę, dodatkowa którą trzeba utrzymać i dodatkowa która może coś zepsuć. Pomijając już to wszystko - rady lintera nie zawsze są poprawne. Czasem linter sugeruje dodanie czegoś co nie ma sensu - i jeśli jesteś seniorem, to wprowadziłbyś dobrą zmianę tak czy tak; a jak jesteś juniorem to nie potrafisz rozróżnić która rada lintera jest dobra a która nie.
Jeśli jesteś zainteresowany poprawnymi zasadami, to moim zdaniem Pair Programming jest dużo lepszym narzędziem do tego niż analiza statyczna.
A jak do projektu wchodzi nowa osoba to tez latwiej przypominac niz sprawdzac po jobie?
Jak nowa osoba wchodzi do projektu, to i tak ją trzeba onboardować, i do tego celu Pair Programming też jest dużo lepszy niż jakikolwiek statyczny tool.
O ile w moim mniemaniu jestes osoba naprawde dobra technicznie, to jak czasem sie na cos uprzesz to potem dyskusja przypomina kopanie sie z koniem.
Daj mi dobry argument za linterami to dyskusja się skończy. Na razie dostaję jedynie słabe.
Mam pomysł jak możemy to rozwiązać. Co powiesz na taki pomysł:
- Ty wklej kilka przykładów z Twojego doświadczenia, gdzie linter był pomocny. Ja wkleję kilka miejsc w których linter zrobił coś bardzo głupiego, i porownamy je. Bez przykładu na ręcę ciężko jest coś mówić, bo wychodzimy z różnych perspektyw.
1
Riddle napisał(a):
No jest cośtakiego jak PSR i PHPStan.
Ale nie rozumiem co to wnosi do mojej wypowiedzi?
To, że wypowiedzią pokazujesz ich nieznajomość. Piszesz, że umawiasz się w projekcie na to by IDE nie pokazywało błędów. Ale wyobraź sobie, że np. przy mergu nie zadziała to w ogóle. Czemu więc nie zapiąć lintera na innym poziomie jeszcze.
No i temat tyczy się ogólnych narzędzi a nie tylko linterów sprawdzających czy zamknięcie nawiasu jest w innej linii.
Jeśli upierasz się, przy swoim pokazujesz brak podstawowej znajomości tych narzędzi.
4
Jak dodam linter w moich programie teraz, to znajdzie powiedzmy 50 "złamań zasad", z czego 40 wcale nie będzie złamaniem, tylko normalnym użyciem, których linter nie jest w stanie skumać. Musiałbym wtedy dodać konfigurację pod to, żeby go wyciszyć- ale co mi to da? To że znajdzie dwie funkcje za długie, albo jedną out of date dependency? No dzięki
Tylko że ten linter skonfigurujesz raz, a będzie wspomagał cię przez całe życie projektu? :o
Generalnie koszt zintegrowania go jest niewielki, a wartość sensowna.
Im więcej można przerzucić na narzędzia, tym lepiej.
0
jurek1980 napisał(a):
Riddle napisał(a):
No jest cośtakiego jak PSR i PHPStan.
Ale nie rozumiem co to wnosi do mojej wypowiedzi?
To, że wypowiedzią pokazujesz ich nieznajomość. Piszesz, że umawiasz się w projekcie na to by IDE nie pokazywało błędów. Ale wyobraź sobie, że np. przy mergu nie zadziała to w ogóle. Czemu więc nie zapiąć lintera na innym poziomie jeszcze.
Nie nie. U mnie w projekcie każdy może sobie ustawić żeby IDE pokazywało błędy jakie chce. Jeśli ktoś chce lokalnie używać lintera to spoko, niech używa.
Co do konwencji kodu, to ja mówiłem że używamy ustalonego stylu formatowania przez auto-formatowanie w IDE.
Natomiast jestem przyciwny żeby dodawać linter do całej kontroli wersji i żeby takie checki dodawać np do builda w pipeline'ie albo brać je pod uwagę w CR. Jeśli ktoś chce używać linterów lokalnie to może, ale niech nie narzuca rad statycznej analizy kodu w kontekście człowieka który go czyta.
2
Riddle napisał(a):
Seken napisał(a):
No tak, to jest trade-off, pomiędzy tym co linter znajdzie, a tym co człowiek znajdzie. Faktycznie, czasem lintery mają reguły których człowiek nie zna - to na plus. Ale często też lintery mają głupie zasady, ale zasady które nie działają zawsze. Dodatkowo, człowiek też znajduje rzeczy których linter nie jest w stanie wykryć.
Dla mnie trade-off jest silnie przechylony w stronę człowieka.
Do tego sluzy konfiguracja lintera :)
No widzisz, tylko to się mija z celem. Bo ja chcę dodać do swoich projektów coś, co ma sens. A nie dodać coś co nie ma sensu (defaulty lintera), a potem je blokować (konfiguracją lintera).
Gdyby domyślne reguły lintera były bardzo trafne (np trafiałyby w 99.9% przypadków) to nie miałbym problemów z nimi. Ale tak nie jest. Jak dodam linter w moich programie teraz, to znajdzie powiedzmy 50 "złamań zasad", z czego 40 wcale nie będzie złamaniem, tylko normalnym użyciem, których linter nie jest w stanie skumać. Musiałbym wtedy dodać konfigurację pod to, żeby go wyciszyć- ale co mi to da? To że znajdzie dwie funkcje za długie, albo jedną out of date dependency? No dzięki.
Jak mówiłem. Linter to spoko narzędzie IMO jak znajduje dużo błędów w Twoim programie. Jeśli dodasz linter do pojrketu, i linter znajduje same false-positive, to nie ma sensu go używać IMO. A przynajmniej ja nie używam.
Okej czyli problemem w linterze jest to, ze musisz poswiecic pare godzin zeby go dobrze skonfigurowac?
To pewnie zależy od programisty, ale dla mnie 95% zasad domyślnie włączonych w linter to followuje je z automatu, i nie potrzebuje toola który mi to sprawdzi. Na palcach jednej ręki mogę policzyć miejsca w których linter faktycznie mi podpowiedział coś czego nie wiem; ale za to dużo więcej case'ów było kiedy linter podpowiadał mi jakiś bez sens.
Ja za to domyslnie pisze bezbledny kod i nie potrzebuje testow. Dodatkowo widzialem duzo testow, ktore w rzeczywistosci niczego nie testuja, a tylko betonuja implementacje. Swietna retoryka no nie?
Dobry argument - porównanie argumentu z nie używaniem lintera do nieużywania testów. Mam kilka odpowiedzi na to porównanie, nie wiem czy chcemy wchodzi w to.
Nie chcemy w to wchodzic, bo tu nie chodzi o porownanie lintera do testow tylko zobrazowanie Twojego podejscia, ktore jest eufemizem od "jestem tak zajebisty, ze nie potrzebuje [tutaj wstaw cokolwiek]".
Okej, mogę się zgodzić że ujednolicenie stylu kodowania to jest coś co linter jest w stanie zrobić. Ale w moich projektach zawsze wystarczyło uzgodnić ustawienia formatowania automatycznego, i potem się umówić że robimy auto-format plików przy commicie. Nic więcej nam nie było potrzebne.
No rzeczywiscie lepiej sie umowic na gebe, niz wstawic tego jednego joba wiecej w pipeline i miec pewnosc, ze nikt (zlosliwie lub nie) nie wrzuci czegos co lamie te reguly :D.
Nie chodzi o to czy to jest job w pipeline czy nie; i nie chodzi o to czy trudno jest coś takiego dodać. Bo faktycznie dodać linter jest banalnie prosto. Chodzi o to że to jest dodatkowa zależność, dodatkowa rzecz o której trzeba myśleć, dodatkowa rzecz którą trzeba wziąć pod uwagę, dodatkowa którą trzeba utrzymać i dodatkowa która może coś zepsuć.
Dodac jest latwo, skonfigurowac odpowiednio to robota na pare godzin zakladajac, ze musimy przecierac szlaki. To jest taka potezna zaleznosc, ze raz na rok walniesz update i tyle. Ja mysle wrecz odwrotnie, to jest rzecz dzieki ktorej nie trzeba myslec o wielu rzeczach.
Pomijając już to wszystko - rady lintera nie zawsze są poprawne. Czasem linter sugeruje dodanie czegoś co nie ma sensu - i jeśli jesteś seniorem, to wprowadziłbyś dobrą zmianę tak czy tak; a jak jesteś juniorem to nie potrafisz rozróżnić która rada lintera jest dobra a która nie.
Zakladajac ten wyidealizowany przyklad, ze senior pisze kod idealny, a junior sie myli. Skoro wprowadzi rade, ktora nie jest dobra to wyjdzie na review, junior sie douczy i juz wiecej nie bedzie tego powielac. Ja widze czysty profit, pomijajac fakt, ze te "bledne" rady lintera nigdy nie wystapia, bo mamy wszystko dobrze skonfigurowane :).
Jeśli jesteś zainteresowany poprawnymi zasadami, to moim zdaniem Pair Programming jest dużo lepszym narzędziem do tego niż analiza statyczna.
To jest porownywanie gruszek do jablek. Nie zawsze jest czas na pair programming, nie kazdy to lubi, nie kazdy tez potrafi przekazywac wiedze w sposob zrozumialy. Analiza kodu nie zabiera niczyjego czasu, jedynie go zaoszczedza. W pair programmingu jakis senior musialby poswiecic swoj czas (podczas ktorego zrobilby bardziej skonstrutywne rzeczy) na to zeby mi wyjasnic niektore sprawy, ale i tak jest to podejscie dorazne, bo bede zajmowac sie czyms innym to znowu bedzie musial mi tlumaczyc cos innego itd. Abstrahujac od tego, ze senior moze byc jakims zasiedzialym korposzczurem, ktorego umiejetnosci sa delikatnie mowiac kiepskie.
A jak do projektu wchodzi nowa osoba to tez latwiej przypominac niz sprawdzac po jobie?
Jak nowa osoba wchodzi do projektu, to i tak ją trzeba onboardować, i do tego celu Pair Programming też jest dużo lepszy niż jakikolwiek statyczny tool.
Znowu porownywanie gruszek do jablek. Tu nie chodzi o onboarding tylko nowa osoba jest z reguly przytloczona iloscia wiedzy jaka musi przyswoic, dorzucanie jej jakichs regul, o ktorych musi pamietac zamiast trzymac je w linterze to niepotrzebny wymysl.
btw. Zmienialem prace raczej czesto i nikt mnie w ten sposob nigdy nie onboardingowal. Jasne, zdarzaly sie sytuacje ze czegos w zadaniu nie rozumialem i potrzebowalem podpowiedzi albo szerszego kontekstu, ale nikt ze mna nie siedzial na callu pare godzin zeby razem ze mna to naklepac i poprawnie przetestowac. Pewnie byloby to fajne, ale teoria odbiega znaczaco od rzeczywistosci.
(...)
Mam pomysł jak możemy to rozwiązać. Co powiesz na taki pomysł:
- Ty wklej kilka przykładów z Twojego doświadczenia, gdzie linter był pomocny. Ja wkleję kilka miejsc w których linter zrobił coś bardzo głupiego, i porownamy je. Bez przykładu na ręcę ciężko jest coś mówić, bo wychodzimy z różnych perspektyw.
Linter to tylko narzedzie, ja Ci wkleje pare przykladow gdzie ktos napisal glupie testy i o czym to swiadczy? Tylko wylacznie o tym kto to pisal (konfigurowal).
Nie chce sie bawic w zadne przyklady w zycia wziete. Nie jestem zadnym akwizytorem coverity czy sonarQube zeby Cie na sile do tego przekonywac, bo mam wrazenie ze jestes po prostu uprzedzony. Jesli temat Cie interesuje to mysle, ze w internecie znajdziesz o wiele lepsze przyklady niz jakies tam moje :).
WeiXiao napisał(a):
Im więcej można przerzucić na narzędzia, tym lepiej.
To jest podsumowanie w jednym zdaniu mojego podejscia i argumentem dlaczego warto.
btw. Mam nadzieje, ze mowiac linter myslimy o narzedziach do statycznej analizy kodu typu coverity, sonarqube itd
btw2. Te narzedzia oprocz "dorazniej" pomocy zawieraja tez mase metryk. Pozwala to wyciagnac pewne wnioski na podstawie tego jak zmienila sie jakosc kodu w przeciagu ostatniego czasu/featurow.
5
Nie no, bez jaj. Nawet na defaultowych ustawieniach taki Sonar wykrywa więcej błędów niż człowiek robiący review.
Największymi problemami przy tego typu narzędziach jest to, że często zarządza nimi jakiś firmowy uberarchitekt, i ustawia reguły z czapy. Albo nawet sensowne, ale nie dla każdego zespołu/projektu.