9 sposobów na opanowanie okropnego kodu, fast

otrzymałeś zadanie zaimplementowania nowej funkcji na Starym kodzie, ale kod wygląda okropnie. Jak możesz to zrozumieć tak szybko, jak to możliwe? Oto kilka skrótów, które pomogą nauczyć się ważnych części nowego kodu bez zagubienia się w nieistotnych szczegółach.

jako programiści często musimy dołączać do nowych projektów, a jakość kodu może być wszędzie. Nawet w przypadku zorganizowanego zespołu utrzymywanie spójności jakości kodu w ramach średniego i dużego projektu jest wyzwaniem.

dlatego szybkie zrozumienie słabego kodu może być cenną umiejętnością. Może pomóc ci stać się bardzo produktywnym w krótkim czasie i zmniejszyć stres, który zwykle wiąże się z byciem nowym facetem i koniecznością nadrobienia zaległości. Bycie w rozmowie ze współpracownikiem i niewiedza o tym, o czym ta osoba mówi przez połowę czasu, to straszne uczucie.

z drugiej strony, jest to doskonała okazja, aby pokazać klientowi lub szefowi swoją wartość i że możesz szybko uzyskać prędkość i zaimponować im. Większość programistów zajmuje tygodnie lub miesiące, aby stać się naprawdę produktywnym dzięki bazie kodu, której sami nie zbudowali.

oto jak szybko opanować okropny kod.

poproś o pomoc. To najskuteczniejsza strategia

inni już się dowiedzieli, jak działa kod, więc dlaczego ich o to nie zapytać? Możesz pomyśleć, że to sprawia, że wyglądasz jak początkujący, ale okazywanie ciekawości może mieć silny wpływ na twój wizerunek jako pracownika. Jeśli twoja Szefowa oczekiwała, że szybko osiągniesz produktywność bez zadawania pytań, to jest to błędna ocena z jej strony.

każdy potrzebuje czasu, aby nadrobić zaległości. Zadawaj pytania, a zaimponujesz ludziom, którzy mają odpowiednie podejście do pracy zespołowej.

w wielu przypadkach oryginalni Programiści podejmowali dziwne lub nieoczekiwane decyzje i właśnie tam mówienie o kodzie będzie o wiele bardziej wartościowe niż jego czytanie. Dzieje się tak nawet w przypadku braku dokumentacji. Pamiętaj, że istniejący programiści mają cenną wiedzę o projektach, która nie jest nigdzie zapisana.

stwórz listę pojęć, które nie mają dla ciebie sensu

mogą istnieć Koncepcje biznesowe, które są dla ciebie nowe lub zbyt złożone. Ważne jest, aby uzyskać wyjaśnienie na ich temat przed próbą pracy nad kodem, który obsługuje te pojęcia, aby uniknąć nieporozumień, które mogą trochę potrwać, aby je zrozumieć.

może się nawet zdarzyć, że te pomysły są błędnie oznaczone lub reprezentowane w nieoczekiwany sposób w bazie danych. Więc unikaj stresu z powodu owijania mózgu wokół tego, i po prostu idź do źródła i zapytaj o to swoich współpracowników.

w tym samym duchu mogą istnieć Moduły, klasy lub jednostki, które nie mają odpowiednich nazw. Zanotuj je. Źle nazwane elementy mogą prowadzić do wielkiego zamieszania, więc udokumentuj je wcześnie, a także cokolwiek innego, co negatywnie wpłynie na Twoją zdolność myślenia o tym, jak działa kod.

ułatwiaj odtwarzanie błędów

dodając wersjonowanie kodu i maszynę wirtualną, taką jak Docker lub Vagrant, znacznie skrócisz czas potrzebny na odtworzenie błędu i przetestowanie pracy nad nową funkcją.

jakiekolwiek nieporozumienie na temat działania kodu może doprowadzić cię do zbudowania niewłaściwej rzeczy, albo dlatego, że to, co budujesz, może już tam być i tego nie widziałeś, albo dlatego, że rzeczy po prostu nie działają tak, jak myślałeś.

w tym momencie chcesz mieć kontrolę wersji Git w swoim projekcie. W ten sposób będziesz mógł wrócić do wydania stabilnego, a nawet po prostu pracować nad oddzielnymi gałęziami, które w razie potrzeby można odrzucić.

jest nawet możliwe uzyskanie większej powtarzalności z Gitem, ponieważ możesz użyć skrytki, aby dodać testowanie lub debugowanie kodu podczas kopania w trudnym do wyśledzenia problemie.

aby dowiedzieć się więcej o architekturze swojego projektu, wcześnie podejmij zadania konfiguracyjne i dokumentacyjne.

to samo można powiedzieć o maszynach wirtualnych i odtwarzalności. Stały się wszechobecne dla każdego nowoczesnego zespołu programistów, ale z pewnością napotkasz projekty, które ich nie używają, a nawet są gotowe do uruchomienia w jednym. Czasami Twoim pierwszym krokiem jako nowego członka zespołu jest udokumentowanie kroków podjętych w celu uruchomienia środowiska i ostatecznie przekształcenie tych kroków w skrypt konfiguracji maszyny wirtualnej.

Zbuduj diagram komponentów

mapa myśli pojęć biznesowych, diagram ERD (entity-relational diagram) tabel bazy danych i prosty diagram komponentów kodu mogą znacznie pomóc zmniejszyć ból związany ze zrozumieniem nowego kodu. Nie pamiętasz, jak coś działa? Trzymaj otwarte ERD.

w rzeczywistości każde narzędzie graficzne, które pomaga szybko przetrawić informacje i mieć widok projektu na 10 000 stóp, będzie cenne. Inne przykłady narzędzi, które mogą Ci pomóc, to wykresy zależności, dzienniki i mapa stosu technologicznego projektu.

jednym z największych konsumentów czasu w rozwoju jest punkt integracji między systemami. Globalny wgląd w krajobraz projektu pomoże Ci określić, które punkty integracji są interesujące do zbadania. Są to miejsca, w które wkłada się najwięcej pracy i najwięcej błędów.

z drugiej strony, Technologia szybko się rozwija i mogą pojawić się możliwości zastąpienia dużej części kodu bardziej nowoczesnymi i odpowiednio zintegrowanymi rozwiązaniami. Stary framework mógł opracować nowy i oficjalny sposób rozwiązania problemu lub zupełnie nowa biblioteka mogła zostać opracowana z myślą o lepszej kompatybilności.

Użyj narzędzi do wizualizacji i modelowania, aby zobaczyć duży obraz.

przygotuj się do automatycznego testowania

zanim zaczniesz łamać rzeczy, zawsze rozsądnie jest dodać odpowiednie testy jednostkowe. Problem z testowaniem i słabym kodem polega na tym, że słaby kod jest zwykle ściśle sprzężony i trudny (jeśli nie niemożliwy) do przetestowania. Nie można izolować elementów, które są ze sobą splecione i niepodzielne.

w takich przypadkach zrób krok do tyłu i przetestuj z daleka. Zazwyczaj oznacza to przeprowadzenie testów integracyjnych, do których dostępnych jest wiele narzędzi. Aplikacje internetowe mogą być testowane pod kątem żądań HTTP, więc można przynajmniej sprawdzić, czy system będzie reagował w ten sam sposób na te same wejścia.

testy integracyjne mają jednak znacznie gorszą wydajność niż testy jednostkowe. Kiedy tylko możesz, zaimplementuj testy jednostkowe, aby mieć szybsze informacje zwrotne na temat zmian w kodzie. Jeśli nie jest to możliwe, wybierz test funkcjonalny lub nawet integracyjny.

ten krok powinien rzucić trochę światła na części kodu, które wymagają pracy. Jeśli istnieje duża ilość ściśle sprzężonego kodu, jest to dobry cel do refaktoryzacji po wykonaniu testów integracyjnych, a następnie do testów jednostkowych później.

Zidentyfikuj nietypowe lub nieodpowiednie strategie kodowania

nadszedł czas, aby rozpocząć refaktoryzację, ale od czego zacząć?

Zwykle najlepszym miejscem jest miejsce, w którym rzeczy wyglądają dziwnie lub gdzie nie stosuje się najlepszych praktyk w zakresie rozwoju. W przypadku tworzenia stron internetowych może to oznaczać Kontrolery fat ze ściśle sprzężonym kodem modelu.

pamiętaj, że te same strategie mogą być stosowane gdzie indziej. Jeśli więc na przykład zidentyfikujesz, że kontrolery fat są obecne, prawdopodobnie poprzedni programiści nie próbowali mieć kontrolerów thin. Możesz spodziewać się tego samego problemu również w innych kontrolerach, ponieważ odzwierciedlało to styl lub niedociągnięcia procesu programowania do tej pory.

na początku pracuj nad małym zadaniem

naprawienie małego błędu w funkcji, która jest koncepcyjnie prosta, będzie bardzo pouczające i pomoże Ci poczuć się produktywnym od samego początku.

jest to pomysł podobny do tego, co Andy Hunt i Dave Thomas nazywają “pociskami tracerowymi” w Pragmatic Programmer. Podstawowa logika jest taka sama: pracuj nad czymś od początku do końca, aby udowodnić sobie, że jest to możliwe, a następnie stopniowo ulepszaj tę początkową pracę.

zbliża się “pocisk tracer”. Kredyt: pragmatyczny programista

dobrym przykładem rodzaju prostego ulepszenia, które możesz zrobić, jest podjęcie małych kroków refaktoryzacji za pomocą prostego kodu. Zidentyfikuj powszechną praktykę programistyczną, która nie jest przestrzegana, i zastosuj ją.

jednym z moich ulubionych jest nie zagnieżdżanie bloków warunkowych. Zamiast więc mieć kilka bloków if-if-if, jeden wewnątrz drugiego, zaneguj pierwszy i zwróć, i zrób to samo dla wszystkich sprawdzeń typu walidacji, które możesz znaleźć. Może to być tak proste, jak odwrócenie kontroli “jeśli” i przesunięcie kodu wokół, więc ryzyko jest prawie nieistniejące, a kod płaski będzie łatwiejszy do odczytania.

pamiętaj, aby najpierw pracować nad funkcjami refaktoryzacji, które są łatwe do przetestowania, ponieważ mimo że zmiany są niskie, zawsze dobrym pomysłem jest sprawdzenie poprawności kodu przed wysłaniem go do produkcji.

zapoznaj się ze znajomością kodu, zanim zajmiesz się krytycznym kodem

zawsze dowiedz się, jak projekt jest skonfigurowany, a dopiero potem zanurz się w stronę architektury. Najważniejsze elementy kodu biznesowego i integracyjnego są najtrudniejsze do zrozumienia i modyfikacji. Unikaj kłopotów na początku.

zasadniczo unikaj problemów biznesowych, które wymagałyby więcej niż obecnie wiedzy na temat projektu lub strony biznesowej. Zwykle oznacza to, że trzymaj się z dala od transakcji, płatności lub matematycznego kodu, dopóki nie zacznie się on znajomy.

gdy jesteś produktywny, czujesz się komfortowo ze stylem kodowania dla projektu i nie masz problemu z rozwiązywaniem prostych problemów, nadszedł czas, aby pracować nad trudniejszymi rzeczami—ale nie wcześniej.

nawet jeśli istnieje pilna potrzeba na przykład naprawienia problemów z płatnościami, tego rodzaju zadanie może być niezwykle ryzykowne. Błąd może kosztować projekt drogo, i to będzie na Ciebie. Absolutnie odmawiaj wczesnej pracy nad zadaniami wysokiego ryzyka, jeśli w ogóle to możliwe.

jak radzić sobie z nieznanym stosem technologii

na koniec, częstym problemem, który napotkałem, jest to, że każdy nowy projekt zwykle zawiera jakąś technologię, z którą nie jestem zaznajomiony.

kiedy tak się dzieje, mam kilka strategii, które pomagają mi szybko przyspieszyć. Oczywistą drogą do nauki jest czytanie dokumentacji i zapoznanie się z nową technologią. Ale podczas gdy nauczysz się wiele o strukturze, ta ścieżka nie pomoże Ci nauczyć się przypadków narożnych, które zwykle wiążą się z doświadczeniem. (“Corner case” to termin techniczny, który odnosi się do sytuacji, która występuje poza normalnymi parametrami operacyjnymi.)

jednym ze sposobów na przyspieszenie tego procesu zdobywania doświadczenia jest wzięcie zasobów opartych na pytaniach, takich jak Stack Overflow i Quora i po prostu przeczytanie ich jak książki. Znajdź najpopularniejsze pytania dotyczące biblioteki, której się uczysz i zobacz, na jakie problemy zwykle napotykają inni ludzie. Nie koniecznie natkniesz się na nie sam, ale sama wiedza, co jest możliwe, jest jak rzucenie jasnego światła na mapę umysłu tych nowych pomysłów.

pytania dotyczące przepełnienia stosu dźwigni, aby szybko zdobyć doświadczenie. Kredyt: Stack Overflow

aby uzyskać bardziej ukierunkowane podejście, Znajdź informacje o funkcjach biblioteki używanych w nowym projekcie. Przyjrzyj się tym, które są dla Ciebie nowe i naucz się ich z wyprzedzeniem, zanim w ogóle będziesz musiał dotknąć tego kodu.

podziel się swoimi pomysłami