Jak ustalić, czy w kontroli źródła jest przydatny usunięty kod?

Czytałem więc to pytanie. Czy powinienem usunąć kod, do którego nie ma odniesienia?

Niektóre z porad polegały na usunięciu kodu, do którego nie ma odniesienia, ponieważ kod ten znajduje się w kontroli źródła w celu późniejszego wykorzystania w razie potrzeby.

Jak zorganizujesz ten usunięty kod, aby późniejsza wersja ciebie (lub inny programista) mogła go później znaleźć? Czy tworzysz oddzielną gałąź lub jakoś tagujesz ją w kontroli źródła?

Nigdy wcześniej nie wskrzesiłem usuniętego kodu spod kontroli źródła, głównie używałem go do śledzenia zmian w kodzie, który jest nadal aktywny. Odniosłem się już do gałęzi, gdy zawierały czyjeś prace eksperymentalne, więc może to dobry sposób na oznaczenie interesujących fragmentów kodu, które są usuwane z pnia?

O ile nie eksperymentujesz w oddziale i nie jesteś jeszcze pewien, które rozwiązanie ostatecznie zostanie ponownie zintegrowane, zwykle nie odwołujesz się do usuniętego kodu.

W bardzo rzadkich przypadkach możesz jawnie kopać w poszukiwaniu usuniętego kodu, który niejasno przypomina sobie rozwiązanie problemu, który masz teraz . Ale bardziej typowym powodem, dla którego widzisz usunięty kod, jest przeglądanie rejestru, aby zrozumieć coś o bieżącym kodzie lub zachowaniu aplikacji w odniesieniu do jej kodu historycznego lub zachowania.

W szczególności możesz być ...

• przeprowadzanie ogólnego przeglądu kodu / rozumienie refaktora
• szukam zatwierdzenia, które wprowadziło błąd X.
• zaspokajanie ciekawości / szukanie zmian, które rozwiązały błąd
• ponowne wdrożenie funkcji lub podobnej funkcji
• zrozumienie kodu lub danych, które wydają się działać w połączeniu z kodem, który nie istnieje

... itd.

W takich przypadkach zazwyczaj nie wskrzeszasz starego kodu. Jesteś po prostu zrozumieć coś, czego widzieć teraz za pomocą kodu usunięte do kontekstu lub wskazówek.

Myślę, że odpowiedź brzmi: zdecydowana większość programistów nie dba o odniesienie do usuniętego kodu. Z kilku powodów. Oto kilka powodów, które przychodzą mi na myśl:

• Prawdopodobnie najważniejsze, czyste lenistwo ...

• Większość nigdy nie odczuwała potrzeby wskrzeszenia jakiegoś kodu, więc nie mają doświadczenia, które motywuje ich do ułatwienia wskrzeszania kodu.

• Większość usuniętego kodu jest usuwana z określonego powodu. Zwykle jest zastępowany przez inny, lepszy, funkcjonalnie równoważny lub mocniejszy kod. Dlaczego ktokolwiek miałby chcieć wskrzesić gorszy kod?

  Zauważ, że jest to również kwestia psychologiczna: większość programistów jest dość dumna z wyników swojej pracy. Jak mogło się kiedykolwiek wydawać, że to, co zastąpili, miało pewną wartość?

• Ponieważ większość kodu nie jest czysto usuwana, ale zastępowana, interfejsy, które zostały zmienione podczas przejścia, dostarczają wystarczających informacji, jeśli naprawdę trzeba wyśledzić usunięty kod z powodu pewnych regresji wprowadzonych przez nowy kod.

Ale niezależnie od tego, ile mniej lub bardziej uzasadnionych powodów możesz pominąć martwy kod, myślę, że to po prostu „nie przejmuj się” ze strony programistów. I nawet jeśli spróbujesz oznaczyć usunięte elementy w taki czy inny sposób, bądź przygotowany na całkowite zignorowanie tego wysiłku ...

To pytanie prawdopodobnie opiera się na „Jak zachować identyfikowalność swoich kontroli VCS względem bazy danych błędów i wymagań systemowych?”

Czasy, w których ludzie przechodzą do wskrzeszenia kodu z kontroli źródła, to zwykle czasy, w których dowiadujesz się, że coś nieumyślnie się zepsuło i trzeba je przywrócić.

Najważniejszą rzeczą w tym scenariuszu dla kogoś, kto szuka określonego fragmentu usuniętego kodu, jest to, że może łatwo go prześledzić, przeglądając bazę danych wymagań i narzędzie do śledzenia błędów; ponieważ prawdopodobnie szukają określonego wymagania lub słów opisujących funkcjonalność. Jest mało prawdopodobne, aby znali nazwę pliku źródłowego lub usuniętą klasę / funkcję.

Jeśli chcesz śledzić ciekawy / eksperymentalny kod, który należy usunąć przed wydaniem, możesz po prostu prześledzić go za pomocą biletów „błędów” w stylu „Usuń nieużywany kod dla ...” . A może wprowadzić do systemu nowy typ biletu dla funkcji Prototype .

Aby odpowiedzieć bezpośrednio na pytanie - nie używaj gałęzi / tagów w systemie VCS do śledzenia usuniętego kodu - skorzystaj z narzędzia do śledzenia zmian.

Ta rada jest przeznaczona dla osób, które przechowują przestarzały kod w bazie danych „na wszelki wypadek”. Ponieważ kod nadal będzie istniał w kontroli źródła, nie powinieneś obawiać się jego usunięcia. Naprawdę nie organizujesz usuniętego kodu jako takiego, ponieważ chodzi o to, że nie jest już potrzebny. Po prostu dodajesz komunikat zatwierdzenia, który wskazuje, co zostało zmienione i usunięte w zatwierdzeniu. Najbardziej odpowiedni komunikat zatwierdzenia dla usuniętego kodu to komunikat w momencie dodania kodu, a nie komunikat, gdy został ponownie usunięty.

„Praca eksperymentalna” to naprawdę inna kwestia. Powinieneś mieć do tego oddzielny oddział.