Legacy Never Die: How To Handle Legacy Code

Kiedy pojawia się termin „legacy code”, zwykle mówi się go lub otrzymuje z lekceważeniem. Wstępne wyszukiwanie w Google dla „legacy code memes” przywołuje setki makr obrazów ludzi wyrywających włosy, wyglądających na frazzled lub ogromnie rozczarowanych.

Kiedy zacząłem pracować jako programista 6 miesięcy temu, nie miałem pojęcia, co to jest legacy code ani co wiąże się z pracą z nim.

podczas mojego czwartego miesiąca jako młodszy programista, zostałem poproszony o Dodanie modułu filtra wyszukiwania do aplikacji zbudowanej przez jednego z moich współpracowników dwa lub trzy lata temu. Wydawało się to dość łatwe; spędziłem większość ostatnich czterech miesięcy pracując nad niesamowicie złożoną aplikacją dla innego klienta, w której mamy standardowy stos: TypeScript / React / Redux / Redux-Saga. Rozwiązałem już wiele unikalnych problemów i czułem się przekonany o mojej zdolności kodowania na tyle, aby zrobić prosty modal, aby przekazać parametry zapytania do zaplecza.

jak można się domyślić, nie było to takie proste. Ale dlaczego?

czym jest starszy kod i dlaczego radzenie sobie z nim może być trudne

starszy kod to kod odziedziczony od innego programisty lub zespołu, który korzysta ze starszych technologii, które nie są już obsługiwane lub zostały zastąpione przez nowszą wersję. Wielu programistów twierdzi, że”kod staje się kodem legacy zaraz po jego napisaniu”. Funkcjonalna różnica między” zwykłym ” kodem a starszym kodem może być po prostu taka, że ma on inne konwencje w porównaniu z tym, z czym jesteś przyzwyczajony do pracy.

w moim przypadku aplikacja została przypisana do wykorzystywanego przepływu, a nie maszynopisu, i to nie było tak mocno wpisane, jak byłem przyzwyczajony do. To sprawiło, że nieco trudniej było mi zrozumieć strukturę danych pobieranych z zaplecza. Brak typów oznacza, że częściej spotykałem się z TypeErrors w środowisku wykonawczym, co może być trudne do debugowania podczas pisania dużej funkcji. Oprócz tego, aplikacja używała znacznie starszej wersji Reacta, która musiała zostać pogodzona z kompatybilną wersją biblioteki komponentów, której chciałem użyć do zbudowania modalu.

zanim przejdę do sedna tego, jak radzić sobie ze starym kodem z poczuciem opanowania i racjonalności, chcę dodać zastrzeżenie, że stary kod nie jest cały zły i praca nad starym projektem nie musi być straszna. Wręcz przeciwnie, praca nad legacy code nauczyła mnie być elastycznym, cierpliwym, a przede wszystkim doświadczenie pozwoliło mi na rozwiązywanie problemów z nowej perspektywy w nowatorskim kontekście.

w rzeczywistości uczyniło mnie lepszym programistą niż wcześniej, zanim zacząłem pracować nad wspomnianym kodem, i mam nadzieję, że Twój legacy projekt też może cię czegoś nauczyć.

jak radzić sobie ze starym kodem na poziomie technicznym

Photo by Jeff Sheldon on Unsplash

Read documentation and code comments when possible

w idealnym świecie każda baza kodu ma solidny README, który zawiera zwięzłe wyjaśnienia, jak działa projekt, komentarze kodu, które wyjaśniają dokładną logikę oryginalnego autora, a cała aplikacja ma doskonały sens. Jednak rzadko tak się dzieje. Wiele czytań nie jest aktualizowanych w miarę rozwoju projektów, ludzie zapominają pisać komentarze, zakładają, że ich logika jest oczywista dla nowego dewelopera lub po prostu kończy im się czas na zajęcie się tymi sprawami.

spójrz na kod jako całość

Jeśli zgubiłeś się i nie wiesz od czego zacząć, zadaj sobie następujące pytania:

• jaki jest cel aplikacji?
• jak dane przepływają przez aplikację?
• jak twoja funkcja pasuje do aplikacji?

Kiedy masz poczucie szerszej perspektywy, łatwiej jest wymyślić, jak najlepiej rozwiązać problem. Może trzeba utworzyć nowy plik i utworzyć nowy komponent. Może trzeba napisać funkcję użytkową i przetestować go. Niezależnie od przypadku zrozumienie szerszego kontekstu problemu jest dobrym pierwszym krokiem do stworzenia rozwiązania.

przetestuj aplikację ręcznie i za pomocą testów jednostkowych, jeśli to możliwe

tymczasowe złamanie aplikacji podczas dodawania nowej funkcji jest nieuniknione, bez względu na to, na jakim poziomie jesteś programistą. Jest to normalne i oczekiwane, zwłaszcza jeśli jesteś nowy w pracy, pracujesz w starszej bazie kodu z nieznanym stosem lub jakąś kombinacją tych dwóch.

najlepszym sposobem, aby zapobiec tym uszkodzeniom, które stają się długoterminowymi problemami, jest dokładne przetestowanie aplikacji zarówno za pomocą testów jednostkowych, jak i testów ręcznych. Posiadanie tych testów i dokładna wiedza o tym, jaki rodzaj pokrycia z nich uzyskasz, pozwoli zaoszczędzić Tobie i przyszłym programistom dużo czasu. Ponadto rygorystyczne testy sprawiają, że aplikacja jest bardziej skalowalna, a także zapewniają lite dopaminy za każdym razem, gdy testy są czyste.

do testów jednostkowych można użyć frameworków testowych takich jak jest lub jaśmin.

w przypadku testów ręcznych należy opracować matrycę testową i upewnić się, że dokument jest dostępny dla przyszłych programistów. W przypadku macierzy będziesz chciał zdefiniować zestaw działań, oczekiwane zachowanie, rzeczywiste zachowanie podczas testowania i wszelkie inne ważne szczegóły, takie jak:

w przyszłym poście na blogu omówię, jak efektywnie wdrożyć oba typy testów do twojego przepływu pracy.

poproś o pomoc

zakładając, że twój projekt został napisany przez obecnego lub byłego pracownika w Twoim miejscu pracy, ktoś inny prawdopodobnie wie, co dzieje się w aplikacji, lub przynajmniej wie wystarczająco dużo, aby cię odłączyć. Nauka połykania dumy i zadawania pytań jest dla niektórych niewygodnym krokiem, ale niezbędnym do rozwoju jako programista, a może twój współpracownik nauczy cię kilku nowych sztuczek.

dobrym sposobem na efektywne wykorzystanie swojego czasu (i ich) jest formułowanie świadomych pytań. Spróbuj wrócić do spojrzenia na bazę kodu jako całość i rozwiąż luki w swoim zrozumieniu. Nie tylko pomoże im to lepiej zrozumieć, na czym polega twój problem, ale pokazuje, że podjąłeś inicjatywę, próbując najpierw rozwiązać problem na własną rękę.

Wiedz, kiedy zmniejszyć straty

Jeśli spędzasz zbyt dużo czasu próbując dostać się do drzwi i nie zrobiłeś poważnego kroku w kierunku wdrożenia funkcji po wypróbowaniu powyższych kroków, może warto zmienić kod wokół funkcji. Nie poddawaj się zbyt łatwo, ale pamiętaj, jakie są Twoje terminy i czego oczekuje od Ciebie kierownik projektu.

To powiedziawszy, są wady, aby tak to zrobić:

• przepisywanie kodu może wprowadzić błędy, chociaż można to nieco obejść dzięki dobrym testom jednostkowym.
• przepisywanie kodu może usunąć ukrytą funkcjonalność, choć można to również obejść dobrymi testami jednostkowymi.
• jeśli naciskasz na czas, pisanie kodu poza funkcją może być bardziej czasochłonne niż budowanie wokół niej.

w sumie wykorzystaj swój najlepszy osąd. Istnieją plusy i minusy każdego wyboru, a wszystko zależy od indywidualnych okoliczności i budżetu projektu.

jak radzić sobie ze starszym kodem na poziomie psychologicznym

Zdjęcie Simona Migaja na Unsplash

teraz, gdy omówiliśmy techniczne aspekty radzenia sobie ze starszym kodem, porozmawiajmy o tym, jak radzić sobie z nim za pomocą naszych umiejętności miękkich. W końcu Programiści to ludzie, a nie tylko roboty programistyczne, a radzenie sobie z trudnymi problemami w projektach, które wymagają kreatywności i autorstwa, może być emocjonalnie obciążające, nie tylko dla ciebie, ale także dla Twoich współpracowników.

bądź skromny i miły

To jest coś, co nieśmiało przyznam, że muszę więcej ćwiczyć. Kiedy po raz pierwszy przydzielono mi projekt modalny filtra, byłem dość głośny o tym, jak janky i nieatrakcyjny kod miał sobie poradzić, podczas gdy oryginalny autor kodu siedział 15 stóp ode mnie. Chciałem, aby moje komentarze były żartem, ale z perspektywy czasu zdaję sobie sprawę, że byłem arogancki i krzywdzący, i że powinienem być bardziej empatyczny.

istnieje wiele czynników, które mogą prowadzić do tego, że starszy kod wygląda „off”, które powinieneś wziąć pod uwagę, zanim zaczniesz krytykować autora lub zakładać najgorsze o nim (jest to luźno związane z podstawowym błędem atrybucji!).

oryginalny autor mógł mieć powody do pisania kodu w taki sposób, w jaki to zrobił.

Ograniczenia czasowe i technologiczne mogą spowodować, że osoba napisze kod, który działa, ale niekoniecznie ma najlepszą konwencję. Jeśli wyobrażasz sobie siebie w sytuacji z niewystarczającą ilością czasu, przestarzałymi narzędziami i długą na kilometr listą rzeczy do zrobienia, prawdopodobnie nie napisałbyś też najlepszego kodu!

konwencje się zmieniają.

w starszych projektach Olio Apps konwencją kodu jest używanie pojedynczych cudzysłowów do deklarowania ciągów, a dwie spacje były równe jednej tabulacji. Mieliśmy wiele małych komponentów Reactowych zagnieżdżonych w jednym pliku. W naszej obecnej konwencji używamy podwójnych cudzysłowów i czterech spacji, a każdy komponent Reactowy, niezależnie od tego, jak mały, znajduje się we własnym pliku .tsx w katalogu component. I za kilka lat, jestem pewien, że to też się zmieni.

cały kod w końcu staje się dziedziczny

To wiąże się z poprzednim punktem: Twój kod w końcu stanie się dziedziczny. Gdy awansujesz po drabinie starszeństwa, nowi Programiści zostaną zatrudnieni i będą musieli utrzymywać twój stary kod. Możesz napisać czysty, nieskazitelny, suchy kod, ale gdy konwencje się zmienią lub zmienią się trendy, ci nowi programiści mogą zobaczyć Twój kod w taki sam sposób, w jaki widzisz stary kod innych.

Szczyć się małymi sukcesami

nie jest łatwo pracować poza zwykłymi konwencjami; jest powód do ogromnej ilości memów i żartów na temat radzenia sobie ze starym kodem. Jeśli kiedykolwiek nauczyłeś się języka poza ojczystym językiem, wiesz, jak to jest zapomnieć słowo lub termin w drugim języku, ale zapamiętać go w swoim ojczystym języku i nie być w stanie przetłumaczyć przez lukę. To samo dotyczy zmiany między konwencjami modern i legacy. Czasami odzyskanie pozycji zajmuje tylko minutę.

będąc w stanie skutecznie poruszać się po starszym kodzie, pokazujesz swoją zdolność do adaptacji, co jest ważną umiejętnością, która przynosi korzyści w obecnej pracy i wszystkich przyszłych pracach, niezależnie od tego, czy są to prace w dziedzinie technologii, czy nie. Legacy code to idealne miejsce do Ćwiczenia tej umiejętności.

podsumowując:

wykorzystaj ten czas na wzmocnienie własnego pisania kodu

teraz, gdy masz już doświadczenie w pracy w legacy codebase, powinieneś odejść od niego z lepszym poczuciem tego, co lubisz, a czego nie lubisz pod względem narzędzi i konwencji. Są to rzeczy, które możesz kontynuować w przyszłych projektach i poprawić przegląd kodu innych, oferując konstruktywną krytykę i udzielając mentoringu.

Tworzenie aplikacji dla użytkownika i przyszłego programisty

niezależnie od tego, czy masz doświadczenie z doskonałą dokumentacją i komentarzami do kodu, czy nie masz dokumentacji lub komentarzy do kodu, możesz zobaczyć, jak zarówno dokumentacja, jak i komentarze są potężnymi narzędziami, które pomagają przyszłym programistom poruszać się po projekcie. Masz wspólny cel, jakim jest potrzeba płynnej, funkcjonalnej i suchej aplikacji; utrzymanie dokumentacji i pozostawienie informacyjnych komentarzy do kodu jest dobrym sposobem na wypełnienie tej luki.

pamiętaj, że Twój kod będzie kiedyś dziedziczny

wspominałem o tym już kilka razy, ale ważne jest, aby powtórzyć, że Twój kod będzie również dziedziczny, bez względu na to, jak suchy i nieskazitelny jest Twój kod i logika.

najważniejsze jest bycie elastycznym, skromnym i to, że na pewno można nauczyć się nowych sztuczek ze starego kodu.