Legacy Code Nightmare [zamknięty]

Pracuję w podobnej sytuacji.

Jeśli nie jest to małe narzędzie, ale duży projekt przedsiębiorstwa, to jest to:

A) too late to fix it
b) poza możliwościami jednej osoby do próby a)
c) może być naprawiony tylko przez całkowite przepisanie rzeczy, które nie wchodzi w grę

Refaktoryzacja w wielu przypadkach może być podejmowana tylko w czasie prywatnym na własne ryzyko. Jeśli nie masz wyraźnego mandatu, aby to zrobić w ramach swojej codziennej pracy więc prawdopodobnie nawet nie dostaniesz za to uznania. Może być nawet krytykowany za "bezcelowe marnowanie czasu na coś, co doskonale działa już od dawna".

Po prostu kontynuuj hakowanie go w sposób, w jaki został wcześniej zhakowany, otrzymuj wypłatę i tak dalej. Kiedy będziesz całkowicie sfrustrowany lub system osiągnie punkt, w którym nie da się dalej zhakować, znajdź inną pracę.

EDIT: ilekroć próbuję poruszyć kwestię prawdziwej architektury i robienia rzeczy w odpowiedni sposób zwykle dostaję LOL w twarz bezpośrednio od odpowiedzialnych menedżerów, którzy mówią coś w stylu " mam gdzieś dobrą architekturę "(próba tłumaczenia z niemieckiego). Ja osobiście przyniósł jeden bardzo zły komponent do punktu non-hackability, podczas gdy oczywiście dał zaawansowane Ostrzeżenia miesięcy wcześniej. Następnie musieli anulować niektóre obiecane funkcje klientom, ponieważ nie było to już wykonalne. Nikt już go nie dotyka...

Pracowałem już w tej pracy. Spędziłem nieco ponad dwa lata na dziedzicznej bestii, która jest bardzo podobna. Dwóch z nas zajęło nam ponad rok, aby wszystko ustabilizować (nadal jest zepsute, ale jest lepiej).

Pierwsza rzecz -- uzyskać wyjątek logowania do aplikacji, Jeśli jeszcze nie istnieje. Użyliśmy FogBugz i zajęło nam około miesiąca, aby zintegrować raportowanie z naszą aplikacją; nie było to idealne od razu, ale automatycznie zgłaszało błędy. Zazwyczaj jest całkiem bezpiecznie zaimplementuj bloki try-catch we wszystkich swoich wydarzeniach, a to pokryje większość błędów.

Stamtąd naprawić błędy, które pojawiają się jako pierwsze. Następnie walcz w małych bitwach, zwłaszcza tych opartych na błędach. Jeśli naprawisz błąd, który nieoczekiwanie wpływa na coś innego, przefaktoruj ten blok tak, aby został oddzielony od reszty kodu.

Potrzeba ekstremalnych środków, aby przepisać dużą, krytyczną dla sukcesu firmy aplikację, bez względu na to, jak jest zła. Nawet Ty masz pozwolenie na tak więc będziesz spędzać zbyt dużo czasu na wspieraniu starszej aplikacji, aby i tak poczynić postępy w przepisywaniu. Jeśli zrobisz wiele małych refaktoringów, w końcu albo te duże nie będą aż tak duże, albo będziesz miał naprawdę dobre klasy fundamentowe do przepisywania.

Jedną rzeczą, którą należy od tego zabrać, jest to, że jest to wspaniałe doświadczenie. To będzie frustrujące, ale wiele się nauczysz.

Kiedyś natknąłem się na kod, który był tak obłędnie splątany, że nie mogłem go naprawić funkcjonalnym duplikatem w rozsądnym czasie. To był szczególny przypadek, ponieważ był to parser i nie miałem pojęcia, ilu klientów może "używać" niektórych błędów, które miał. Renderowanie setek "działających" plików źródłowych nie było dobrym rozwiązaniem.

Przez większość czasu jest to wykonalne, po prostu zniechęcające. Przeczytaj tę refaktoryzację.

Ogólnie zaczynam naprawianie złego kodu poprzez przenoszenie rzeczy wokół (bez zmieniania kodu implementacji bardziej niż jest to wymagane), tak aby moduły I klasy były przynajmniej w pewnym stopniu spójne.

Kiedy to zrobisz, możesz wziąć swoją bardziej spójną klasę i przepisać jej wnętrzności, aby wykonać dokładnie w ten sam sposób, ale tym razem z sensownym kodem. Jest to trudna część z zarządzaniem, ponieważ na ogół nie lubią słyszeć, że zajmie ci tygodnie kodowanie i debugowanie czegoś, co zachowa się dokładnie tak, jak to możliwe to samo (jeśli wszystko pójdzie dobrze).

Podczas tego procesu gwarantuję, że odkryjesz mnóstwo błędów i głupstw projektowych. W porządku jest naprawiać trywialne błędy podczas rekodowania, ale w przeciwnym razie zostaw takie rzeczy na później.

Gdy zrobi się to za pomocą kilku klas, zaczniesz widzieć, gdzie rzeczy można lepiej modularyzować, lepiej zaprojektować itp. Plus będzie łatwiej dokonać takich zmian bez wpływu na niepowiązane rzeczy, ponieważ kod jest teraz bardziej modularny i pewnie wiesz dokładnie.

W większości, to brzmi dość źle. Ale nie rozumiem tej części:

Moi poprzednicy nawet myśleli, że będzie bądź sprytny, aby korzystać ze wszystkich zestawów danych do tyłu. Każda aktualizacja bazy danych jest wysyłane bezpośrednio do serwera db jako parametrów w procedurze składowanej, a następnie zestawy danych są ręcznie odświeżane tak interfejs wyświetli najnowszą zmiany.

To brzmi dość blisko sposobu, w jaki często piszę rzeczy. Co w tym złego? Co jest poprawne sposób?

Jeśli Twoje refaktoryzacje łamią kod, szczególnie kod, który wydaje się być niezwiązany, to próbujesz zrobić za dużo na raz.

Polecam refaktoryzację pierwszego przejścia, w której wszystko co robisz to ekstrakcja method: celem jest po prostu nazwanie każdego kroku w kodzie, bez żadnych prób konsolidacji.

Potem pomyśl o zerwaniu zależności, zastąpieniu singletonów, konsolidacji.

Jeśli Twoje refaktoringi niszczą rzeczy, oznacza to, że nie masz odpowiedniego pokrycia testów jednostkowych - ponieważ testy jednostkowe powinny być najpierw uszkodzone. Polecam uzyskać lepszy zasięg testów jednostkowych po zalogowaniu się do wyjątków.

Polecam najpierw zrobić małe refaktoryzacje-metodę wyodrębniania, aby rozbić duże metody na zrozumiałe części; wprowadzić zmienną, aby usunąć niektóre duplikacje w metodzie; może wprowadzić parametr, jeśli znajdziesz duplikację między zmienne używane przez rozmówców i rozmówcę.

I uruchom zestaw testów jednostkowych po każdym refaktoringu lub zestawie refaktoringów. Powiedziałbym, uruchom je Wszystkie dopóki nie zdobędziesz pewności, które testy będą musiały być powtarzane za każdym razem.

Żadna książka nie będzie w stanie pokryć wszystkich możliwych scenariuszy. Zależy to również od tego, czego będziesz oczekiwać od projektu i czy istnieje jakaś zewnętrzna Specyfikacja.

• Jeśli będziesz musiał robić tylko sporadyczne małe zmiany, po prostu zrób to i nie kłopocz się zaczynaniem refakturowania.
• Jeśli istnieje Specyfikacja (lub możesz poprosić kogoś, aby ją napisał), rozważ całkowite przepisanie, jeśli może to być uzasadnione przewidywalną ilością zmian w projekcie
• Jeśli "implementacja jest specyfikacją" i zaplanowano wiele zmian, więc jesteś prawie gotowy. Napisz wiele testów jednostkowych i rozpocznij refaktoryzację w małych krokach.

Właściwie, testy jednostkowe będą bezcenne bez względu na to, co robisz (jeśli możesz je napisać do interfejsu, który nie zmieni się zbytnio przy refaktoringach lub przepisywaniu, czyli).

Zobacz wpis na bloguAnatomia warstwy antykorupcyjnej, Część 1 oraz Anatomia warstwy antykorupcyjnej, część 2.

Cytuje Eric Evans, projektowanie oparte na domenie: rozwiązanie problemu złożoności w sercu oprogramowania:

Dostęp do śmieci za fasadą

Można wyodrębnić, a następnie refaktoryzować jego część, aby rozdzielić zależności i wyizolować warstwy na różne moduły, biblioteki, zespoły, katalogi. Następnie ponownie wstrzykuje się oczyszczone Części do aplikacji za pomocą aplikacji . / Align = "left" /

Powodzenia, to jest trudna część bycia deweloperem.

Myślę, że Twoje podejście jest dobre, ale musisz skupić się na dostarczaniu wartości biznesowej (liczba testów jednostkowych nie jest miarą wartości biznesowej, ale może dać ci wskazanie, czy jesteś na torze lub poza nim). Ważne jest, aby zidentyfikować zachowania, które należy zmienić, ustalić priorytety i skupić się na najlepszych.

Druga rada to pozostać pokornym. Uświadom sobie, że jeśli napisałeś coś tak dużego pod prawdziwe terminy i ktoś inny widział Twój kod, prawdopodobnie też miałby problemy ze zrozumieniem go. Jest umiejętność pisania czystego kodu, a jest ważniejsza umiejętność radzenia sobie z cudzym kodem.

Ostatnią radą jest próba wykorzystania reszty zespołu. Poprzedni członkowie mogą znać informacje o systemie, którego możesz się nauczyć. Mogą również pomóc w testowaniu zachowań. Wiem, że ideałem jest mieć zautomatyzowane testy, ale jeśli ktoś może pomóc weryfikując rzeczy dla Ciebie ręcznie rozważyć uzyskanie ich pomocy.

Szczególnie podoba mi się schemat w Kod kompletny, w którym zaczynasz od kodu starszego, prostokąta o rozmytej szarej teksturze. Następnie po zastąpieniu niektórych z nich masz rozmyty szary na dole, biały na górze i postrzępioną linię reprezentującą interfejs między nimi.

Oznacza to, że wszystko jest albo 'paskudne stare rzeczy', albo 'ładne nowe rzeczy'. Po jednej lub drugiej stronie linii.

Linia jest postrzępiona, ponieważ migrujesz różne części system w różnym tempie.

W trakcie pracy, postrzępiona linia stopniowo opada, aż będziesz miał więcej bieli niż szarości, a w końcu tylko szarości.

Oczywiście, to nie ułatwia Ci szczegółów. Ale daje Ci model, którego możesz użyć do monitorowania swoich postępów. W każdym momencie powinieneś mieć jasne zrozumienie, gdzie znajduje się linia: które bity są nowe, które są stare i jak obie strony się komunikują.

Poniższy post może okazać się przydatny: http://refactoringin.net/?p=36

Jak to jest powiedziane w poście, nie odrzucaj pełnego nadpisania tak łatwo. Ponadto, jeśli to możliwe, spróbuj zastąpić całe warstwy lub warstwy rozwiązaniem innych firm, takim jak na przykład ORM dla trwałości lub nowym kodem. Ale co najważniejsze, spróbuj zrozumieć logikę (problem domeny) za kodem.