Wpis z mikrobloga

Biore temat stad https://www.wykop.pl/wpis/56976117/#comment-202896093 do nowego watku, bo nie bede sie rozpisywal w watku jakiej #!$%@? zielonki, ktora kasuje posty jak ja pojedziesz. xD

Code review, sonar ani nawet papież nie sprawdzi czy kod, który jest napisany będzie działać. Co z tego ze jest ładny jak logicznie to może być kaszana. Na review nikt nie zagłębia się w to jakie dane wchodzą z jakiegoś serwisu czy z pliku.


@kubelek-classic: To oczywiscie bzdura absolutna. Od tego masz QA testy, ktore sprawdzaja nie tylko dokladnie, czy dana funkcjonalnosc dziala, jest zgodna z tym co bylo oczekiwane, to jeszcze czy nic innego sie nie #!$%@?. IT testy tez wykryja czy nic nie zmienilo sie w obszarze dzialania danej funkcjonalnosci, a jak nie to sa #!$%@? napisane.

#programista15k #scrum #java
  • 21
Co z tego ze jest ładny jak logicznie to może być kaszana. -> kto to napisal? xD
albo ja nie rozumiem, albo on tutaj napisal, ze masz w jirce czytanie pliku zrobic, zamist tego piszesz przepiekne zapisywanie do pliku i nikt tego nie wylapuje? Przeciez to nawet gdyby malpe jako QA posadzic to by to znalazla
@Hatespinner: @kubelek-classic
Sonar upewni się, że kod jest zgodny z ogólnie przyjętymi wzorcami.
Code review sprawdzi, czy tego co zakodowałeś nie lepiej zakodować nieco inaczej (bo może ci brakuje jeszcze znajomości domeny)
Unit testy sprawdzą czy twoje klasy w izolacji robią to co powinny robić

Od sprawdzania tego, czy ogólnie serwis zrobi to co powinien są testy na wyższym poziomie - integracyjne, end-to-end, może testy kontraktowe, może po części performance testy.
@Hatespinner: ja kiedys pracowalem w firmie, w ktorej nie bylo ani testow ani QA, taka wewnetrza apka ale wtedy biznes wszystko lapal. Troche jakby testowanie bylo przesuniete na produkcje ale to mala firma, nie bylo zadnych krytycznych danych itd. Teraz pracuje dla banku i nim moj kod wejdzie na proda to jest testowany przeze mnie, potem QA na ich srodowisku, potem BA na jeszcze innym srodowisku wiec ryzyko release syfu jest
@93michu93: Ja kiedyś pracowałem w takiej gdzie nie było żadnych testów, bo prezes zakładał, że należy od razu pisać działający kod a testy nie przynoszą pieniędzy. Nikt nie słyszał o wynalazkach jak Jenkins, Sonar.

Ale sam fakt ile się zarabia w takich firmach i jaka jest ich renoma, daje wiele do myślenia na temat tego czy powinny być stawiane jako wzorzec.
@Hatespinner: zgadzam się z tym prezesem, trzeba odrazu pisać działający kod, testy nie przynoszą pieniędzy, tylko koszty. To bardzo dobre podejście w produkcie który ma mniej niż 3miesiące i naganne w projekcie który ma ponad rok. Wszystko zależy od tego czy oprogramowanie jest w stanie zarobić na testy i zgodny z ogólnie przyjętymi dobrymi praktykami proces wytwarzania oprogramowania. Czasem jest tak że albo zasady te zostaną pominięte(najlepiej tylko w początkowej fazie)
zgadzam się z tym prezesem, trzeba odrazu pisać działający kod


@zibizz1: Widać jak takie podejście się sprawdza po tym, ile zarabia się z taką mentalnością i jakich masz klientów.

Do tego takie firmy siedzą w jakimś gównie typu Java 7 do teraz, bo przecież lepiej sprzedać gównianą aplikacje klientowi dzisiaj, niż wprowadzić usprawnienia na za miesiąc.

Co więcej, w wielu firmach, jak masz soft sprint end, to nie robisz w ogóle
@Hatespinner: > Ludzie z tamtego wątku nie słyszeli chyba o QA testach, albo nie wiedzą jak to działa, więc myślę że tu leży problem.

Myślę, że się trochę zesrałeś i koniecznie chcesz wszystkim teraz powiedzieć "patrzcie wszyscy, jacy oni są głupi, nie to, co ja w mojej firmie" Albo dopiero wchodzisz na rynek i jesteś zachłyśnięty tym wszystkim, albo po prostu masz taki nieprzystępny sposób bycia, że patrzysz na wszystkich z
Do tego takie firmy siedzą w jakimś gównie typu Java 7 do teraz, bo przecież lepiej sprzedać gównianą aplikacje klientowi dzisiaj, niż wprowadzić usprawnienia na za miesiąc.


@kubelek-classic: nie siedzę w Javie, ale co jest złego w tym, że używasz starej Javy, skoro dalej działa i się sprzedaje w obecnej formie? Po co dokładać kosztów na aktualizację. Jeśli przetwarzasz jakieś ważne dane i są jakieś poważne luki bezpieczeństwa to okej, ale
nie siedzę w Javie, ale co jest złego w tym, że używasz starej Javy, skoro dalej działa i się sprzedaje w obecnej formie? Po co dokładać kosztów na aktualizację. Jeśli przetwarzasz jakieś ważne dane i są jakieś poważne luki bezpieczeństwa to okej, ale aktualizacja dla samej aktualizacji to raczej nie jest najmądrzejsze posunięcie. ( ͡° ͜ʖ ͡°)


@kubelek-classic: aktualizacja dla samej aktualizacji ma sens i to wielki,
@93michu93: jeśli chcesz rekrutować nową osobę do takiego projektu to albo mówisz że jej zadniem będzie ta aktualizacja, albo sam robisz aktualizację. Wtedy powodem nie jest "aktualizacja dla aktualizacji" tylko dalszy rozwój aplikacji.
co jest złego w tym, że używasz starej Javy, skoro dalej działa i się sprzedaje w obecnej formie?


@kubelek-classic: to sie kloci z tym co wczesniej napisales, powodem nie jest dalszy rozwój aplikacji tylko znalezienie kogos kto nawet bedzie ci utrzymywal ta apke. Aktaulizacja dla samej aktualizacji jest mega wazna. Zaczynasz sobie kodzic w javie 7, mija 5 lat nie podbijasz bo nie musisz, ale w koncu czegos potrzebujesz z javy
Myślę, że się trochę zesrałeś i koniecznie chcesz wszystkim teraz powiedzieć "patrzcie wszyscy, jacy oni są głupi, nie to, co ja w mojej firmie" Albo dopiero wchodzisz na rynek i jesteś zachłyśnięty tym wszystkim, albo po prostu masz taki nieprzystępny sposób bycia, że patrzysz na wszystkich z góry.


@kubelek-classic: Myślę że w dupie mam twoją opinię o tym co ja myślę. Mówię o metodologii pracy, nie tylko w mojej firmie, ale
@93michu93: być może nie znam po prostu środowiska Javy, ale nigdy nie słyszałem nigdy, żeby ktoś "potrzebował czegoś" w wyższej wersji języka programowania. Za to wiele razy "niekompatybilne z najnowszą wersją" ( ͡° ͜ʖ ͡°)
nie siedzę w Javie, ale co jest złego w tym, że używasz starej Javy, skoro dalej działa i się sprzedaje w obecnej formie?


@kubelek-classic: Wszystko. Bo jak pracujesz w starej, #!$%@? Javie to nie mozesz rozwijać oprogramowania? Jak nie możesz rozwijać oprogramowania to nie będziesz miał więcej userow/klientów, nie dasz rady go skalować, stracisz czas na tworzenie bzdurnych rozwiązań, zamiast skorzystać z gotowych, w późniejszych wersjach. #!$%@? miliard powodów. Nie mówimy