Czy powinienem usunąć niepowiązany kod?

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

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.

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.

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.

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.

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Ś .

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.

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.

„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).

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.

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.

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.

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.

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

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.

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.)

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.