Kiedy refaktoryzować

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.

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?

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)

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.

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.

„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.

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ś.

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.

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.

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ć.