Czy powinienem usunąć niepowiązany kod?

118

Pracuję na bazie kodu średniej wielkości (100 tys. Linii), to wszystko jest stosunkowo nowy kod (mniej niż roczny) i ma dobry zasięg testu jednostkowego.

Ciągle natrafiam na metody, które albo nigdzie już nie są używane, albo są wymieniane tylko w testach jednostkowych, które testują tylko tę określoną metodę.

Czy powinienem usunąć ten kod, jeśli jestem pewien, że nie jest już potrzebny?

Powody, aby go usunąć:

  • Mniej kodu, mniej błędów
  • Mniej kodu jest łatwiejsze do strawienia dla innych
  • Nadal jest pod kontrolą źródła

Powody, dla których warto to zachować:

  • Może być stosowany jako odniesienie
  • Może się przydać
  • Być może został napisany w celu „zaokrąglenia” funkcjonalności klasy
Simon Hutton
źródło
22
„Mniej kodu, mniej błędów” - jeśli naprawdę nigdy nie są używane, prawdopodobnie nie powodują błędów
Konrad Morawski
19
@Morawski Ale jeśli zostanie pozostawiony, pewnego dnia zostanie wykorzystany. A ponieważ nie został utrzymany, będzie zawierał błędy, które następnie się pojawią.
DJClayworth
9
Zazwyczaj komentowałem to i testy, które od niego zależą, a następnie zostawiam komentarz „TODO” z datą. Kiedy nie był używany przez rok, rzuciłem go. Inni zalecają usunięcie go teraz, ale jest to trudne, szczególnie jeśli wygląda na to, że kod był kiedyś przydatny.
Job
31
@Job Jeśli napotkam skomentowany kod, jest on usuwany. Bez wymówek. Skomentowany kod krzyczy „Nie ufam naszemu systemowi kontroli źródła”. Dla mnie.
Kristof Provost
26
@Kristof Provost, skąd miałbyś wiedzieć, że użyteczny kod był kiedyś w pliku źródłowym A, jeśli już go nie ma? oczywiście zawsze możesz sprawdzić historię pliku, w którym się znajdujesz, ale jak często myślisz sobie: „Hm ... muszę tu zmienić / wdrożyć funkcję. Albo muszę przetestować, jak to działało 5 lat temu SZYBKO. Zastanawiam się, czy ktoś już go zaimplementował, a następnie usunął ... pozwól mi sprawdzić historię ". Nie opowiadam się za utrzymywaniem bałaganu, ale zdarzają się sytuacje, w których nie używasz kodu w środowisku produkcyjnym, ale potrzebujesz go / czasami potrzebuję do debugowania itp.
Job

Odpowiedzi:

219

Mówiąc prościej, większość powodów, dla których warto go zachować, jest zupełnie nieistotna. Jeśli kod nie jest używany, wyrzuć go - wszelkie korzyści związane z jego utrzymaniem można w prosty sposób uzyskać z kontroli źródła. Co najwyżej zostaw komentarz, w której wersji go znaleźć.

Po prostu, im wcześniej wycinasz kod, tym szybciej nie musisz tracić czasu na jego utrzymanie, kompilowanie i testowanie. Korzyści te znacznie przewyższają trywialne korzyści, które przedstawiłeś, z których wszystkie i tak można uzyskać z kontroli źródła.

DeadMG
źródło
30
Zgadzam się na usunięcie go, ale miałem przypadki, w których coś zepsułem, ponieważ ktoś używał „nieużywanego” kodu przez odbicie. Tak czy inaczej należy zachować ostrożność.
Falcon,
14
@ Falcon, to dobry powód, aby usunąć go jak najszybciej, zanim ludzie zaczną go używać lub odkryją potrzebę upublicznienia.
StuperUser
6
@ Falcon: To twierdzenie OP, że kod nie jest używany.
DeadMG,
4
@StuperUser: Całkowicie się zgadzam. Ale należy zachować ostrożność i przygotować się na nieoczekiwane.
Falcon
18
Jeśli go usuniesz, a testy jednostkowe i regresyjne zakończą się pomyślnie, ale produkt się zepsuje, będzie to mocny argument za ustawieniem pewnego rodzaju narzędzi do pokrywania kodu.
Andrew T Finnell,
43

Wszystkie powody, aby go usunąć, stoją.

Powody, dla których warto to zachować:

  • Może być stosowany jako odniesienie
  • Może się przydać
  • Być może został napisany w celu „zaokrąglenia” funkcjonalności klasy

Wszystkie te powody, aby go zachować, będą zarządzane przez kontrolę źródła. Usuń go z aktywnego kodu, a będziesz mógł go odzyskać, jeśli / kiedy będzie potrzebny.

StuperUser
źródło
1
Tak, niepowiązanego kodu nie należy pozostawiać w kodzie aktywnym.
xdazz
Wydaje mi się, że te korzyści można uzyskać po prostu komentując duże fragmenty.
Steve Bennett
@ SteveBennett Rzeczywiście, ale źle rozumiesz sens tej odpowiedzi. Wymieniam korzyści płynące z komentowania, chodzi o to, że uzyskasz wszystkie ORAZ WIĘCEJ korzyści z kontroli źródła (co zobaczysz w innych odpowiedziach).
StuperUser
Na pewno nie jestem przeciwko VCS. :) (Zauważam jednak, że po usunięciu rzeczy z bieżącej wersji jest to znacznie mniej widoczne niż inne podejścia, takie jak przechowywanie ich w pliku tekstowym bez odnośników, na wiki, w komentarzach itp.)
Steve Bennett
@Steve Bennet - Może być „mniej widoczny” niż komentarze w bieżącej wersji pliku, ale trywialne jest sprawdzenie historii VCS pojedynczego pliku, i powiedziałbym, że jest znacznie łatwiejsze niż txt-file / wiki / etc. .. podejścia.
Zach Lysobey,
23

Kod bez odniesień jest taki sam, jak trzymanie baterii, które są dość płaskie, na wypadek, gdybyś potrzebował ich pewnego dnia na pochodnię.

Tak długo, jak używasz jakiejś kontroli wersji, powiedziałbym, że wyrzuć ją z aktywnego kodu i użyj historii wersji na wypadek, gdyby okazało się to przydatne.

Nicholas Smith
źródło
40
Aby nieco poprawić analogię, przypomina to trzymanie prawie wyczerpanych baterii przyklejonych do pilota, zamiast w pudełku obok nowych baterii w pomieszczeniu z napisem „zużyte, ale nie wyczerpane baterie”.
Scott Whitlock,
Plus 1 za znacznie lepszą poprawę!
Nicholas Smith
15

Jedynym dobrym powodem, dla którego widzę kod, który nie jest aktualnie używany, jest to, że jest on częścią samodzielnego modułu: Chociaż niektóre części kodu mogą nie być w tej chwili używane, może być tak, że będą używane w przyszłości.

Może to być szczególnie prawdziwe w przypadku biblioteki używanej w różnych projektach: nie chcesz ciągle wrzucać i wyrzucać fragmentów kodu, zgodnie z tym, czego potrzebujesz dla konkretnego projektu: Uważam, że jest to czasochłonne i podatne na błędy.

Moje podejście jest następujące: (1) jeśli użyjesz go raz, zachowaj tylko to, czego naprawdę potrzebujesz; (2) jeśli użyjesz go dwa razy, skopiuj go i dostosuj za drugim razem; (3) jeśli używasz go więcej niż dwa razy, stwórz z niego dobrze zdefiniowany, stabilny moduł i używaj tego modułu, jak potrzebujesz.

Podsumowując: wyrzuciłbym cały nieużywany kod, chyba że jest on częścią modułu ogólnego przeznaczenia, który zaprojektowałeś jako taki i że wiesz, że zamierzasz użyć go kilka razy.

Uwaga : Oczywiście jeszcze czystszym rozwiązaniem byłoby utworzenie osobnego projektu dla biblioteki i dodanie zależności między projektami.

Giorgio
źródło
1
Jako przykład tego mam kilka procedur bibliotecznych, które odczytują i zapisują różnego rodzaju podpisane i niepodpisane typy danych w tablicy bajtów. Wydaje się czystsze mieć zestaw takich procedur dla wszystkich typów danych, niż mieć niektóre, a niektóre nie, w zależności od tego, czego wymaga obecnie kod.
supercat
11

Ogólnie rzecz biorąc, pokłoniłbym się w tej sprawie YAGNI. Jeśli „nie będziesz go potrzebować”, to po prostu zajmuje miejsce w twojej bazie kodu, testach jednostkowych i zestawach. Być może będziesz go potrzebować, ale możesz też całkowicie go przepisać, ponieważ od teraz do momentu, gdy będziesz czegoś podobnego, wiele może się zmienić.

Jednak to się nieco zmienia, gdy piszesz narzędzie lub interfejs API przeznaczony do ogólnego użytku. Tak jak nigdy nie można oczekiwać, że użytkownicy końcowi będą wchodzić w interakcje z oprogramowaniem w zamierzony sposób, nigdy nie można oczekiwać, że konsumenci Twojego kodu będą chcieli używać kodu dokładnie tak, jak ci się wydaje. W takich przypadkach, o ile można uzasadnić istnienie metody za pomocą „jest to prawidłowy sposób na interakcję z moim obiektem”, prawdopodobnie powinna ona wejść, ponieważ nawet jeśli jej nie będziesz potrzebować, szanse są duże, KOGOŚ .

KeithS
źródło
8

Biorąc pod uwagę, że podstawa kodu ma mniej niż rok, prawdopodobnie nadal jest w dużej mierze zmienna (tak?) - więc pogląd, że niektóre bity mogą wymagać wskrzeszenia w niedalekiej przyszłości, nie jest nieuzasadniony.

W przypadku bitów, które były trudne do uzyskania w pierwszej kolejności i wydają się bardziej prawdopodobne, że zostaną wskrzeszone, utrzymałbym je nieco bardziej „na żywo” niż tylko kontrola źródła. Ludzie nie będą wiedzieć / pamiętać, że istnieją - powiedzenie „możesz po prostu znaleźć w kontroli źródła” zakłada, że ​​wiesz / pamiętasz, że tam jest! W takich przypadkach rozważ wycofanie (z showstopper „aser (false)”) lub skomentowanie.

Ed Staub
źródło
5
+1 za „powiedzenie„ możesz to po prostu znaleźć w kontroli źródła ”zakłada, że ​​wiesz / pamiętasz, że tam jest!” - czasami znajduję małe przypomnienia o kodzie, który został wycięty jako pomocny z jakiegoś powodu.
Steven
3

Jeśli kod jest trywialny i nieciekawy, po prostu go wyrzucam, aby pozbyć się niepotrzebnej bezwładności systemu oprogramowania.

Dla interesujących zwłok kodu używam archivegałęzi w moich systemach kontroli wersji.

fresnel
źródło
3

„Może być użyty jako odniesienie” Nie zgodziłbym się z dobrym powodem do pozostawienia nieużywanego kodu. Często tylko niewielka część nieużywanego kodu faktycznie pokazuje coś interesującego. Istnieje wiele sposobów dokumentowania i przechowywania przydatnego, ale nieużywanego kodu.

Chociaż kontrola wersji będzie zawierała historię, która z łatwością pozwoli przywrócić określoną funkcjonalność, jeśli później zdecydujesz, że kod jest potrzebny, wiedząc, że musisz zajrzeć do historii kontroli wersji, aby znaleźć xy lub z, kto wie, która poprzednia wersja może być trochę nudne i często pomijane, chyba że masz dość konkretne pojęcie, czego szukasz.

Kod można skomentować z notatką o tym, kiedy został usunięty i dlaczego nie został po prostu usunięty z kodu. Jest to jednak ogólnie uważane za zły styl, a kod, który nie jest używany i nie jest odpowiednio utrzymywany, może wprowadzać różnego rodzaju błędy, jeśli później nie zostanie skomentowany, więc jest to ogólnie lepsze jako tymczasowy etap debugowania / testowania podczas pośredniego refaktoryzacji niż sposób na opuszczenie kodu produkcyjnego.

Moim ulubionym sposobem przechowywania usuniętego kodu, jeśli wydaje się on przydatny w przyszłości, jest utworzenie dodatkowego dokumentu referencyjnego zawierającego wszystkie różne fragmenty wartościowego usuniętego kodu. Każdy blok kodu jest opatrzony krótką wzmianką o tym, skąd pochodzi lub o czymkolwiek innym, co należy zapamiętać, na przykład kiedy został usunięty lub numer wersji, w której był ostatni w kodzie. Wszystko, co zostało usunięte, ale „potencjalnie przydatne” jest w jednym miejscu, łatwe do przeszukiwania, ale nie wymaga ciągłego wysiłku w celu utrzymania i testowania na bieżąco (testowanie jest odraczane do momentu ponownego wprowadzenia kodu).

Jessica Brown
źródło
2

Jednym z dobrych powodów, aby zachować nieużywane metody, są: można ich użyć w innych gałęziach / tagach!

Przeglądaj wszystkie aktywne gałęzie i tagi przed ich usunięciem.

smakować
źródło
To nie ma dla mnie sensu: jeśli nie jest używany w tej gałęzi, usuń go z tej gałęzi. Jeśli inny oddział go wykorzysta, pozostanie tam.
sleske
1

Jeśli korzystasz z systemu kontroli wersji, nie martw się o przyszłe odniesienia, ponieważ możesz po prostu przejrzeć historię tego kodu i znaleźć usuniętą część. Jeśli tego nie zrobisz i uważasz, że któregoś dnia zostanie użyty, po prostu pozwól mu pozostać, ale skomentuj go opisem wyjaśniającym, dlaczego jest komentowany.

Jeśli jednak masz pewność, że nie będziesz go używać w przyszłości, po prostu go usuń . Myślę, że powody, o których wspomniałeś, są dość proste do usunięcia kodu.

Ale proszę, zanim go usuniesz, upewnij się, że nie jest nigdzie używany. Visual Studio ma funkcję o nazwie Znajdź wszystkie referencje, która przeszukuje całe rozwiązanie i znajduje dowolne odwołanie do bieżącej zmiennej, metody, właściwości, klasy, interfejsu itp. Zawsze usuwam część odnośnika przed usunięciem części mojego kodu.

Saeed Neamati
źródło
1

Stosunkowo często miałem doświadczenie w znalezieniu funkcji, która wygląda tak, że zrobi dokładnie to, czego potrzebuję, i ufając jej, że zadziała, ponieważ jest produkowana od dłuższego czasu, ale okazało się, że nie była używana kilka lat. Nieużywany kod nie jest utrzymywany i chociaż mógł działać lata temu, API wokół niego zmieniło się na tyle, że nie można mu ufać.

W najlepszym razie spędzasz dużo czasu, upewniając się, że nadal robi to, co chcesz. W najgorszym przypadku wydaje się, że działa, dopóki nie zostaniesz ugryziony paskudnym błędem później i dłużej go śledzisz, ponieważ zakładasz, że kod „przetestowany podczas produkcji” działa, więc problem musi znajdować się gdzie indziej w nowym kodzie. Z mojego doświadczenia wynika, że ​​prawie zawsze szybciej jest napisać nową funkcję samodzielnie.

Jeśli go usuniesz, ale stosunkowo szybko się dowiesz, że naprawdę go potrzebujesz, jest to pod kontrolą źródła. Jeśli nie potrzebujesz go, dopóki nie upłynie tak dużo czasu, że nie pamiętasz, że jest pod kontrolą źródła, prawdopodobnie lepiej jest napisać go od zera.

Karl Bielefeldt
źródło
1

Nic nie zajmuje mniej czasu niż brak kodu.

Jeśli musisz zanurzyć się w bazie kodu, potrzebujesz trochę czasu, aby dowiedzieć się, do czego ten kod jest używany, a jeśli jest używany do niczego, potrzebujesz jeszcze więcej czasu.

Ok - to może być uleczone jako komentarz, ale z drugiej strony wszyscy będą rozumować, dlaczego ten nieużywany kod nadal znajduje się w bazie kodu, czy powinien zostać usunięty, czy nie.

Jeśli nic nie ma, nikt nie straci z tym czasu.

Jeśli trudno było go poprawnie uzyskać, potrzebujesz dobrej dokumentacji, że ten kod istnieje, ale jeśli baza kodów ewoluuje w trakcie kilku iteracji, być może przestanie działać, jeśli zostanie ponownie aktywowana.

nieznany użytkownik
źródło
1

Usuń nieużywany kod - mniej bałaganu, lepsze zrozumienie. Twój system kontroli wersji zajmie się tym. Ponadto, jeśli używasz czegoś lepszego niż notatnik, twoje środowisko pozwoli ci użyć starszego kodu w celach informacyjnych.

Długie komentarze starego kodu rozpraszają uwagę i utrudniają nawigację.

pozdrowienia

Luca Botti
źródło
1

Postępuj zgodnie z tym prostym algorytmem:

  1. Czy ma kopię zapasową w SCM? Jeśli tak, przejdź do 3.
  2. Skonfiguruj SCM.
  3. Wyrzuć to .

Wszystkie twoje punkty za usunięcie są ważne.

Wszystkie twoje punkty za utrzymanie bałaganu są nieważne, gdy masz SCM, aby go wyszukać lub przywrócić. W rzeczywistości twój SCM powinien być w stanie pomóc ci ustalić, dlaczego ten kod jest tutaj i nieużywany, jeśli został użyty poprawnie.

Z jakiegoś powodu nazywa się to „martwym kodem”. Niech umrze i spoczywa w pokoju.

Haylem
źródło
0

Pozostanie pod kontrolą źródła; nie powinien pozostać w aktywnej bazie kodu.

Jedynym wyjątkiem jest to, że kod kończy projektowanie i chociaż nie używasz kodu, planujesz w końcu upublicznić kod, a inni mogą chcieć tej podstawowej funkcjonalności. Następnie po prostu zaprojektuj testy, aby upewnić się, że te części kodu działają naśladując sposób, w jaki sugerujesz innym, że mogą korzystać z tych części kodu. Jeśli jednak zastanawiasz się nad usunięciem kodu i nie możesz znaleźć solidnego powodu, aby go zatrzymać, powinien on odejść. Nieużywany kod sprawia, że ​​każdy ma więcej pracy (trudniej odczytać kod; kod może być uszkodzony; więcej pracy w utrzymaniu; itp.)

dr jimbob
źródło
0

Z mojego doświadczenia wynika, że ​​usuwanie nieużywanego kodu również może spowodować błąd. Możesz zapomnieć, że masz ten kod i nie będziesz go szukał w historii. Lub możesz nie wiedzieć, że ktoś zaimplementował ten kod, a następnie usunął go później. Znów nie będziesz tego szukać w historii ...

Niewątpliwie nieużywany kod to nieprzyjemny zapach.

AKTUALIZACJA: Właśnie zauważyłem, że Ed Staub udzielił bardzo podobnej odpowiedzi.

Ali
źródło