Refaktoryzacja: czy to nie jest tylko wymyślne słowo, aby oczyścić kod? [Zamknięte]

21

Zanim ukazała się książka Martina Fowlera „Refactoring: Improving the Design of Existing Code”, nazywaliśmy duże zmiany kodem „rearchitekturą”, a drobne zmiany „porządkiem”. IMO, techniki refaktoryzacji to zdrowy rozsądek / oczywiste rzeczy, które robiliśmy od zawsze.

Czy uważasz, że refaktoryzacja była kiedykolwiek czymś nowym? Być może to tylko sposób na oszukiwanie zarządzania w przydzielaniu czasu na czyszczenie kodu?

Chuck Stephanski
źródło
Kiedy mówisz „zanim ukazała się książka”, zakładam, że masz na myśli książkę Martina Folwera, czy to prawda?
AlexC,
-1: Jaka jest przydatność tego pytania?
Jim G.
Tak, książka Fowlera.
Chuck Stephanski

Odpowiedzi:

43

Refaktoryzacja jest starsza niż wzgórza, więc nie, to nie jest nic nowego.

A refaktoryzacja nie sprząta. Cóż, może tak być, ale nie ogranicza się do sprzątania.

Dostosowuje architekturę aplikacji (w dużej lub małej skali), zachowując zachowanie.

Oznacza to, że choć wczoraj część aplikacji mogła być idealnie czysta i dobrze, dzisiejsza nowa funkcja wymaga dostosowania tej części, aby dostosować ją do nowej funkcji.

Nie chcesz przerywać istniejącej funkcjonalności, więc dostosowujesz strukturę aplikacji, zachowując zachowanie - czyli refaktoryzację.

To powiedziawszy, bez względu na to, jakie zmiany zostaną wprowadzone w kodzie, należy zawsze uruchamiać jego testy ... na wszelki wypadek.

Frank Shearar
źródło
1
Newtopian: to bardzo ważna kwestia. Jeśli nie uruchomiłeś swoich testów, nie masz pojęcia, czy coś przypadkowo zhakowałeś, czy rzeczywiście zreorganizowałeś . (I oczywiście potrzebujesz odpowiedniego zestawu testów!)
Frank Shearar
9

Po prostu porządkuje kod. Zasadniczo programiści (zwłaszcza Martin Fowler) zauważyli, że mieli tendencję do wykonywania tych samych zadań za każdym razem, gdy poprawiali swój kod. Zdefiniowali i oznaczyli metody porządkowania oraz powiązane problemy z kodem i presto! Narodziło się refaktoryzacja.

To samo dotyczy wzorców projektowych - ludzie zauważyli, że mieli tendencję do stosowania tego samego podejścia do określonych problemów w kółko. Oznaczyli i zdefiniowali podejścia, a teraz wydaje się, że nie jesteś prawdziwym programistą, chyba że użyjesz tylko tego samego tuzina wzorców w kodzie.

Refaktoryzacja nie wymaga magii; to tylko nowy zestaw żargonu opisujący starą praktykę.

Mrówka
źródło
William Opdyke, 1992: Refactoring Object-Oriented Frameworks . Fowler & Beck i przyjaciele spopularyzowali refaktoryzację. Jon Brant i Don Roberts wdrożyli pierwsze zautomatyzowane narzędzie jakiś czas przed 1999 r. Zatem „nowy zestaw żargonu” nie jest zbyt dokładny.
Frank Shearar,
Jeśli zaakceptujesz, że programowanie komputerowe trwa od czasów Ada Lovelace w połowie XIX wieku, to tak - jest to stosunkowo nowy zestaw żargonu.
Ant
1
Myślę, że różnica polega na tym, że wzorce projektowe prawie każdy programista nauczył się nowych wzorów, a więc i nowych narzędzi handlu z książki. Dzięki Refaktoryzacji nie wydaje mi się, żeby ktoś naprawdę się czegoś nauczył. Po prostu nadanie nazwy czemuś ma wartość drugorzędną (i tam utrzymuje się porównanie wzorców projektowych), ale mógł to zrobić z postem na blogu.
Chuck Stephanski
Rzeczywiście wspomniałem, że był to nowy żargon ... względem rachunku lambda.
Frank Shearar,
@Chuck, czy czytałeś książkę, Refaktoryzacja? Jeśli tak, byłbym bardzo zaskoczony, gdybyś nie nauczył się z tego czegoś nowego.
Marcie
7

W naszej firmie wykonujemy trzy osobne czynności, przydzielając czas na trzy:

  • Refaktoryzacja: polega na zmianie struktury kodu, a tym samym zachowaniu.

Przykład: podzielenie brzydkiej i nieczytelnej metody 100 linii, która robi cztery rzeczy na cztery metody wielokrotnego użytku, każda po 25 linii.

  • Oczyszczanie: polega na wprowadzaniu drobnych modyfikacji, aby kod był bardziej czytelny bez modyfikowania jego zachowania ani struktury.

Przykład: usunięcie skomentowanego kodu po upewnieniu się, że ten kod nie jest już potrzebny.

  • Egzekwowanie reguł StyleCop / FxCop: polega na sprawdzeniu, czy kod odpowiada domyślnemu zestawowi reguł StyleCop lub FxCop, a jeśli nie, zmodyfikuj go, aby pasował do tych reguł.

Przykład: dodawanie Culture.Invariantw string.Format(lub innego kultura, która jest bardziej właściwe).

W moim przypadku refaktoryzacja jest czymś zupełnie innym niż porządkowanie . Kiedy robi porządki, nie trzeba ponownie uruchomić testy jednostkowe: jeśli kod pracował wcześniej, to będzie działać po czyszczeniu. Innymi słowy, to nie dlatego, że usunąłem pusty wiersz lub dodałem komentarz, że kod przestanie działać. Z drugiej strony, kiedy refaktoryzuję skomplikowane części starego kodu, mogę popełnić błędy, więc po refaktoryzacji muszę przeprowadzić testy jednostkowe.

Arseni Mourzenko
źródło
4
Chociaż zgadzam się, że istnieje zasadnicza różnica między czyszczeniem a ponownym faktoringiem, istnieje wiele przypadków, w których ta linia całkiem się zaciera. Usunięcie martwej klasy i „usunięcie” wszystkich odniesień do niej z podpisów metod lub pozostałych skojarzeń byłoby uważane za czyszczenie lub refaktoryzację? Zdecydowanie nie zgadzam się z tym, że przeprowadzanie testów jednostkowych jest opcjonalne. Nie masz pojęcia, jak wszystko może się zepsuć. Widziałem zmiany w łańcuchu komunikatów kodu przerwania wyjątku, ponieważ ktoś pomyślał, że dobrym pomysłem jest parsowanie go w celu podjęcia pewnych błędów.
Newtopian
Muszę zgodzić się z Newtopianem, szczególnie jeśli chodzi o to, że nie muszę ponownie uruchamiać testów. W rzeczywistości powinien istnieć zautomatyzowany zestaw testów, który uruchamia się nie rzadziej niż raz na zatwierdzenie. Niezależnie od tego, czy jest to czyszczenie, czy refaktoryzacja , w przypadku zmiany kodu w celu zatwierdzenia kontroli wersji testy powinny zostać uruchomione.
kojiro
Zawsze powinieneś wykonać pełną kompilację po każdym czyszczeniu - nawet jeśli jest to tylko biała spacja i zmiany komentarzy. Zapytaj o to każdego autora Pythona lub Makefile.
JBRWilkinson,
3

Refaktoryzacja dodaje wiedzę do twojego kodu. Jeśli wiesz, że coś ma niepoprawną nazwę, nadaj jej lepszą nazwę. Jeśli wiesz, że coś można zrobić lepiej, zmieniasz to w coś lepszego.

Jest wiele kroków - małych i dużych - które, mam nadzieję, skutkują lepszym programem.

użytkownik1249
źródło
3

Zgadzam się z tym, że „refaktoryzacja to wymyślne słowo do czyszczenia kodu”, ale nie z „tylko”. Ludzie używają fantazyjnych słów z jakiegoś powodu: czasami dlatego, że chcą wyglądać sprytnie, a czasem dlatego, że przekazują większe lub bardziej precyzyjne znaczenie, a refaktoryzacja IMHO (nawet jeśli czasami niewłaściwie używana) odnosi się ogólnie do tego drugiego.

„Oczyszczanie” może znaczyć wszystko, od „nieco sformatowania” do „przepisywania dużych fragmentów”.

„Refaktoryzacja” oznacza w szczególności coś w rodzaju „małych stopniowych zmian w kodzie, zaprojektowanych w celu utrzymania tej samej funkcjonalności, a jednocześnie przekształcenia jej w lepszy projekt”. Istnieje szereg najlepszych praktyk w zakresie tego, co robisz: niektóre są ad hoc, ale istnieją ogólne zasady, takie jak stosowanie testów jednostkowych, wyodrębnianie części funkcji do nowych funkcji lub klas itp., Których ludzie mogą i powinni się uczyć .

Mówisz „po prostu podstępnie zarządzaj, aby przydzielić czas na czyszczenie kodu”. Ale jeśli powiedzenie „refaktoryzacja” poprawnie przekazuje koncepcję, że stała inwestycja w klarowność teraz przyniesie dywidendy w wydajności w przyszłości, to nie jest to „sztuczka”, to jasna i skuteczna komunikacja.

Jack V.
źródło
2

Refaktoryzacja polega na kodowaniu, ponieważ normalizacja dotyczy danych relacyjnych. Jest to proces przekształcania koncepcji w czystsze, jaśniejsze i bardziej wydajne reprezentacje ich roli w aplikacji.

sunwukung
źródło
1
To ciekawy sposób na to spojrzeć. Może pochodzi z mojej bazy danych, ale jest coś, co denerwuje mnie w stresie związanym z refaktoryzacją, a ty pomogłeś mi to położyć. Chodzi o to, że w bazie danych to, czego nie naprawiasz w projekcie, zajmuje 10 razy więcej czasu na naprawę i prawdopodobnie 1000 razy dłużej w produkcji. Tak więc dobry DBA jest analitykiem, aby wszystko jak najszybciej zacząć. Mam przeczucie, że zbyt dużo czasu na refaktoryzację na późniejszych etapach wskazuje na zbyt mało czasu poświęcanego na projektowanie.
user21007,
@ user21007: Kod jest o wiele bardziej skomplikowany niż schemat bazy danych, ale o wiele łatwiej go zmienić i wdrożyć.
kevin cline
1

To zależy, jak rozumiesz refaktoryzację terminu. Dla większości ludzi jest to proces ulepszania struktury bez zmiany zachowania. Jeśli się zgadzasz, to tak, zrobiono to na długo przed wydaniem tej książki. Wiem, ponieważ zmieniłem nazwy klas, wyodrębniłem klasy i wyodrębniłem metody przed napisaniem książki. Nie nazwałam tego refaktoryzacją, ale w zasadzie robiłam dokładnie to samo.

Dla mnie osobiście refaktoryzacja to, co ludzie nazywają teraz „automatyczną refaktoryzacją kodu”, tj .: wsparcie dla różnych technik refaktoryzacji wewnątrz IDE. To jest prawdziwa poprawa tego, co robiłem wcześniej (co było naprawdę bardzo bolesne). Mogę dokonać zmiany w jednej klasie i nie martwić się, jak wpłynie to na resztę oprogramowania. Myślę, że Martin sformalizował technikę refaktoryzacji do tego stopnia, że ​​mogłaby być reprezentowana jako algorytm, a tym samym zaimplementowana w różnych IDE.

Więc jeśli rozumiesz refaktoryzację jako proces, to nie jest to nic nowego. Jeśli postrzegasz to jako automatyzację, to tak, to ogromna poprawa. Spróbuj zmienić nazwę kilku podstawowych klas (dosłownie, nie poprzez opcje refaktoryzacji twojego IDE) w dość dużym projekcie, aby zobaczyć dlaczego :)

Jacek Prucia
źródło
0

Refaktoryzacja to rzeczywiście „czyszczenie” kodu, ale także restrukturyzacja kodu. W moim zespole refaktoryzacja jest zwykle tym drugim. Kiedy mamy przypadek „refaktoryzacji”, poświęcamy czas na restrukturyzację naszego kodu, np. W celu dostosowania go do nowej architektury lub modelu informacyjnego lub w celu zwiększenia jego wydajności.

„Czyszczenie” kodu to coś, co robimy bez przerwy, bez specjalnie przeznaczonego na to czasu. Dla mnie „czyszczenie” zwykle oznacza zmianę nazwy, usuwanie komentarzy itp.

Mantisen
źródło
1
zmiana nazwy jest standardową techniką refaktoryzacji!
Chuck Stephanski
0

Powiedziałbym nie

W procesie refaktoryzacji mogą występować porządki, ale nie jest to istotą.

Oczyszczanie zakłada, że ​​poprzedni kod nie jest czysty. W rzeczywistości programiści refaktoryzują swój kod, nawet oryginalny kod jest już czysty.

DRY jest kluczowym czynnikiem wpływającym na refaktoryzację.

Podczas dodawania nowych kodów do istniejącej bazy kodów refaktoryzacja odbywa się w sposób naturalny, zgodnie z zasadą OSUSZANIA.

Tylko moje 0,02

ohho
źródło
0

Czyszczenie kodu jest jak sprzątanie domu, refaktoryzacja jest jak burzenie ściany i umieszczanie go gdzie indziej

Homde
źródło
0

Kiedy ktoś sprząta w twoim domu, nie możesz niczego znaleźć, ponieważ celem jest uporządkowanie sprawy. Refaktoryzacja pozwoliłaby zbudować i oznaczyć pokoje, szafy, szafki, półki, kosze itp. Nadal zawiera większość tych samych rzeczy (nadal możesz zrobić kanapkę z serem z grilla w kuchni i zjeść ją w salonie), ale powinna to zrobić łatwiej znaleźć i być może mieć wydajne miejsca na nowe rzeczy.

JeffO
źródło
Nie jestem fanatykiem modnych słów, ale czasem typowe zadania muszą być oznaczone i sformalizowane, aby każdy wiedział, o czym mówisz. Klient zgłasza błąd, a kierownik krzyczy: „Wyczyść swój kod!” wiesz, że nie mówią o refaktoryzacji.
JeffO
0

Termin „refaktoryzacja” został elegancko zapożyczony z algebry. Oznacza to uproszczenie warunków, aby uzyskać ten sam wynik. Był nie tylko elegancki, ale i rewolucyjny - wymagał twardego, skończonego podejścia do twojego kodu, na poziomie, który zaskoczył wielu. Tak więc sam termin był znaczący i pomocny.

Smandoli
źródło
-1

Nie. Refaktoryzacja poprawia strukturę bez zmiany zachowania. Refaktoryzacja w ścisłym tego słowa znaczeniu wymaga dobrej dyscypliny testowej. Niekoniecznie jest to wymagane, gdy „czyścisz rzeczy”.

Willie Wheeler
źródło
2
niebezpieczne podejście. Usunięcie całego pokosu martwego kodu i martwej konfiguracji to oczyszczenie i zmiana sygnatury jednej metody refaktora. Jednak w obu przypadkach chciałbym uzyskać dobrą dyscyplinę testową, aby upewnić się, że niczego nie złamałem.
Newtopian
Nie twierdzę, że wprowadzanie poważnych zmian bez dyscypliny testowej jest dobre / bezpieczne / pożądane. Mówię, że refaktoryzacja jako metodologia wymaga dyscypliny testowej, podczas gdy „sprzątanie rzeczy” wcale nie jest metodologią.
Willie Wheeler
Więc jeśli dobrze rozumiem, jeśli nie ma ona odpowiedniej wymyślnej nazwy, to możemy zacząć !! : -O żartuję, widzę, co próbujesz powiedzieć, to prawda, że ​​sprzątanie rzeczy nie może być nazwane metodologią, ale z drugiej strony żadna nie jest refaktoryzacją. To tylko fantazyjne słowo, które mówi, że zmieniasz kod bez zmiany jego zachowania. Samo w sobie nie ma żadnego wpływu na testowanie. Zgodnie z dobrą praktyką kodowania stwierdzimy, że jeśli kod się zmienił, to należy go przetestować niezależnie od tego, jak wywołasz akcję, która wygenerowała zmianę.
Newtopian
1
Jasne, że mogę to kupić. Dyscyplina testowa jest bardziej związana z przeprowadzaniem refaktoryzacji, ale nie jest nieodłączna od definicji. (Tj. Mogę ponownie kodować kod bez żadnych testów.) Nie wiem, czy mogę zgodzić się, że refaktoryzacja nie jest metodologią - są całe książki napisane z wzorcami krok po kroku i tak dalej.
Willie Wheeler
-1

Obie pokrywają się trochę na krawędziach, ale dla mnie to różnica między czyszczeniem domu a przebudową domu. Oczyszczanie nie oznacza dla mnie zmian strukturalnych, a refaktoryzacja.

Zasilacz
źródło
-2

„Refaktoryzacja” to tak naprawdę to samo, co „rearchitektura”, ale z silniejszą konotacją „bez zmian funkcjonalności”. Jest również jaśniejszy pod względem celu polegającego na ponownej architekturze, która często polega na „rozłożeniu” wspólnego kodu na części wielokrotnego użytku.

DVK
źródło