[SiemkaKolego]

Hejka, jeśli macie jakąś metodę na 500 linii albo i więcej z zawiłą logiką biznesową, gdzie musicie pod koniec takiej metody coś dopisać, to sprawdzacie od samego początku czy jakiś obiekt może być nullem czy nie, czy może z automatu dajecie ifa który to sprawdza bez analizowania setek linii kodu wstecz (bo może jednak dany obiekt nie będzie nigdy nullem więc nie trzeba tego ifa)?

Przyznam się że czasami mi się nie chce analizować tego i wstawiam to zabezpieczenie ale nie wiem czy to dobra praktyka, stąd pytanie :)

#java #programowanie

[leoha]

@SiemkaKolego: po pierwsze staramy sie zrozumiec co to 500 lini robii, poznirj refaktorujemy na krotsze metody zgodnie z zasadna zostaw kod wlepszym stanie niz go zastales i wtedy dopisujemy logike.

[Kolorowezworki]

@SiemkaKolego: Takie długie metody tylko w Javie mogą być chyba xd

[63274682374]

po pierwsze staramy sie zrozumiec co to 500 lini robii, poznirj refaktorujemy na krotsze metody zgodnie z zasadna zostaw kod wlepszym stanie niz go zastales i wtedy dopisujemy logike.

@leoha: ...w idelanym świecie. W rzeczywistości raczej nie ma czasu na poprawianie babola, który był już zmieniany pewnie kilka razy. Jeśli metoda ma 500 linii to raczej od ręki się tego nie zrefaktoryzuje tzn da się, ale sama ta metoda zajmie więcej

[j.....6]

@SiemkaKolego: jak masz metodę na 500 linii to świadczy że niezły #!$%@? w repo macie, kto pozwolił na takie coś?

[markaron]

@63274682374: Niekoniecznie, zależy co ta metoda robi, bo często te długie metody wyglądają tak:

if (warunek1) {
 // 50 linii kodu
} else if (warunek2) {
 // 50 linii kodu
} else if (warunek3) {
 // 70 linii kodu
} else {
 // 40 linii kodu
}

i przez zwykłą ekstrakcję metody może wyglądać tak:

if (warunek1) {
 metoda1();
} else if (warunek2) {
 metoda2();
} else if (warunek3) {
 metoda3();

[PaaD]

@SiemkaKolego: jeśli metoda jest "pure-function" (nie puka po innych serwisach itp) to można ją pokryć testami - przynajmniej dla swojego nowego scenariusza, i może jakiegoś z rzeczywistymi parametrami (np. spisanymi podczas debugowania), żeby upewnić się że nie popsuje się czegoś co działało... a potem jeśli mamy natchnienie i czas to można robić porządny refaktor: zapewnić coverage i sprawdzać czy cały działa po "poprawkach" ( ͡° ͜ʖ ͡°)

[markaron]

@whoru: Dokładnie tak

[SiemkaKolego]

ale spokojnie, ja wiem że fajnie byłoby metodę zrefaktoryzować, pociąć, potworzyć jakieś osobne klasy, serwisy czy co tam jeszcze człowiek wymyśli ale to jest legacy projekt i ja mam zadanie wyestymowane na 2 dni a wy mi tu mówicie że najlepiej by było to przepisać :D

Ktoś tam wyżej napisał że dobrze by było przeanalizować metodę przed swoją robotą - jak najbardziej, ale nie śledzę wtedy pojedynczego obiektu czy pola przez setki

[j.....6]

jeśli metoda jest "pure-function" (nie puka po innych serwisach itp) to można ją pokryć testami - przynajmniej dla swojego nowego scenariusza, i może jakiegoś z rzeczywistymi parametrami (np. spisanymi podczas debugowania), żeby upewnić się że nie popsuje się czegoś co działało... a potem jeśli mamy natchnienie i czas to można robić porządny refaktor: zapewnić coverage i sprawdzać czy cały działa po "poprawkach" ( ͡° ͜ʖ ͡°)

@PaaD:

[PaaD]

niemożliwe by kod na 500 linii nie miał side effects

@jaca_66: "Hope all is good my friend" i wtedy kod może nawet nie mieć żadnych effects ( ͡° ͜ʖ ͡°)

[63274682374]

Niekoniecznie, zależy co ta metoda robi, bo często te długie metody wyglądają tak:

@markaron: hehe no no, i jak metoda miała 100, 200, 300 linii to nikt nie wpadł na refaktoryzację... ale jasne licznik wybił 500 i mamy pojedynczo zagnieżdżonego if'a bez wzajemnych zależności między gałęziami... real life scenario.
Jest dokładnie na odwrót, często to występują takie metody, które powstają miesiącami i latami i są mocno skomplikowane nie dlatego, że ktoś

[markaron]

@63274682374: Oczywiście, że ktoś mógł wpaść na pomysł żeby zrobić refaktoryzację. Pytanie czemu ona nie została wykonana? Odpowiedź najczęstsza z możliwych czyli ciśnienie na dowiezienie buga/ficzera kosztem jakości.

Co do reszty Twojej wypowiedzi to zdarzają się metody takie jak pokazałem, jak i metody bardziej złożone o których Ty piszesz. Które wystepują częściej? Trudno jednoznacznie powiedzieć. Ja odniosłem się do swoich doświadczeń, Ty do swoich. Prawda jak zawsze w takich sytuacjach jest

[63274682374]

@markaron: Bardzo wyważona odpowiedź. Trudno się z nią nie zgodzić, więc nie będę nawet próbował ;)

[wpiot]

@SiemkaKolego: Wstawianie takich zabezpieczeń nazywa się defensive programming i jeśli masz mało czasu i jest to legacy to warto tak robić zawsze, bo to, że teraz nie ma nulla nie znaczy, że nie pojawi się za tydzień :)

[SiemkaKolego]

@wpiot: no i w końcu ktoś odpowiedział na moje pytanie :D dzięki :)