Czy ktoś mógłby wyjaśnić zalety usuwania (lub zachowania) nieużywanego kodu?

Wielokrotnie słyszałem, że nieużywany kod trzeba usunąć z projektu. Jednak nie jest dla mnie jasne „dlaczego?”.

Moje punkty za nieusuwanie, które są:

• Kod jest już napisany, a wysiłki są wydawane
• Kod można testować w środowisku syntetycznym i rzeczywistym
• Jeśli jest dobrze zorganizowany (zgrupowany, oddzielny pakiet, luźno powiązany itp.), Nie przeszkadza Ci w ogólnej analizie lub refaktoryzacji kodu
• Kod może zostać użyty w przyszłości
• Po usunięciu autor może czuć się nieswojo

Czy ktoś mógłby wyjaśnić zalety usuwania (lub zachowania) nieużywanego kodu?

Oto kilka powodów, dla których nieużywany kod powinien zostać usunięty:

• Każdy, kto dopiero zaczyna pracę nad projektem, musi nie tylko rozumieć działający kod, ale także rozumieć nieużywane materiały. To strata czasu i powoduje zamieszanie.

• Istnieje niebezpieczeństwo, że kiedyś ktoś dokona zmiany, która nieumyślnie dotyczy „uśpionego” kodu i może wprowadzić błędy. Wiem, że stało się to przy projektach, nad którymi pracowałem.

• Utrzymanie dowolnego kodu jest obciążeniem administracyjnym. Zachowanie starego, nadmiarowego kodu zwiększa obciążenie. Na przykład scalanie zmian w głównej gałęzi staje się trudniejsze, ponieważ jest więcej kodu do przepracowania i więcej możliwości popełnienia błędu.

• To, co dzieje się z biegiem czasu, polega na tym, że do bazy kodu dodaje się coraz więcej starego, nieużywanego kodu. Zwiększa to zamieszanie, potencjalne nieporozumienia i ogólne koszty administracyjne.

• Szanse, że nieużywany kod kiedykolwiek zostanie ponownie użyty, są bardzo mało prawdopodobne. Z czasem ta możliwość ponownego wykorzystania maleje. Jeśli kod ma zostać usunięty i jest uważany za wystarczająco ważny, wówczas można go rozgałęzić i udokumentować.

• Wszelkie osobiste odczucia programisty dotyczące kodu, nad którym mógł ciężko pracować, są zrozumiałe. Ale część bycia profesjonalistą wymaga odłożenia tych myśli na bok dla lepszego dobra. Czas nie jest dla nikogo i nie ma miejsca na przechowywanie kodu historycznego w działającym kodzie źródłowym.

@suspectus wykonał świetną robotę, przedstawiając powody usunięcia kodu; Chciałbym zająć się Twoimi indywidualnymi punktami dotyczącymi przechowywania kodu.

• Kod jest już napisany, a wysiłki są wydawane

Ale jeśli już napisany kod nie jest używany, jest to koszt tylko bez (przyszłej) wartości. Jest to wysiłek włożony na próżno, a zachowanie niewykorzystanego produktu tych wysiłków nie potwierdza tych wysiłków. Utrzymujemy kod, ponieważ jest teraz użyteczny, a nie jako swego rodzaju pamiątka po wysiłkach autorów.

• Kod można testować w środowisku syntetycznym i rzeczywistym

Przepraszam, nie wiem, co przez to rozumiesz.

• Jeśli jest dobrze zorganizowany (zgrupowany, oddzielny pakiet, luźno powiązany itp.), Nie przeszkadza Ci w ogólnej analizie lub refaktoryzacji kodu

Jeśli istnieje w bazie kodu, bez względu na to, jak dobrze jest zorganizowany, przyczynia się do obciążenia związanego z utrzymaniem i zrozumieniem. Prawdą jest, że można to zorganizować tak, aby było mniejszym ciężarem, ale jeśli zniknie, w ogóle nie będzie obciążeniem.

• Kod może zostać użyty w przyszłości

W szkole Agile mówimy YAGNI : nie będziesz tego potrzebować. Tak, być może przyda Ci się to w przyszłości, ale dziś nie możemy wystarczająco wiedzieć o potrzebach jutra, aby móc to przewidzieć z jakąkolwiek niezawodnością. Myślenie inaczej jest równoznaczne z pychą. Co nas może wiedzieć o jutro to: chcemy, aby nasza baza kodu, aby był łatwy do zmodyfikowania, a niewykorzystane umniejsza kod z tej cechy.

• Po usunięciu autor może czuć się nieswojo

Autor musi się z tym pogodzić. Wszyscy napisaliśmy rzeczy, które okazały się nieprzydatne - o wiele lepiej jest móc wskazać cały kod, który jest używany (ponieważ nieużywany cruft został usunięty) niż zbiór kodu, w którym można powiedzieć kilka metod, "a ta jest aktualnie w użyciu!"

Czy nie jest wystarczająco trudne zebranie kodu i ustalenie celu, ale teraz musisz dowiedzieć się, które części nie są używane?

Kod jest już napisany, a wysiłki są wydawane

To też jest niepotrzebne. Jeśli nie używasz go do niczego, jest (z definicji) bezużyteczny, niezależnie od tego, co robi i ile wysiłku na to włożono.

Kod można testować w środowisku syntetycznym i rzeczywistym

Jeśli jest bezużyteczny, nadal jest bezużyteczny, nawet jeśli masz na nim testy. Jeśli kod jest bezużyteczny, testy dla niego również powinny być bezużyteczne (więc trzymanie tam skomentowanego kodu stwarza niejednoznaczność - czy zachowujesz testy? Jeśli miałeś kod klienta komentowanego kodu, czy komentujesz również kod klienta? )

Jeśli jest dobrze zorganizowany (zgrupowany, oddzielny pakiet, luźno powiązany itp.), Nie przeszkadza Ci w ogólnej analizie lub refaktoryzacji kodu

Skąd. Wszystkie Twoje narzędzia (kontrola źródła, analiza statyczna, ekstraktor dokumentacji, kompilator itp.) Będą działać wolniej, ponieważ muszą przetwarzać więcej danych (a większa lub mniejsza część tych danych to szum).

Z drugiej strony, jeśli kod nie jest dobrze zorganizowany, zepsuje analizę statyczną, refaktoryzację i inne.

Wprowadzasz szum do danych wejściowych narzędzi i masz nadzieję, że sobie z nim poradzą.

Co się stanie, jeśli narzędzie do analizy statycznej obliczy stosunek komentarzy do kodu? Po prostu schrzaniłeś coś, co było istotne do wczoraj (lub za każdym razem, gdy kod był komentowany).

Co najważniejsze, skomentowane bloki kodu wprowadzają opóźnienia w zrozumieniu kodu w celu utrzymania i dalszego rozwoju, a takie opóźnienia prawie zawsze kosztują dużo. Zadaj sobie następujące pytanie: jeśli chcesz zrozumieć implementację funkcji, na co wolałbyś raczej spojrzeć? dwa wiersze czystego kodu lub dwa wiersze kodu i kolejne dwadzieścia sześć komentarzy, które nie są już aktualne?

Kod może zostać użyty w przyszłości

Jeśli tak, znajdziesz go w wybranym przez siebie systemie zarządzania treścią.

Jeśli używasz kompetentnego SCM i polegasz na nim, aby zachować martwy kod (zamiast zaśmiecać źródło), powinieneś zobaczyć nie tylko, kto usunął ten kod (autor zatwierdzenia), ale z jakiego powodu (komunikat o zatwierdzeniu) i jakie jeszcze zmiany zostały wprowadzone wraz z nim (reszta różnic dla tego zatwierdzenia).

Po usunięciu autor może czuć się nieswojo

Więc?

Jesteście (zakładam) całym zespołem programistów, któremu płaci się za tworzenie najlepszego oprogramowania, jakie umiecie, a nie „najlepsze oprogramowanie, jakie umiecie, bez ranienia uczuć X”.

Jest to część programowania, w której większość napisanego kodu zostanie ostatecznie odrzucona; na przykład Joel Spolsky powiedział w pewnym momencie, że w przypadku jego firmy około 2% napisanego kodu to produkcja.

Jeśli przedkładasz ego programistów nad jakość kodu, poświęcisz jakość swojego produktu dla ... co dokładnie? Zachowujesz niedojrzałość innych programistów? Chroniąc nierealistyczne oczekiwania swoich kolegów?

Edycja: Widziałem jeden ważny powód, aby zostawić zakomentowany kod w źródle i jest to bardzo szczególny przypadek: kiedy kod jest napisany w dziwnej / nieintuicyjnej formie, a czysty sposób ponownego przepisania go nie działa pracować z naprawdę subtelnego powodu. Należy to również zastosować dopiero po ponownej próbie naprawienia problemu i za każdym razem, gdy próba powoduje ponowne wprowadzenie tej samej usterki. W takim przypadku należy dodać skomentowany intuicyjny kod jako komentarz i wyjaśnić, dlaczego nie działa (aby przyszli programiści nie spróbowali ponownie tej samej zmiany):

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

Martwy kod zanieczyszcza Twój kod

Martwy kod zmniejsza zrozumiałość i czytelność.

Najlepsze kody są zawsze używane ponownie, a jeśli masz martwe kody, zmniejsza to możliwość ponownego wykorzystania

Kierujemy się modułowym podejściem do kodowania, w którym projektujemy kody do interakcji z innymi programistami, a nie dla maszyny. Powinniśmy włożyć najwięcej energii, aby ułatwić mu zrozumienie naszego kodu. Maszyna i tak będzie dobrze.

Martwy lub skomentowany kod jest jak fałszywe znaki drogowe, które tylko dezorientują ludzi, więc unikaj go za wszelką cenę.

• Strach . To sprawia, że ​​zespół bardziej się martwi i produkuje mniej. Strach rośnie wykładniczo, gdy wprowadza się więcej martwego kodu. „Nie wiemy, czy ten kawałek jest używany, więc nie odważymy się go usunąć ani dotknąć”.

• Ogromne zmiany . Jeśli coś, co trzeba zmienić w całym systemie, również istnieje w martwym kodzie, czy zmieniasz to? Bardzo trudno jest wiedzieć, czy zdecydowanie nie jest gdzieś używany, więc zawsze jest to ryzyko. A nawet gdyby niczego nie zepsuło, czy martwy kod w ogóle działałby, gdyby został przywrócony do użytku po tej zmianie?

  Mając do czynienia z rozległą zmianą, programiści będą musieli również sprawdzić każde miejsce zawierające kod, aw przypadku martwego kodu jest to zbędne. A sprawdzenie ich trwa dłużej, gdy kod jest martwy, ponieważ trudno jest zweryfikować, czy nie jest nigdzie używany.

• Obciążenie psychiczne . Za każdym razem, gdy musisz pomyśleć o tym, czy coś jest używane lub czy powinieneś coś zrobić z martwym kodem, wymaga to trochę mocy twojego mózgu.
• Pościgi dzikich gęsi . „Potrzebuję przykładu, jak używać Foobara. Och, jest w tych miejscach w bazie kodu. Sprawdzę pierwsze trafienie i dowiem się, gdzie to jest w interfejsie użytkownika. Hmm… Nigdzie go nie mogę znaleźć”.
• Rozszerzone raporty (np. Ile wierszy kodu, klas, procedur, zmian). Zakłóca widoczność projektu i decyzje dotyczące części kodu źródłowego, nad którymi należy pracować, oraz oceny przyszłych projektów.
• Osłabione zaufanie do bazy kodu . Może to spowodować więcej czasu spędzonego na zbędnych zadaniach i przerywa przepływ korzystania z bazy kodu. Deweloperzy być może będą musieli bardzo dokładnie sprawdzić, czy wszystko, czego używają, będzie działać tak, jak ich zdaniem powinno.

Jest to niezwykle cenne, jeśli wiesz, że część bazy kodu nie jest używana, ponieważ wtedy możesz ją usunąć. Jeśli pozwolisz mu pozostać, to w przyszłości może być trudne lub prawie niemożliwe uzyskanie pewności, że faktycznie nie jest ono używane. Na przykład niektóre rzeczy, które wykorzystują kod w zaskakujący sposób: odbicie, dynamiczne wywoływanie procedur połączonych z ciągami znaków, eval, magia frameworka .

Jeśli jednak istnieje duże prawdopodobieństwo, że kod zostanie użyty w przyszłości, łatwiej jest dodać, jeśli znajduje się obok innego kodu zamiast w systemie kontroli wersji. Po pewnym czasie możesz nie pamiętać żadnych słów, które zawierał kod, więc znalezienie kodu z trzewi VCS może być bardzo trudne. Ale ja pozwoliłbym, żeby martwy kod istniał rzadko, a nawet wtedy skomentowałbym go.

• Nieużywany kod to większa przestrzeń wyszukiwania, którą możesz przeczytać zarówno dla Ciebie, jak i dla wszystkiego, co zazwyczaj skanuje Twój kod. Na przykład kompilator, IDE, znajdź w pliku, debugowanie, analiza statyczna, więcej do przejrzenia, dołączenie pliku, wyewidencjonowanie z VCS itp. Spowalnia to te procesy i dodaje znaczący szum.
• Nieużywany kod nie zawsze jest martwy. Może to nastąpić w pewnych okolicznościach. Może to nie tylko stanowić źródło błędów i problemów z wydajnością, ale może również stanowić zagrożenie dla bezpieczeństwa. W odniesieniu do wydajności może to wyrażać się w nieoczekiwany sposób, na przykład w przypadku większych pobrań.
• Niewykorzystany kod rodzi nieużywany kod. Jeśli usuniesz wywołanie funkcji, a następnie wyszukasz zastosowania tej funkcji, aby sprawdzić, czy nadal jest potrzebne, możesz zobaczyć dopasowanie z poprzedniego nieużywanego kodu i założyć, że możesz go zachować. Im więcej masz nieużywanego kodu, tym więcej przeskoków pozwala określić, czy kod jest nieużywany.
• Niewykorzystany kod nadal często wymaga konserwacji. Powiedzmy, że A i B zależą od C. Z tych B nie jest używane. Zmieniasz C, a następnie B nie będzie kompilować, ponieważ usunąłeś element członkowski ze struktury w C, której wymagał B, teraz musisz naprawić B lub aktywnie usunąć go z kompilacji. Powinieneś po prostu go usunąć.

Ta lista może wydawać się prosta, ale każdy z nich przejawia się na setki różnych sposobów, dodając opór, który zapewnia synergię w całym procesie rozwoju. Nieefektywność można często udowodnić lub wykazać w prosty i matematyczny sposób.

W odpowiedzi na Twoje uwagi ...

• Kod jest już napisany, a wysiłki są wydawane

Ale często trzeba to utrzymywać. Będzie również nadal pojawiać się w rzeczach, takich jak znajdowanie w pliku.

• Kod można testować w środowisku syntetycznym i rzeczywistym

Nie jestem pewien, co masz na myśli przez to. Myślę, że jest taki sam jak poprzedni. Masz na myśli, że kod jest już przetestowany, a jego wyczyszczenie może oznaczać konieczność ponownego przetestowania. Jest to koszt, który zwykle jest tego wart, ponieważ opłaci się w 90% przypadków i aby uniknąć sytuacji, w której powinien zostać wyczyszczony przed rozpoczęciem produkcji. Prawie cały kod ma dwie iteracje, spraw, aby działał, spraw, aby był czysty. Powód, dla którego trzeba testować dwukrotnie, jest taki, że ktoś pominął ostatni krok. Jeśli twój kod jest również zbyt drogi, aby sprawdzić, czy odczytać różnice, przetestować (co prawdopodobnie jest bałagan z dużą ilością nieużywanego kodu), itd., To kolejny problem.

• Jeśli jest dobrze zorganizowany (zgrupowany, oddzielny pakiet, luźno powiązany itp.), Nie przeszkadza Ci w ogólnej analizie lub refaktoryzacji kodu

Twój kod i tak powinien być taki, ale to tylko umiarkowanie łagodzi problem. To najdziwniejszy argument, gdy słyszy się, że coś powinno być zorganizowane, ale nieczyste. To normalne, że próbujesz zachować modularny kod i zmniejszyć zależności, ale chcesz również kodu wielokrotnego użytku, a jeśli wszystkie twoje moduły są wyspami, prawdopodobnie nie byłeś SUCHY. Może się również zdarzyć, że nadmiernie odsprzęgasz, co nie robi nic, ale łagodzi problem nieużywanego niechlujnego kodu.

• Kod może zostać użyty w przyszłości

Wiele osób ponad ceni napisany kod. Jeśli nie jest teraz używany, jest to deadweight, aw rzeczywistości, gdy idziesz tą ścieżką, często tylko ułamek nieużywanego kodu staje się kodem używanym. Najprawdopodobniej nieużywany kod prawdopodobnie nie będzie użyteczny lub używany. Najprawdopodobniej zostanie ponownie użyty kod, który już jest używany.

Co gorsza, nieużywany kod nie ma celu. Kiedy ktoś przyjdzie i będzie musiał zmienić coś, co ostatecznie wpłynie na nieużywany kod, będzie zaskoczony, siedząc tam, próbując dowiedzieć się, co ten nieużywany kod musi robić bez celu.

Ludziom łatwo jest się tak czuć, gdy zaczynając pracę nad kodem, trzeba dużo wysiłku. Jednak gdy już biegnie i przyzwyczaisz się do tego kod, staje się jak jazda na rowerze. Przekonasz się, że koszt napisania takiego fragmentu kodu gwałtownie spada, koszt jego utrzymania rośnie.

• Po usunięciu autor może czuć się nieswojo

To jest problem autora. Z jednej strony pozostawienie mnóstwa niewykorzystanego kodu dla innych jest samolubne. Z drugiej strony, jeśli autor stawia swoje uczucia na jakości kodu, prawdopodobnie nie powinien kodować. Idziesz dalej z tym, że nie możesz naprawić ich kodu, gdy jest zepsuty, ponieważ zrani ich uczucia. To nie jest dobry znak, jeśli ktoś jest przywiązany do kodu tylko dlatego, że jest jego, a nie dlatego, że jest dobry. Autor powinien czuć się zadowolony, że jego kod został wyczyszczony. To tak, jakby ktoś wynosił dla Ciebie śmieci i wrzucał je do kosza.

Byłbym oszołomiony, gdyby ktoś zrobił to za mnie. To, co może ułatwić przezwyciężenie tych uczuć, to zamiast czekać, aż ktoś inny to zrobi, spróbuje zrobić to sam. Kontynuuj iteracyjne przepisywanie kawałka kodu, który zrobiłeś, sprawiając, że działa lepiej, porusza się zwięźle, z mniejszym nadmiarem i bardziej elastycznym, ale za każdym razem z mniejszą ilością kodu. Staraj się nie czuć dobrze z ilością kodu, ale z tym, ile możesz osiągnąć przy niewielkiej ilości kodu. To mielenie w celu podniesienia poziomu, a kiedy już to zrobisz, cały kod będzie na dobrym poziomie, więc nie będzie trzeba go tak często poziomować.

Przede wszystkim należy zawsze używać narzędzia do kontroli źródła do zarządzania projektami, dlatego usuwanie nieużywanego kodu jest dobrą praktyką, ponieważ zawsze można wrócić, korzystając z kontroli źródła, aby uzyskać usunięty kod. Dla mnie powodem usunięcia nieużywanego kodu jest to, że wie o nim tylko osoba, która wie, że kod jest nieużywany, ktoś inny z zespołu natrafi na ten kod i spróbuje dowiedzieć się, co robi i jak pasuje do całej aplikacji i poczuje się zawiedziony po takim wysiłku, że kod w ogóle nie jest używany :)

Ta dyskusja ma kilka lat, ale właśnie ją spotkałem ...

Jedyną rzeczą, o której nie wspomniałem, jest praca, którą należy ponieść, aby usunąć nieużywany kod. W wielu przypadkach czas i wysiłek związany z usunięciem nieużywanego kodu nie jest z natury trywialny, a testowanie i dokumentowanie refaktoryzowanego systemu wiąże się z dodatkowymi kosztami. Kolejna rzecz do rozważenia w procesie decyzyjnym.

Myślę, że możesz mieć dwa przypadki: - kod aplikacji: jeśli jest nieużywany, może jest nieprzetestowany i nie jest utrzymywany przez czas, może możesz przejść do „wewnętrznego repozytorium kodu” - kod API: jeśli piszesz bibliotekę, to IMHO jest to lepszy wybór, aby go utrzymać, ale w ramach aktywnego procesu rozwoju

Czy na pewno kod jest nieużywany?

Nie wystarczy sprawdzić, czy kod nadal się kompiluje. W C ++, jeśli usuniesz „nieużywaną” niejawnie zdefiniowaną metodę, tak operator=jakbyś nie wystąpił błąd kompilatora, klasa po cichu zacznie używać (potencjalnie niepoprawnej) domyślnej implementacji. W Javie lub C # kod może być używany przez odbicie. W językach obiektowych dziedziczenie może odgrywać rolę (można teraz wywołać klasę bazową). W prawie każdym języku może przejąć inną przeciążoną funkcję.

Sprawdź wiek kodu w kontroli wersji, a nie tylko to, że jest nieużywany. Widziałem kod, który wyglądał na nieużywany, ale został właśnie zatwierdzony i był właściwie pierwszym krokiem w projekcie innego dewelopera.

Agresywnie usuń nieużywany kod

Za utrzymanie kodu płacisz:

• Naprawianie zepsutych kompilacji (czas inżynierii). Niedawno mieliśmy skomplikowany łańcuch#include zmian, wprowadzający nowe przeciążenie do nieużywanego kodu, co doprowadziło do rozsądnego bólu głowy dla każdego inżyniera w zespole kilkudziesięciu programistów.
• W zasobach maszynowych w testach (zakładając, że masz ciągłe kompilacje samokontroli). Mój zespół niedawno przyjrzał się wszystkim naszym najwolniejszym testom i wiele z nich zawierało nieużywany kod. Inżynierowie wykonujący testy lokalnie lub w ramach ciągłej integracji czekają na testy nad nieużywanym kodem.
• Pod względem czytelności (znowu inżynieria). Twoje pliki nagłówkowe reprezentują API. Jeśli zawierają funkcje, których nikt nie chciałby używać, ale każdy musi czytać, krzywa uczenia się twojego kodu jest o wiele trudniejsza.
• W wyszukiwaniu kodu (znowu czas inżynierii). Czy posprzątałeś swój dom, dysk twardy lub Dysk Google? Im częściej przeszukujesz domenę, tym ważniejsze jest, aby zawierała odpowiednią treść, aby uniknąć fałszywych trafień (lub korzystasz z bardziej wyrafinowanego wyszukiwania, takiego jak wyszukiwarka internetowa).

Powiedziałbym, że zasadniczo cały kod, który pisze przeciętny programista, staje się nieużywany w perspektywie pięciu lat, więc ta aktywność nigdy się nie kończy. Nie pozwól, żebyś to był ty; pisz tylko wysokiej jakości i absolutnie niezbędny kod.