Kiedy refaktoryzować


32

Przeczytałem większość książek o refaktoryzacji Fowlera i dokonałem refaktoryzacji wielu aplikacji w mojej dużej i małej przeszłości.

Jedną z trudniejszych rzeczy, których nauczam, jest „kiedy” refaktoryzować. Zwykle robię to w oparciu o przeczucie, które w przeszłości służyło mi wyjątkowo dobrze. Jednak kiedy wchodzimy w dyskusje z ludźmi na temat tego, czy fragment kodu należy teraz zostawić w spokoju, czy zrekonstruować, trudno jest trzymać się „kontroli jelita”.

Wydaje mi się, że powinny być do tego bardziej rygorystyczne podejścia, ale nie jestem pewien, czym one są.

Rozumiem „zapachy kodowe”, refaktor czerwono-zielony i inne myśli, ale często wydaje mi się, że najlepszym czasem na refaktoryzację nie jest pierwszy raz, kiedy piszesz kod, ale drugi lub trzeci raz, kiedy używasz kodu i zdajesz sobie sprawę że tak naprawdę jest to problem i jest w użyciu.


2
Zasadniczo pytasz o to samo: programmers.stackexchange.com/questions/6268/… . Tyle że próg podjęcia działania jest niższy, ponieważ koszty i ryzyko są niższe, prawda?
S.Lott,

Odpowiedzi:


22

Refaktoryzuj, gdy koszt refaktoryzacji jest mniejszy niż koszt braku refaktoryzacji.

Zmierz „koszt”, jakkolwiek możesz. Na przykład, czy kod jest tak słabo zaimplementowany, że usunięcie drobnych błędów zajmuje wiele godzin lub dni? Czy refaktoryzacja pozwoli Ci zdobyć więcej klientów, zwiększyć wydajność lub poprawić wydajność, a tym samym uszczęśliwić obecnych klientów?


krótki i idealny
ZJR

8
Innymi słowy: „warto refaktoryzować, kiedy warto refaktoryzować”. Duh. Cóż, to naprawdę nie jest odpowiedź, prawda :) Measure "cost" however you can.- OK, jak? Czy to nie jest sedno pytania? Jaką perspektywę czasową należy zastosować, mierząc ten koszt?
Konrad Morawski

2
@ Morawski: nie, to niepoprawna parafraza. Powiedziałem, że warto refaktoryzować, jeśli wartość otrzymana z refaktoryzacji jest większa niż koszt refaktoryzacji. To nie to samo, co powiedzenie „warto refaktoryzować, kiedy warto refaktoryzować”. Oblicz koszt refaktoryzacji. Oblicz koszt braku refaktoryzacji. Które jest większe?
Bryan Oakley,

@BryanOakley: problem polega na tym, że nie można „obliczyć” tych kosztów. Możesz je w najlepszym razie oszacować, co jest naprawdę trudne, jeśli chodzi o koszt braku refaktoryzacji . Jaki multiplikator kosztów utrzymania stosuje się w przypadku wersji nierefrakcjonowanej w porównaniu z wersją refaktoryzowaną? Skąd wiesz, czy dany kod będzie musiał zostać w ogóle zachowany lub zmieniony? Jak oceniasz liczbę błędów, które wygeneruje? W końcu wydaje się, że wszyscy nieświadomie dokonujemy tego rodzaju szacunków w ramach naszego procesu decyzyjnego, gdy myślimy o refaktoryzacji, ale nie można oczekiwać od niego dokładności.
guillaume31

1
@ ian31: prawda, nie można obliczyć wartości, a najlepsze, co możesz zrobić, to oszacować. Jest to jednak jedyny naprawdę słuszny sposób podjęcia decyzji, czy dokonać refaktoryzacji, czy nie, zakładając, że masz ograniczony czas i zasoby. Musisz zdecydować, czy refaktor jest tego wart. To, jak definiujesz „wartość”, jest bardzo niedokładną nauką. Chodzi o to, że nie powinieneś refaktoryzować przeczucia - powód powinien być inny niż „Chcę, żeby kod był ładniejszy”.
Bryan Oakley

12

  1. Czy cykliczna złożoność funkcji jest mniejsza niż 5?
  2. Czy całkowicie zrozumiałeś, czym była złożoność cykliczna bez podążania za tym łączem?
  3. Czy masz zautomatyzowany test lub udokumentowany przypadek testowy dla każdej ścieżki w funkcji?
  4. Czy wszystkie istniejące przypadki testowe przeszły pomyślnie?
  5. Czy możesz mi wyjaśnić funkcję i wszystkie jej najważniejsze przypadki w mniej niż 1 minutę?
  6. Jeśli nie, to może około 5 minut?
  7. 10 minut?
  8. Czy w funkcji jest mniej niż 100 linii kodu (w tym komentarze)?
  9. Czy możesz znaleźć dwóch innych programistów, którzy zgadzają się, że ten kod jest wolny od błędów tylko poprzez kontrolę wizualną?
  10. Czy ta funkcja jest używana tylko w jednym miejscu?
  11. Czy funkcja spełnia założone cele dotyczące wydajności (czas / pamięć / procesor)?

Punktacja

Dodaj odpowiedzi „nie” powyżej:

  • 0-1 - Dlaczego w ogóle pomyślałbyś o refaktoryzacji? Prawdopodobnie chcesz po prostu zmienić nazwę zmiennych, ponieważ nie lubisz konwencji nazewnictwa poprzedniego programisty
  • 2-5 - Może to wymagać drobnych poprawek, ale nie wstrzymałbym wydania produkcyjnego dla czegoś z tego zakresu
  • 6-8 - OK, prawdopodobnie musimy to naprawić ... Prawdopodobnie będziemy to robić ponownie i / lub tak naprawdę nie wiemy, co robi. Nadal na płocie, ale to bardzo podejrzane
  • 9+ - Jest to główny kandydat do refaktoryzacji. (Uwaga: pisanie przypadków testowych jest formą refaktoryzacji)

http://mikemainguy.blogspot.com/2013/05/when-to-refactor-code.html


4
# 2 brzmi bardzo snobistycznie i jest właściwie bezużyteczny do oceny kodu . # 3 i # 4 nie każda firma stosuje testy jednostkowe. # 8 Unikaj komentarzy tam, gdzie to możliwe, a 100 linii jest zbyt wysoka. Mam 1 duży monitor panoramiczny w trybie portretowym i ledwo będę w stanie zobaczyć całą funkcję na raz. Jeśli jest to więcej niż 15 wierszy rzeczywistego kodu, powinien już istnieć solidny powód, dla którego należy go zachować w ten sposób. To miłe, praktyczne podejście do posiadania listy kontrolnej, ale zbyt wiele punktów tutaj jest po prostu wymyślonych lub używa się losowych wartości bez żadnego uzasadnienia.
R. Schmitz

8

Kiedy twoje wnętrzności mówią ci, że powinieneś zrobić pewne refaktoryzacje, to prawdopodobnie twoje instynkty mówią ci trochę za późno, że odkładasz coś ważnego zbyt długo.

Rozumiem „zapachy kodowe”, refaktor czerwono-zielony i inne myśli, ale często wydaje mi się, że najlepszym czasem na refaktoryzację nie jest pierwszy raz, kiedy piszesz kod, ale drugi lub trzeci raz, kiedy używasz kodu i zdajesz sobie sprawę że tak naprawdę jest to problem i jest w użyciu.

Istnieją dwa poziomy refaktoryzacji. Pierwszy to oczywiste problemy, które pojawiają się przy pierwszym kodowaniu. Są to małe optymalizacje, które bardzo niewiele kosztują z góry. Rzeczy takie jak utrzymywanie małych metod i klas oraz przestrzeganie zasad DRY i SRP. Następnie masz dodatkowy etap radzenia sobie z poważnymi wadami twojego projektu, które mogą nie być od razu widoczne, dopóki twój kod nie znajdzie się pod nim kilka mil. To ten drugi poziom, o którym mówisz, a jednak aby upewnić się, że późniejsze refaktoryzacja nie będzie zbyt kosztowna, musisz już napisać swój kod w taki sposób, aby wysiłek, który później przewidujesz, był łatwiejszy i mniej kosztowny, co oznacza wcześniejsze przeprowadzenie refaktoryzacji.

Jak wspomniał Jeff w swojej odpowiedzi, „czas to pieniądz” , szczególnie w firmach, w których obciążenie pracą jest wysokie, a ryzyko jeszcze większe. Czas spędzony z góry na upewnieniu się, że kod jest w najlepszym możliwym stanie, oszczędza czas później, gdy dowodzenie, co powinno być łatwym refaktoryzacją, okazuje się poważną operacją.

Pisząc oprogramowanie, każda chwila spędzona na ulepszaniu kodu z góry oszczędza czas później, kiedy naprawdę będziesz go potrzebować. Im wcześniej dokonamy refaktoryzacji, tym wyraźniejsze będą późniejsze zmiany. To jak wpłacanie zaliczki w dzisiejszych dolarach w stosunku do przyszłego zadłużenia technicznego, które będzie w jutrzejszych zawyżonych dolarach.

W każdym razie refaktoryzacja nie powinna być zadaniem, które odkładasz do tajemniczej przyszłości, gdy oprogramowanie jest już kompletne i stabilne, ponieważ zwiększa to ryzyko później, gdy stawki są znacznie wyższe, a produkt znacznie trudniejszy do zmiany. Refaktoryzacja powinna być częścią codziennych czynności, a to jest esencja wspomnianej przez ciebie filozofii Refaktora Czerwono-Zielonego.


2

Myślę, że na każde pytanie może odpowiedzieć każdy programista, a nawet kierownictwo odpowiedzialne za programowanie.

Moją osobistą preferencją jest to, że za każdym razem, gdy uczę się czegoś nowego lub doskonalę swoje najlepsze praktyki, zmieniam kod, który mogę - lubię utrzymywać swój kod na standardowym poziomie, gdy tylko dowiaduję się, jaki był najlepszy standard do zastosowania w tej sytuacji. Mogę to jednak robić, ponieważ jest to mniejsza firma, która korzysta z tego samego oprogramowania przez długi czas.

W większej firmie zajmującej się tworzeniem oprogramowania, w której czas to pieniądz, być może po prostu zacznij projektować z lepszymi praktykami, których nauczyłeś się od tego momentu, nie martw się o refaktoryzację, aż do wersji 2 tego konkretnego oprogramowania?

Czuję, że nauczanie, kiedy refaktoryzować naprawdę zależy od firmy, w której się obecnie znajdujesz.


2

„Kiedy refaktoryzować?”

Krótka odpowiedź: za każdym razem, gdy natrafisz na kod, który źle pachnie lub który można poprawić ( reguła skautowa )

W praktyce dzieje się tak:

  • Jeśli ćwiczysz TDD, systematycznie podczas etapu Refaktora cyklu TDD, to znaczy, gdy twój test będzie zielony i zanim zaczniesz pisać nowy test.
  • W wyniku przeglądu kodu
  • Podczas przejmowania starszego kodu
  • Podczas korzystania z kodu, który wydaje się niezręcznie zaprojektowany
  • itp.

Wydaje mi się, że to po prostu mówi „Powinieneś dokonać refaktoryzacji”, nie odpowiadając na trudniejszą część: „Czuję, że powinny być bardziej rygorystyczne podejścia do tego, ale nie jestem pewien, czym one są”.
Hortitude

Nie wiem, co powiedzieć, oprócz wyczuwania tego, co bolesne w utrzymaniu, wąchania zapachów kodu i korzystania z doświadczenia. Wątpię, aby kiedykolwiek istniała ostateczna, ustalona metoda, która powie ci, kiedy i co należy refaktoryzować, jeśli tego właśnie szukasz.
guillaume31

1

Kiedy po raz pierwszy uczyłem się o refaktoryzacji, mój mentor powiedział mi: „Zrób to dwa razy, trzymaj nos. Zrób to trzy razy. Refactor”. (Dzięki, Josh!) Mówiąc konkretnie, powiedział to, że kiedy masz zamiar napisać ten sam blok kodu po raz trzeci (lub nawet podobny wzorzec kodu), jest to czas na refaktoryzację. Śledziłem to przez ostatnie 10 lat i uznałem, że jest to dość rozsądna zasada.

Korzystanie z Eclipse lub podobnego IDE, które ma silne wsparcie refaktoryzacji, zmniejsza wysiłek związany z refaktoryzacją. Obsługa IDE zwiększa prawdopodobieństwo refaktoryzacji, jak tylko trafisz na „trzeci raz” (lub zobaczysz potrzebę), zamiast postrzegać to jako dodatkowy wysiłek.

Również - TDD jest tutaj dużą pomocą, ponieważ możesz nadal uruchamiać testy jako refaktor i wiedzieć, że niczego nie zepsułeś.


1

Refaktoryzacja z definicji jest procesem. Oznacza to, że nie powinieneś starać się znaleźć wolnego czasu na zrobienie refaktoryzacji, zamiast tego powinieneś ciągle refaktoryzować cały czas, gdy natrafisz na kod, który można lepiej napisać.

Osobiście lubię pisać ewolucyjne prototypy, mówiąc to prościej: kod, który po prostu działa, a następnie refaktoryzuję je, aż spełnią oczekiwane standardy kodowania. Innym dobrym przykładem jest dodanie dodatkowej funkcjonalności i refaktoryzacja istniejącego kodu, aby umożliwić jego ponowne użycie.


1

W ciągu moich 20 lat programowania, oto jedyna praktyczna zasada, którą widziałem w pracy, do której ludzie mogą się trzymać, a menedżerowie dają na to czas. (Refaktoryzacja jest jak dieta: jasne, że „kalorie w / kalorie” to formuła na odchudzanie, ale to nie przekłada się na dietę, którą ludzie będą przestrzegać.) A więc:

Refaktoryzuj w sposób ciągły podczas pracy. Użyj Test Driven Development, aby mieć kilka cykli refaktora czerwono-zielonego w ciągu dnia. Refaktoryzuj tylko te fragmenty kodu, którego dotknąłeś.

Gdy będziesz bardziej pewny siebie, możesz różnić się od tego trybu.


1

Myślę, że zależy to od wymagań właściciela projektu i faceta, który odpowiada za jakość kodu. Po prostu nie możesz decydować o tym sam, kiedy pieniądze innej osoby są kwestionowane.

Ze względów technicznych jest ich kilka.

  • Jeśli masz błąd w kodzie, oznacza to, że to miejsce jest źle zrozumiane i BARDZO prawdopodobne jest, że można tu ukryć więcej błędów, a na pewno będą duże problemy z każdą próbą opracowania połączonych części kodu. To miejsce należy więc sprawdzić pod kątem ewentualnego refaktoryzacji.
  • Innym powodem jest dodanie lub zmiana funkcji, a stary kod jest bardzo niewygodny przy zmianie / dodawaniu, a późniejsze zmiany / dodania są wysoce możliwe. Oczywiście powinieneś zrównoważyć koszty.
  • Być może najpoważniejszym powodem jest zmiana kodu i nie można go przetestować.

Jako mistrz scrum mieliśmy programistę, który nieustannie argumentował, że każda historia, w której liczył zespół, był większy niż to, co myślał zespół, i stwierdził, że chce przefakturować każdy fragment kodu, na który natknie się. Tak więc historia z 3 punktami była dla niego zawsze wartością 8. Najwyraźniej to zepsuło dostarczanie wartości. Dlatego musi być pewne zrozumienie, kiedy dokonać refaktoryzacji i jak należy podjąć decyzję. Tylko moja myśl z tego (i kilku innych) doświadczeń.
Curtis Reed
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.