Kiery refaktoryzujecie cudzy kod?

0

Jeśli wszystko jest napisane bardzo prostacko, ale dzięki temu bardzo czytelnie i dostajesz zadanie by poprawić małą cześć kodu. To refaktoryzujesz cały kod?

1

Twoje pytanie zawiera za duzo domyslow

jest napisane bardzo prostacko, ale dzięki temu bardzo czytelnie

podaj przyklad, bo jezeli jest napisane prosto i czytelnie to nie widze sensu refaktoryzacji takiego kodu.

9

Analiza:

  1. Działa: nie ruszać
  2. Działa, ale brzydkie: nie ruszać
  3. Działa, brzydkie i trzeba coś tam dopisać:
  • jeśli jest czas i nudzi Ci się - pograj w jakąś grę, pamiętaj o skrócie Win+D, na Pulpicie ustaw tapetę ze zrzutem ekranowym z IDE z otwartym kodem, nikt się nie pokapuje o ile nie masz za dużo ikonek, co parę dni zmieniaj tapetę bo głupio patrzeć ciągle na ten sam fragment kodu,
  • jeśli dostaniesz za to kasę - refaktoryzować (jeśli płacone od godziny - refaktoryzować powoli),
  • jeśli nie ma czasu: nie ruszać, dopisać równie brzydkie,
  • jeśli blokuje dopisanie: nie masz wyboru, refaktoryzować

To nie jest łyżwiarstwo figurowe, że dostajesz punkty za styl :P A tak zupełnie szczerze, to jeśli nie masz czegoś w zakresie obowiązków, to nie rób tego, w 99,99% przypadków stanie się to nagle Twoim obowiązkiem i będziesz pół systemu refaktoryzować. Sam się tak lata temu wrobiłem, chcąc pokazać jaki to zdolny jestem. To jest prosta droga jak szybko awansować na lokalnego murzyna.

0
Julian_ napisał(a):

... by poprawić małą cześć kodu. To refaktoryzujesz cały kod?

Tak, zwłaszcza jak mam na to 2 dni i kilka tysięcy linijek kodu.

5

praktycznie zawsze, nie wyobrazam sobie po prostu dodac kolejnego, zagniezdzonego ifa.

11

Zasada harcerzy czy jakoś tak. Za każdym razem, gdy ruszasz jakikolwiek kod to zostaw go w lepszym stanie niż go zastałeś.

1

Co oznacza "cały kod"? Metodę, klasę, funkcję, projekt, system?

Jeśli mam dopisać coś w metodzie i widzę że jest tam coś do poprawy to poprawiam- na pewno nie piszę kodu w takim samym stylu. Jeśli mam czas to poprawiam całą klasę. Poza tym w projekcie w którym aktualnie jestem (system pisany od zera wykluczając zewnętrzne firmowe biblioteki) mamy ścisłe wymuszanie standardów i jeśli coś może zostać napisane lepiej to w IDE pojawiają się ostrzeżenia a w niektórych przypadkach kod się nawet nie skompiluje. Niektóre standardy mi się osobiście nie podobają i w domowych projektach stosuję inne ale uważam że dobrze mieć jakiś mechanizm w pracy zapewniający konsekwentność kodu.

0
fasadin napisał(a):

Twoje pytanie zawiera za duzo domyslow

jest napisane bardzo prostacko, ale dzięki temu bardzo czytelnie

podaj przyklad, bo jezeli jest napisane prosto i czytelnie to nie widze sensu refaktoryzacji takiego kodu.

przykład:

# add a to b
a <- 5
b <- 4
result <- a + b


#check if result ok
if(result < 0) {
  return (-1)
}

return (result)

to byś refaktoryzował na:

addAToB <- function(a = 5, b = 4) {
  return(a + b)
}

checkIfResultOK <- function(result) {
  if(result < 0) {
    return (-1)
  }
return (1)
}

result <- addAToB()
return (ifelse(checkIfResultOK(result), result, -1))

??

3

@Julian_: to jest przyklad na obfuskacje a nie refaktoryzacje. podziwiam zapal do trollpostow :)

refaktoring to byloby zrobienie nazwanej stalej o wartosci == 9

1

refaktoryzuję tylko wtedy kiedy widzę R, czyli nigdy

0

Muszę ocenić czasowo jak to wygląda. Jeśli jest to mała poprawka to piszę ifa i tyle. Jeśli większa to niestety zaczyna się kombinowanie...
Ogólnie przez moją kariere nie widziałem jeszcze systemów napisanych dobrze. Łatwo również powiedzieć jak ma się własny projekt na wyłączność - gorzej jak się pracuje zespołowo. Jeśli używasz jakiś wzorców, starasz by kod jakoś wyglądał, a masz takich co uważają że "kod ma działać, a nie wyglądać" to jeszcze będą na Ciebie narzekać że używasz jakiś rzeczy bez sensu i po co w ogóle jakaś strategia jak można ifa użyć. Tak samo jak pracujesz z ludźmi copy paste - jak mam 2 takie same moduły tylko różnią się jakimś szczegółem to po co używać wspólnego kodu do tego. Lepiej skopiować kod, bo przecież "bo jak się zepsuje w jednym miejscu to drugie będzie działać xD" .

0

Dzięki Bogu, że pracuję z dobrym jakościowo kodem, więc rzecz jasna kod nie przejdzie review jeśli nie będzie dobry. xD

0

Gdy kod jest nieczytelny dodaję komentarz. Refaktoruje wtedy gdy poprawka zajmuje mi bardzo mało czasu lub gdy widzę, że w miarę krótkim czasie mogę znacznie przyspieszyć działanie określonej funkcjonalności.

2

Dziwne pytanie - nigdy nie refaktoryzuję cudzego kodu, bo zwyczajnie nie mam do niego dostępu. Kod, w projektach, w których biorę udział to kod zespołowy, więc nie jest cudzy - należy do zespołu, a więc i do mnie.
Kodu, który jest czytelny też nie ma sensu refaktoryzować. Refaktoryzacji wymaga kod, który jest nieczytelny i nie da się go rozwijać. Jeśli zatem mam jakieś zadanie, którego nie jestem w stanie wykonać ze względu na obecną strukturę kodu, to oczywiste, że muszę najpierw zrefaktoryzować.

1

ja na początku miałem w zwyczaju refaktorowanie cudzego kodu w trakcie naprawiania błędów, ale teraz staram się tego nie robić, moje przemyślenia na ten temat:

  • refaktorowanie najczęścięj robią osoby które zaczynają pracę w zespole
  • refaktorowanie nie ma żadnej wartości z perspektywy biznesowej
  • prawie każdemu programiście na starcie wydaje się że kod którego sam nie napisał działa dziwnie, jest przekombinowany albo że ktoś brzydko pisze
  • każdy ma inny styl pisania kodu i nie ma jedynego dobrego sposobu na napisanie czegoś - to co dzisiaj jest ok jutro może nie być, a to co dzisiaj jest ok jest subiektywne
  • napisanie kodu bez znajomości wymagań jest kilka(nasto?)krotnie trudniejsze niż znając je - druga wersja kodu zawsze jest łatwiejsza do napisania bo większość problemów jest znana z góry, ale prawie zawsze złym pomysłem jest przepisywanie od zera
  • najlepszy kod jest taki który działa, możesz mieć ładny kod, ale jest to bez znaczenia jeśli nie ma jakiegoś 'ficzera' albo nie działa
  • najlepiej robić minimum tego co jest potrzebne, żeby coś działało poprawnie
  • część z powyższych rzeczy zmienia się jeśli piszesz biblioteke gdzie backward compat to problem - wtedy wszystkie publiczne API powinny być dobrze zaprojektowane, ale i tak z perspektywy czasu może się okazać, że nie są i ciężko przewidzieć co będzie w przyszłości
  • niektórzy ludzie są terytorialni jeśli chodzi o kod i z jakiegoś powodu się denerwują jak im coś zmieniasz
6
krwq napisał(a):
  • refaktorowanie nie ma żadnej wartości z perspektywy biznesowej

Tylko dla krótkowzrocznego PM. I to tylko dopóki nie przychodzi ten moment, w którym aplikacji nie da się dalej rozwijać w sposób bezpieczny, a błędy na produkcji powodują coraz straty finansowe.
Refaktorowanie to spłacanie długu technicznego. A dług techniczny prędzej czy później daje się przeliczyć na pieniądze:

  • zwiększone koszty utrzymania infrastruktury;
  • zwiększone koszty pracy:
    • bo zadania zajmują więcej niż powinny;
    • więcej ludzi, albo drożsi pracownicy, bo nikt nie chce pracować w kupie;
  • i wreszcie wydatki na zwroty i odszkodowania dla klientów.
  • prawie każdemu programiście na starcie wydaje się że kod którego sam nie napisał działa dziwnie, jest przekombinowany albo że ktoś brzydko pisze

No tu zgoda, początkujący tak właśnie myślą. Dlatego ja uważam, że w poważnej pracy trzeba się od początkujących trzymać z daleka.

  • każdy ma inny styl pisania kodu i nie ma jedynego dobrego sposobu na napisanie czegoś - to co dzisiaj jest ok jutro może nie być, a to co dzisiaj jest ok jest subiektywne

Styl owszem, ale dobre zasady to nie kwestia stylu. A refaktoryzowanie to jest poprawianie tych części kodu, dla których ma to sens w sposób zrozumiały dla całego zespołu, a nie przepisywanie wszystkiego po swojemu.

  • najlepszy kod jest taki który działa, możesz mieć ładny kod, ale jest to bez znaczenia jeśli nie ma jakiegoś 'ficzera' albo nie działa

Tak, ale z drugiej strony, kod, który jest brzydki ale działa staje się problemem, gdy dodanie nowego ficzera w sensownym czasie i z akceptowalnym ryzykiem okazuje się niemożliwe.

  • najlepiej robić minimum tego co jest potrzebne, żeby coś działało poprawnie

To jakiś cytat z budowniczych blokowisk na Ursynowie?

  • niektórzy ludzie są terytorialni jeśli chodzi o kod i z jakiegoś powodu się denerwują jak im coś zmieniasz

Na to jest tylko jedna rada - opuścić przedszkole.

2
  • refaktorowanie najczęścięj robią osoby które zaczynają pracę w zespole

w sumie to nie wiem czy jest tu jakas regula, jedni rzeczywiscie traca do tego zapal, inni zaczynaja robic wieksze zmiany w miare zrozumienia projektu.
ja czesto robie refaktoring po to zeby zrozumiec jak dziala kod, jakie sa zaleznosci itp (czesto konczy sie to revertem wiekszosci zmian)

  • refaktorowanie nie ma żadnej wartości z perspektywy biznesowej

jest to zrozumiale o tyle ze zysk z refactoringu ciezko uzasadnic i wrzucic na kolorowy wykres podczas prezentacji.
jiry ktorych jedynym zadaniem jest poprawienie jakosci kodu maja male szanse na bycie wysoko w kolejce priorytetow dlatego imo powinno sie go robic jako czesc innych taskow.
btw. najgorsi sa userzy ktorzy troche ogarniaja programowanie albo co gorsze znaja projekt i daja estymacje "to dolozysz ifa w 2 miejscach i bedzie" :)

  • prawie każdemu programiście na starcie wydaje się że kod którego sam nie napisał działa dziwnie, jest przekombinowany albo że ktoś brzydko pisze

to prawda, stwierdzanie ze cudzy kod jest "dostatecznie dobry" przychodzi z doswiadczeniem, ale niestety w praktyce okazuje sie ze kod jest calkiem zly a ludzie zamiast cos z tym zrobic to powielaja kiepskie standardy piszac nowe funkcjonalnosci.
jestem w stanie zrozumiec brak refaktoringu gdy kod jest znosny a problem wyniknal z tego ze autor cos przeoczyl. mysle ze czesciej jednak programisci dodaja pare linijek kodu i ciesza sie ze zalatwili sprawe, podczas gdy nawet nie zrozumieli o co naprawde chodzi i co mozna zrobic zeby tego typu problemow uniknac.

  • każdy ma inny styl pisania kodu i nie ma jedynego dobrego sposobu na napisanie czegoś - to co dzisiaj jest ok jutro może nie być, a to co dzisiaj jest ok jest subiektywne

jasne, ale refaktoring nie powinien polegac na narzuceniu swojego stylu, tylko na narzuceniu dobrych praktyk. oczywiscie ktos kto np. wali globalami bo tak mu wygodnie bedzie argumentowal ze jest prosciej, szybciej, zgodnie z wiekszoscia istniejacego kodu, ze to tylko dodatkowe 50 linijek brzydkiego kodu do 3k linijek juz w tej klasie zawartych itd itp i kazdy inny len mu przyzna racje :)

  • napisanie kodu bez znajomości wymagań jest kilka(nasto?)krotnie trudniejsze niż znając je - druga wersja kodu zawsze jest łatwiejsza do napisania bo większość problemów jest znana z góry, ale prawie zawsze złym pomysłem jest przepisywanie od zera

jasne, ale nie ma co przepisywac od zera - chodzi o np wyodrebnienie funkcjonalnosci nad ktora wlasnie pracujemy a nie dodanie tego samego ifa w 5 miejscach

  • najlepszy kod jest taki który działa, możesz mieć ładny kod, ale jest to bez znaczenia jeśli nie ma jakiegoś 'ficzera' albo nie działa

dlatego tak jak napisalam wyzej - tworzenie extra "cleanup" taskow nie ma zbytniego sensu, bo nikt na to nie da pieniedzy. trzeba poprawiac jakosc kodu na biezaco.

  • najlepiej robić minimum tego co jest potrzebne, żeby coś działało poprawnie

zgadzam sie jesli masz na mysli unikanie przeinzynierowania, jesli chodzi o np fixowanie bugow to takie podejscie czesto procentuje jeszcze wieksza ich iloscia i ciaglym wracanie to tych samych, gownianych kawalkow kodu

  • niektórzy ludzie są terytorialni jeśli chodzi o kod i z jakiegoś powodu się denerwują jak im coś zmieniasz

nawet lubie takie sytuacje z kumatymi ludzmi bo prowokuje to merytoryczne dyskusje. durniow trzeba w takich sytuacjach olewac i robic swoje (chyba ze oni maja wieksze uprawnienia do repo to pozostaje uderzenie do tech leada lub zmiana pracy)

0

Tak btw wczoraj odkryłem metodę która ma 800 linii kodu, zagnieżdżone pięć ifów potem while, foreach... Głupia wtyczka do slidera.. Oczy mnie do teraz bolą

0

u mnie to zależy od budżetu ;)

0

Jeśli nie ma budżetu na to żeby poprawiać na bieżąco kod, przy okazji dodawania nowych rzeczy, albo (szczególnie) przy naprawianiu bugów - to trzeba montować spierdolkę. Nawet jak jest czas, to ciężko utrzymać systemy w jakimś porządku (bo to trudne, wielu developerom się po prostu nie chce). Jak biznes nie daje na to czasu/lkasy to w zasadzie jest jasne jak to się kończy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1