Refaktoryzacja kodu przy złym projektowaniu systemu

Get and read działa efektywnie z kodem starszym . Dotyczy to dokładnie tej sytuacji.

Jak inni również doradzali, do refaktoryzacji potrzebny jest solidny zestaw testów jednostkowych. Jednakże, starszy kod jest zazwyczaj bardzo trudny do testowania jednostkowego, ponieważ nie został napisany tak, aby można go było testować jednostkowo. Musisz więc najpierw refaktorować, aby umożliwić testowanie jednostkowe, co pozwoli na rozpoczęcie refaktoryzacji... zły chwyt.

Tutaj książka Ci pomoże. Daje wiele praktyczne porady, jak sprawić, by źle zaprojektowana Jednostka kodu była testowalna przy minimalnych i najbezpieczniejszych zmianach kodu. Automatyczne refaktoryzacje również mogą Ci pomóc, ale są opisane w książce sztuczki, które można wykonać tylko ręcznie. Następnie, po wprowadzeniu pierwszego zestawu testów jednostkowych, można rozpocząć stopniową refaktoryzację w kierunku lepszego, łatwiejszego do utrzymania kodu.

Update: aby uzyskać wskazówki, jak przejąć legacy code, możesz znaleźć tę wcześniejszą odpowiedź mojej przydatne.

Jak zauważył @ Alex, testy jednostkowe są również bardzo przydatne do zrozumienia i udokumentowania rzeczywistego zachowania kodu. Jest to szczególnie przydatne, gdy dokumentacja systemu nie istnieje lub jest nieaktualna.

Po pierwsze, nie naprawiaj tego, co nie jest zepsute. Tak długo, jak system masz przejąć pracę, zostaw funkcjonalność w spokoju.

System jest oczywiście zepsuty, jeśli chodzi o konserwację, więc tym się zajmujesz. Jak wspomniano powyżej, najpierw napisz kilka testów, uzyskaj kopię zapasową źródła w cvs, a następnie zacznij od czyszczenia najpierw małych kawałków, potem większych i tak dalej. Nie atakuj większych problemów architektonicznych, dopóki nie uzyskasz dobrego zrozumienia, w jaki sposób system działa. Narzędzia nie pomogą Ci tak długo, jak długo nie zanurzysz się w kodzie samodzielnie, ale kiedy to zrobisz, bardzo ci pomogą.

EDIT: Dodano bezpośredni link do artykułu YAGNI

Twój numer # 7 jest zdecydowanie najważniejszy. Dopóki nie masz pojęcia, jak system ma się zachowywać, wszystkie względy techniczne są drugorzędne. Wszyscy sugerują testy jednostkowe - ale jak można napisać przydatny test, skoro nie można odróżnić zachowań pożądanych od niechcianych?

Więc zanim zaczniesz dotykać kodu, musisz zrozumieć system z punktu widzenia użytkownika: rozmawiać z użytkownikami, obserwować ich za pomocą systemu, pisać dokumentację na poziomie przypadków użycia.

Tak, naprawdę sugeruję, że spędzasz dni, a raczej tygodnie, nie zmieniając ani jednej linijki kodu. Bo w tej chwili, każda zmiana, którą dokonasz, może zepsuć wszystko bez Twojej wiedzy.

Gdy już zrozumiesz aplikację, będziesz przynajmniej wiedział, która funkcjonalność jest ważna do przetestowania (ręcznie lub automatycznie).

Napisz najpierw kilka testów jednostkowych i upewnij się, że zdają. Następnie przy każdej zmianie refaktoryzacji upewnij się, że testy przechodzą. Wtedy możesz mieć pewność, że twoje zachowanie aplikacji w świecie zewnętrznym nie uległo zmianie.

Ma to również dodatkową zaletę, że testy zawsze będą tam, więc w przypadku przyszłych zmian testy powinny nadal przejść, chroniąc przed wszelkimi regresjami w nowych zmianach.

Przede wszystkim upewnij się, że masz zainstalowany system kontroli źródła i cały kod źródłowy jest wersjonowany i może być zbudowany.

Następnie możesz spróbować napisać test jednostkowy dla podstawowych części systemu. Stamtąd, gdy masz mniej lub bardziej solidny korpus testów regresyjnych, możesz rzeczywiście przystąpić do refaktoryzacji.

Kiedy spotykam niechlujny kod, zwykle zaczynam od zmiany nazw źle nazwanych typów i metod, aby lepiej odzwierciedlić ich początkowy zamiar. Następnie możesz spróbować podział wielkich metod na mniejsze.

Należy pamiętać, że ten starszy system, z całym kodem spaghetti, obecnie działa. Nie zmieniaj rzeczy tylko dlatego, że nie wyglądają tak ładnie, jak powinny. Skup się na stabilności, nowych funkcjach i znajomości przed zgrywaniem starego kodu z lewej i prawej strony.

Po pierwsze, pozwól mi powiedzieć, że efektywna praca z kodem starszym to chyba naprawdę dobra książka do przeczytania, sądząc po trzech odpowiedziach w ciągu minuty od siebie.

1. bad database table design

Ten, prawdopodobnie utkniesz z. Jeśli próbujesz zmienić istniejący projekt bazy danych, prawdopodobnie zobowiązujesz się do przeprojektowania całego systemu i , pisząc narzędzia do migracji dla istniejących danych. Zostawić sam.

Moja standardowa odpowiedź na to pytanie brzmi: Refaktor nisko wiszący owoc. W tym przypadku, byłbym skłonny wziąć jedną z klas 10k-line i szukać okazji, aby Sprout Class , ale to tylko moja własna skłonność; możesz być bardziej komfortowy, zmieniając inne rzeczy najpierw (ustawienie kontroli źródła było doskonały pierwszy krok!) Przetestuj, co możesz; refakturuj, czego nie można przetestować, zrób krok po kroku i zrób to lepiej.

Pamiętaj o tym jak postępuj, o ile lepiej robisz rzeczy; jeśli skupisz się tylko na tym, jak złe rzeczy nadal są, prawdopodobnie zniechęcisz się.

Jak zauważyli inni, nie zmieniaj czegoś, co działa tylko po to, aby było ładniejsze. Ryzyko wprowadzenia błędów jest duże.

Moja filozofia brzmi: ponieważ muszę wprowadzać zmiany, aby spełnić nowe wymagania lub naprawić zgłoszone błędy, staram się, aby kawałek kodu, który muszę zmienić, był trochę czystszy. I tak będę musiał przetestować zmieniony kod, więc teraz jest dobry czas, aby zrobić małe sprzątanie za niewielką dodatkową opłatą.

Fundamentalne zmiany konstrukcyjne są najtrudniejsze i musi być zapisany na okazje, w których musisz dokonać na tyle dużej zmiany, że i tak będziesz testował cały zmieniony kod.

Zmiana złego projektu bazy danych jest najtrudniejsza ze wszystkich, ponieważ źle zaprojektowane tabele są prawdopodobnie używane przez wiele programów. Każda zmiana bazy danych wymaga zmiany każdego programu, który ją czyta lub zapisuje. Najlepszym sposobem na osiągnięcie tego celu jest zwykle próba zmniejszenia liczby miejsc, które mają dostęp do danej części bazy danych. Na prosty przykład: Załóżmy, że jest 20 miejsc, które czytają rekordy klientów i obliczają saldo konta klienta. Zastąp to jedną funkcją, która odczytuje bazę danych i Zwraca sumę oraz dwadzieścia wywołań tej funkcji. Teraz możesz zmienić schemat dla rekordów klienta i jest tylko jeden kawałek kodu, aby zmienić zamiast 20. Zasada jest dość prosta, ale w praktyce jest mało prawdopodobne, aby każda funkcja, która uzyskuje dostęp do danego rekordu, robiła to samo. Nawet jeśli oryginał programista byĹ 'na tyle niezdarny, Ĺźe napisaĹ' ten sam kod 20 razy (nie jest to nieprawdopodobne-widziaĹ 'em tego mnĂłstwo), w rzeczywistoĹ" ci prawdopodobnie nie jest to, Ĺźe napisaĹ '1 funkcjÄ ™ 20 razy, kropkÄ™, ale to, Ĺźe napisaĹ' funkcjÄ ™ A 20 razy, funkcjÄ ™ B 12 razy, funkcjÄ ™ C 4 razy, itd.

Efektywna praca z kodem starszym może być pomocna.

Problemy projektowe są bardzo trudne do uchwycenia. Pierwszym miejscem na początek jest zrozumienie projektu aplikacji. Uważam, że przydatne jest diagram za pomocą UML lub diagramu przepływu procesu, wszystko działa, co komunikuje projekt i pracę dla aplikacji.

Stamtąd Wchodzę bardziej szczegółowo i zadaję sobie pytania "Czy zrobiłbym to w ten sposób", jakie są inne opcje. Łatwo dostrzec kod-dług, czyli dług, który otrzymujemy z dokonywania złych wyborów, jako zawsze źle, ale czasami są inne czynniki, takie jak budżet, czas, dostępność zasobów itp. Ich trzeba zadać pytanie, czy warto refaktoryzować działającą, ale źle zaprojektowaną aplikację.

Jeśli pojawi się wiele nadchodzących nowych funkcji, zmian, poprawek itp., powiedziałbym, że dobrze jest refaktorować, ale jeśli aplikacja rzadko się zmienia i jest stabilna, to może pozostawienie jej tak, jak jest, jest lepszym podejściem.

Kolejnym punktem na uwadze jest to, że jeśli kod jest używany przez inna aplikacja jako usługa lub moduł, a następnie refaktoryzacja może najpierw oznaczać utworzenie Stuba wokół kodu, który serwuje jako interfejsy, gdy jest wyraźnie zdefiniowany i ma test jednostkowy, aby udowodnić, że działa. Możesz wybrać dowolną technologię, aby wypełnić szczegóły.

Dobra książka na ten temat działa skutecznie z Legacy Code Michaela Feathersa (2004). Przechodzi przez proces wprowadzania małych zmian, jednocześnie pracując nad większym oczyszczeniem.

1. Napisz test jednostkowy i znajdź i usuń zduplikowany kod.
2. Napisz test jednostkowy i podziel długie metody na serię krótkich metod.
3. Napisz test jednostkowy i znajdź i usuń metodę zduplikowaną.
4. Napisz unit test & rozbić klasy tak, że po pojedyncze zasada odpowiedzialności .

Spróbuj najpierw utworzyć testy jednostkowe, które mogą wywołać pewne działania w Twoim kodzie.

Zatwierdź wszystko w SVN i oznacz je (na wypadek, gdyby coś poszło źle, będziesz miał kapsułę ratunkową).

Użyj wtyczki Incode Eclipse http://www.intooitus.com/inCode.html i poszukaj, jakie refaktoringi proponuje. Sprawdź, czy proponowane refaktoryzacje wydają się w porządku dla Twojej proble. Spróbuj je zrozumieć.

Powtórz test z wcześniej utworzonymi jednostkami.

Teraz możesz użyć FindBugs i / lub PMD, aby sprawdzić inne subtelne problemy.

Jeśli wszystko jest ok, możesz chcieć zameldować się ponownie.

Spróbowałbym również odczytać źródło w celu wykrycia niektórych przypadków, w których można zastosować wzorce.