Chciałbym zadać ci kilka pytań na temat brudnego kodu. Jest kilku początkujących, którzy napisali kod na średnim projekcie. Kod jest bardzo wielką kulą błota. Nie są zaawansowanymi programistami. Oni po prostu wiedzą, jak używać klawiatury trochę o Javie. Właśnie napisali kod zawierający 12 000 linii w swojej głównej klasie, jednak 6 000 linii należy do samego NetBeans.
Moim zadaniem jest analiza kodu i zasugerowanie dobrego sposobu na utrzymanie kodu. Moim pomysłem jest złomowanie projektu i rozpoczęcie nowego z metodologią OOP. Ostatnio zebrałem kilka uwag i pomysłów na temat problemu, z tej strony i kilku innych.
Teraz mam następujące pytania:
- Czy powinniśmy naprawić kod i zmienić go na OOP? Teraz go debugujemy.
- Kod nie ma komentarzy, żadnej dokumentacji, żadnego konkretnego stylu programowania i tak dalej. Zmiana jest naprawdę droga i czasochłonna. Co możemy z tym zrobić?
- Jak mogę nauczyć ich przestrzegania wszystkich zasad (komentowanie, OOP, dobra jakość kodu itp.)?
- Kod jest błędny i podatny na błędy. Co możemy zrobić? Testujesz? Prawie piszemy dwa lub trzy papiery A4 do korekty, ale wydaje się to nie mieć końca.
Powinienem powiedzieć, że jestem z nimi nowy. Wydaje mi się, że złamałem zasady dotyczące dodawania osób zbyt późno do projektu. Myślisz, że muszę je zostawić?
źródło
Odpowiedzi:
Krok 0: Wykonaj kopię zapasową w SCM
Ponieważ, jak wskazał JBRWilkinson w komentarzach, kontrola wersji jest pierwszą linią obrony przed (nieodwracalną) katastrofą.
Wykonaj także kopie zapasowe szczegółów konfiguracji oprogramowania, procedur tworzenia rezultatów itp.
Krok 1: Najpierw przetestuj
Następnie zacznij od napisania testów :
Bez względu na to, co zdecydujesz się zrobić, jesteś objęty ubezpieczeniem. Możesz teraz:
Radzę rozpocząć od zera ogólną architekturę , ale wyodrębnij z bałaganu części, które sprawdzają poprawność punktów kontrolnych, i przebuduj je według własnego uznania.
Krok 2: Sprawdź i monitoruj
Skonfiguruj system ciągłej integracji (w celu uzupełnienia kroku 0 i kroku 1 ) ORAZ system ciągłej kontroli (w celu przygotowania do kroku 4 ).
Krok 3: Stań na barkach gigantów
(jak zawsze powinieneś ...)
Krok 4: Oczyść
Jest to oczywiste, ale zamiast przeszukiwać kod samodzielnie, możesz po prostu uruchomić analizatory statyczne / statyczne i inne narzędzia na uszkodzonej bazie kodu, aby znaleźć błędy w projekcie i implementacji.
Następnie możesz także uruchomić formater kodu, który już trochę pomoże w utrzymaniu porządku.
Krok 5: Przejrzyj
Łatwo jest wprowadzać drobne błędy, refaktoryzując lub sprzątając. Wymaga tylko złego wyboru i szybkiego naciśnięcia klawisza, a możesz usunąć coś dość ważnego, nie zdając sobie z tego sprawy. A czasem efekt pojawi się dopiero kilka miesięcy później. Oczywiście powyższe kroki pomogą ci tego uniknąć (szczególnie poprzez wdrożenie silnej uprzęży testowej), ale nigdy nie wiesz, co może i prześlizgnie się. Pamiętaj więc o sprawdzeniu refaktoryzacji przez co najmniej jedną dedykowaną parę gałek ocznych (a najlepiej nawet więcej).
Krok 6: Przyszłościowy proces rozwoju
Weź wszystkie powyższe i uczyń je nieodłączną częścią zwykłego procesu programowania, jeśli już nie jest. Nie pozwól, aby powtórzyło się to na zegarku, i współpracuj ze swoim zespołem, aby wdrożyć zabezpieczenia w swoim procesie i egzekwować to (jeśli to możliwe) w swoich zasadach. Uczyń tworzenie Czystego Kodu priorytetem.
Ale naprawdę przetestuj . Wiele .
źródło
Osobiście nie chciałbym rozpocząć tego projektu, dopóki nie będę mieć pod ręką kopii Efektywnie działającej z Legacy Code . Poważnie, został napisany właśnie dla tego rodzaju rzeczy. Jest pełen strategii radzenia sobie z trudnym kodem i zawiera dużo więcej szczegółów, niż mogę tutaj podać.
źródło
Byłem tam kilka razy. Moja zasada brzmi: jeśli oprogramowanie nie jest trywialne (więcej niż 1 tydzień pracy dla posiadanego zasobu) i działa, to zachowaj je i kontynuuj stopniowe refaktoryzowanie.
Jeśli oprogramowanie tak naprawdę nie działa (bardzo duża liczba błędów, niejasne wymagania itp.), Lepiej przepisać je od nowa. To samo, jeśli jest dość małe.
Istotą refaktoryzacji (jak w książce Fowlera i Kerievsky'ego http://www.industriallogic.com/xp/refactoring/ ) jest to, że utrzymuje ona system w działaniu, być może refaktoryzacja zajmie dwa razy, ale ryzyko jest zerowe.
Przepisywanie od zera może wprowadzić wiele zagrożeń, od nieporozumień po niewłaściwe wdrożenie (w końcu większość zespołu będzie taka sama).
W rzeczywistości widziałem, jak skomplikowana procedura była przepisywana od zera dwa razy i nadal nie działała zgodnie z oczekiwaniami.
źródło
Chciałbym to całkowicie napisać od nowa. Czasami nie można naprawić takiego kodu. Inną opcją jest uruchomienie go bez dodawania nowych funkcji. Aby nauczyć zespół pisać dobry kod (dobrze zaprojektowany, udokumentowany, z testami), pozwól mu naprawić kod, który masz teraz. Pozwól wszystkim naprawić błędy / przejrzeć kod innych programistów, a nie jego / jego części. Po kilku próbach zrozumieją, że przeglądanie / naprawa takich kodów jest prawie niemożliwa.
Dodawanie ludzi do późnych projektów pomaga bardzo rzadko. Zwykle przekracza terminy. Powinieneś zrobić wszystko, aby pomyślnie zakończyć projekt, a następnie pomyśleć o odejściu.
źródło
Moja rada nie będzie polegała na całkowitym usunięciu całego kodu. To codzienny problem, z którym boryka się każdy zespół programistów. Atakuj jedną część kodu naraz. Napraw to, wyczyść, udokumentuj. A następnie przejdź do drugiej części. Najważniejsze, aby zawsze mieć pod ręką kod wysyłkowy. Przepisanie całego kodu od zera zajmie tyle czasu, ile do tej pory spędzono i nie będzie żadnej gwarancji, że będzie ładniejszy niż obecny.
Ale także ludzie powinni unikać pisania kodu w ten sposób. Poświęć trochę czasu na recenzje kodu. Dostosuj się do jednolitego stylu kodowania. Omów najpierw projekt, a następnie napisz kod. Takie proste rzeczy wprowadzą duże zmiany.
Ładny blog informujący, dlaczego Netscape przegrał
źródło
Jeśli to działa, refaktoryzuj to. Istnieją narzędzia, które pomogą Ci to zrobić. Jeśli to nie działa, użyj polecenia poprawy kodu magicznego, tj. W
deltreesystemie Windows lub.rm -rfw systemie Linux.źródło
Byłem tam, masz moje współczucie. Napisałem nawet artykuł na ten temat, który może pomóc ci uzyskać perspektywę. Ale w skrócie:
Jeśli kod zawiera dużo powielania, należy przepisać. Jeśli nie ma dostrzegalnej struktury (brak przejrzystych interfejsów, spaghetti), refaktoryzacja zakończy się niepowodzeniem i prawdopodobnie powinieneś przepisać.
Zacznij od wyjaśnienia, dlaczego mogliby to zrobić, pokazując im, co mogą na tym zyskać osobiście. Kiedy się z tym zgodzą i będą chcieli się uczyć, zacznij ich uczyć za pomocą shuhari .
źródło
Moja sugestia jest kombinacją odpowiedzi @ duros i @Manoj R.
Zacznij od zera, pamiętając o tym, aby tym razem stworzyć dobry kod / OOP / skomentował / etc. Gdy napotkasz złe części starego kodu, przepisz je / prześlij ponownie.
Jeśli twoi programiści nie są dobrze wyszkoleni, myślę, że dobrze jest wysłać ich na kursy. Jest to ważne dla regularnego przekwalifikowania w szybko zmieniającej się branży IT
źródło