Dla każdego z Was stwierdzenie z tytułu jest zapewne czymś oczywistym, ponieważ usuwanie starego, zbędnego kodu jest, a przynajmniej powinno być, nieodłączną częścią rozwijania aplikacji, refaktoryzacji klas i ich zależności.
Oczywiście problem nie istnieje, jeżeli mówimy o usunięciu kilku linijek kodu, które właśnie zastępujemy czymś nowym. Chociaż i tutaj czasami programista nie decyduje się na usunięcie kodu, jeżeli potencjalny kandydat to metoda publiczna, a gdy kod jest w dodatku nie przetestowany! To komu szkodzi te kilka linijek więcej?
Mimo wszystko prawdziwym problemem są sytuacje, gdy zmieniamy kilka metod/zastępujemy klasę/klasy lub wykonujemy inne modyfikacje, których wynikiem powinno być pełne zastąpienie poprzedniego kodu. Strach przed użyciem klawisza delete jest potęgowany, jeżeli cierpimy na jakże powszechną przypadłość, znaną szerzej jako brak testów:)
Ale powyższe przypadki to i tak nie jest najgorsze co może Was spotkać. Może się okazać, że kod, który chcecie zmienić, to coś więcej niż kod, to magia i to magia w najczystszej postaci. Budowanie klas na podstawie parametrów, pobieranie tych parametrów z niewiadomokąd i niewiadomodlaczego, tworzenie powiązań z obiektami, które pojawiają się nagle i w niewiadomych okolicznościach. Metody, które raz są wykonywane, innym razem, przy bardzo podobnym zestawie danych, już nie. Za to odkrywasz inne:) I oczywiście brak testów:) A Ty masz coś z tym zrobić:)
Jak zacząć? Testy, dużo testów upłynie zanim będziesz mógł się zabrać do pracy. Nie mam na myśli jedynie testów jednostkowych, ale przede wszystkim akceptacyjne. Takie komponenty trzeba traktować jak czarne skrzynki (którymi właściwie są:). Nie wiesz, co siedzi w środku, nie chcesz wiedzieć, ale wiesz, że jeżeli przekażesz A, to otrzymasz B. I tą wiedzę tutaj musisz wykorzystać.
Wracając jednak do głównego wątku.
Udało Ci się wszystko napisać. Osiągnąłeś sukces, przynajmniej częściowy. Co teraz? Teraz należy przystąpić do usunięcia pozostałości po starym kodzie. Serce mocniej bije, bo przecież mogłeś coś pominąć, przeoczyć. Więc może lepiej zostawić to tak, jak jest? Nie. Kod, który z jakiś powodów został przepisany/zrefaktoryzowany/zamieniony powinien zniknąć z aplikacji. W innym wypadku jego obecność grozi ponownym, niezauważonym przez nikogo - użyciem. Do zespołu może dołączyć ktoś nowy, a przez review każdy przeleci bez uwagi (bo w końcu proste zadanie, gdzie tu błąd można zrobić?), a po jakimś czasie okaże się, że klasy, które miały popaść w zapomnienie są wykorzystywane w kodzie aplikacji:)
Zdaję sobie sprawę, że usuwanie kodu, który mógł być istotny dla działania aplikacji może być ryzykowne. Z drugiej jednak strony, co może się stać? Albo nic, jeżeli udało się znaleźć i zastąpić wszystkie wystąpienia starego kodu w aplikacji. Albo coś przestanie działać, a o tym z pewnością szybko klienci dadzą Wam znać:) Oczywiście druga alternatywa nie nastraja zbyt optymistycznie, ale pozostawienie nieużywanego kodu jest jak pozostawione w czasie wojny niewypały - niby niepotrzebne i nie powinny zadziałać (zostać użyte), ale czasami potrafią zaskoczyć, niestety negatywnie.
Brak komentarzy:
Prześlij komentarz