Porady dotyczące pracy z legacy code
Potrzebuję porady, jak pracować z kodem starszym.
Jakiś czas temu otrzymałem zadanie dodania kilku raportów do aplikacji raportującej. written in Struts 1, back in 2005. Nic wielkiego, ale kod jest dość niechlujny. Brak użycia form działania, a w zasadzie kod jest jedną wielką akcją i wiele poleceń if-else wewnątrz. Ponadto, nikt tutaj nie ma funkcjonalnej wiedzy na ten temat. Tak się złożyło, że mieliśmy to w kontrakcie.
Jestem z tego powodu niezadowolony i nie wiem jak proszę kontynuować. Ta aplikacja jest niewidoczna: niewiele osób (ale wszystkie bardzo ważne) z niej korzysta, więc nie obchodzi ich, czy moje oczy krwawią podczas czytania kodu, standardów itp.
Jednak uważam, że trzeba spłacić techniczny dług. Jak mam to zrobić? Kontynuuj drogę if-else lub spróbuj zrobić to wymaganie we właściwy sposób, ignorując resztę projektu? Uruchamianie Wielkiego refaktora, ryzykując mój termin?
4 answers
Legacy code to duży problem i jestem pewien, że ludzie się nie zgodzą!
Powiedziałbym, że rozpoczęcie dużej re-factor może być błędem.
Duża zmiana oznacza zrobienie dużo pracy, aby funkcjonował dokładnie tak, jak teraz. Jeśli zdecydujesz się wziąć to na własną rękę, nie będzie dużo widoczności tego, co robisz. Jeśli to zadziała, nikt nie będzie wiedział, w jakich godzinach pracujesz. Jeśli to nie działa, a kończy się z tidy kodu, ale dodać kilka błędów (i kto ma kiedykolwiek napisany kod bez dodawania błędów) wtedy otrzymasz pytania typu "Dlaczego ta zmiana".
Obecnie prawie ukończyłem projekt pracujący na 10-letniej bazie kodu. Po drodze dokonaliśmy kilku zmian w faktoringu. Ale dla każdego ponownego czynnika, który dokonaliśmy, możemy uzasadnić "ta konkretna zmiana ułatwi rzeczywiste zadanie, które teraz wykonujemy". Zamiast "to jest teraz czystsze dla przyszłej pracy". Odkryliśmy, że podczas pracy nad kodem, naprawiając problemy to, że w rzeczywistości spotykamy się z jednym na raz, wyczyściliśmy wiele z nich, nie łamiąc go (dużo).
I powiedziałbym, że zanim będziesz mógł ponownie uwzględnić wiele czynników, będziesz potrzebował zautomatyzowanych testów, więc możesz być dość szczęśliwy, że złożyłeś je z powrotem dobrze!
Większość re factoringu odbywa się po to, aby "ułatwić konserwację i przyszły rozwój". Twój projekt wygląda na to, że nie ma zbyt wiele rozwoju w przyszłości. To ogranicza przewagę, jaką daje re-factor firmie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-01-21 15:33:44
Zasada # 1: Jeśli nie jest zepsuty, nie naprawiaj go.
Zasada # 2: w razie wątpliwości przeczytaj ponownie zasadę # 1.
Niestety, stary kod bardzo rzadko może być opisany jako " nie jest zepsuty."Dlatego musimy dostosować istniejący kod, aby poprawić nowo znaleziony błąd, dostosować istniejący kod, aby zmodyfikować zachowanie, które było wcześniej akceptowalne, lub dostosować istniejący kod, aby dodać nową funkcjonalność.
Moje doświadczenie nauczyło mnie, że każda refaktoryzacja musi odbywać się w "nieskończenie małych" przyrosty. Jeśli musisz złamać zasadę # 2, sugeruję, abyś rozpoczął wyszukiwanie od najbardziej zagnieżdżonej pętli lub struktury IF i rozszerzył na zewnątrz, aż znajdziesz czysty, logiczny punkt separacji i utworzysz nową funkcję / metodę / podprogram, który zawiera tylko wnętrzności tej pętli lub struktury. To nie uczyni niczego bardziej wydajnym, ale powinno dać jaśniejszy obraz podstawowej logiki i struktury. Gdy masz kilka nowych, mniejszych funkcji / metod/podprogramów, możesz refaktorować i / align = "left" /
Reguła # 3: Zignoruj mój poprzedni akapit i przeczytaj ponownie dwie pierwsze zasady.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-01-21 16:05:07
Zgadzam się z innymi komentarzami. Jeśli nie musisz, to nie rób tego. Zwykle kosztuje znacznie więcej niż warto, jeśli baza kodu jest mniej lub bardziej martwa w jakikolwiek sposób.
Z drugiej strony, jeśli czujesz, że nie możesz opanować kodu, to refaktor jest prawdopodobnie nieunikniony. Jeśli tak, to skoro jest to aplikacja webowa, czy można stworzyć solidny zestaw testów funkcjonalnych przy użyciu selenium? Jeśli tak to jest to najszybsze i najbardziej satysfakcjonujące podejście testowe dla takiego kodu i będzie Złap większość robaków za kasę.
Po drugie, zacznij od refaktoryzacji metody ekstraktu, aby utworzyć metody komponowania dużych trudnych metod. Za każdym razem, gdy myślisz sobie "to powinno mieć komentarz, aby wyjaśnić, co robi", powinieneś wyodrębnić go do metody o nazwie, która zastępuje komentarz.
Gdy już to zrobisz, jeśli nadal nie możesz dodać wymaganej funkcjonalności, możesz przejść do bardziej zaawansowanych refaktoringów, a może nawet dodać kilka testów jednostkowych. Ale zwykle znajduję że mogę dodać to, co jest wymagane / naprawić błąd w kodzie starszym, po prostu tworząc własny kod dokumentujący.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-01-22 15:13:14
W kilku słowach: przed dokonaniem jakichkolwiek zmian w kodzie starszym warto zacząć od zautomatyzowanych testów jednostkowych. To da deweloperowi zrozumienie kluczowych rzeczy: zależności, które ma ten fragment kodu, dane wejściowe, wyniki wyjściowe, warunki brzegowe itd.
Kiedy to zrobisz najprawdopodobniej lepiej zrozumiesz co ten kod robi i jak działa.
Po tym jego sens (ale nie musi) trochę wyczyścić kod dając dokładniejsze nazwy zmiennym lokalnym, przenosząc niektóre funkcjonalność (kod powtarzalny, jeśli istnieje) w funkcjach o jasnych, przyjaznych dla człowieka nazwach.
Proste czyszczenie może sprawić, że kod będzie bardziej czytelny, a jednocześnie uchroni programistę przed problemami z regresją dzięki pomocy testów jednostkowych.
Refaktoryzacja-wprowadzaj drobne zmiany, krok po kroku, gdy masz czas i zrozumienie wymagań i funkcjonalności, regularnie testuj kod.
Ale nie zaczynaj od refaktoryzacji
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-26 23:03:35