Nie mam prawie rocznego doświadczenia w kodowaniu. Po rozpoczęciu pracy przez większość czasu pracowałem nad kodem innej osoby, dodając nowe funkcje do istniejących lub modyfikując istniejące. Facet, który napisał właściwy kod, już nie działa w mojej firmie. Trudno mi zrozumieć jego kod i wykonywać swoje zadania. Ilekroć próbowałem zmodyfikować kod, w jakiś sposób pomieszałem z działającymi funkcjami. O czym powinienem pamiętać, pracując nad kodem innej osoby?
architecture
coding-style
coding-standards
coding
maintenance
nieznanych
źródło
źródło
Odpowiedzi:
Czy kod zawiera testy jednostkowe? Jeśli nie, zdecydowanie sugeruję, abyś zaczął je dodawać. W ten sposób możesz napisać nowe funkcje / poprawki błędów jako nieudane testy, a następnie zmodyfikować kod przekazywany przez test. Im więcej z nich zbudujesz, tym większa pewność, że dodany kod nie zepsuł czegoś innego.
Pisanie testów jednostkowych dla niezrozumiałego kodu pomoże ci zrozumieć ten kod. Oczywiście testy funkcjonalne należy dodać, jeśli jeszcze nie istnieją. Mam wrażenie, że te już istniały z pytania OP. Jeśli się mylę w tej kwestii, te testy funkcjonalne powinny być twoim pierwszym krokiem.
Eagle76dk ma świetny pomysł na zaangażowanie swojego kierownika w tę pracę - więcej szczegółów w poście Eagle76dk.
Ponadto podczas pisania tych testów zachęcam do próby napisania testów, aby zweryfikowały one zachowanie biznesowe, które metoda mogła próbować osiągnąć, a nie zachowanie kodu. Nie zakładaj też wcale, że zachowania biznesowe widoczne w kodzie są prawidłowe - jeśli masz kogoś, kto mógłby powiedzieć ci, co powinna robić aplikacja, jest to w wielu przypadkach bardziej wartościowe niż to, co może ci powiedzieć kod.
źródło
Oprócz innej odpowiedzi, w której wspomniano o testach jednostkowych, sugeruję, aby upewnić się, że wszystko jest pod kontrolą wersji, aby można było łatwo przywrócić zmiany. I wprowadzanie drobnych zmian, aby kod był łatwiejszy w utrzymaniu.
źródło
Moim zdaniem najszybszym sposobem na nauczenie się kodu innej osoby (szczególnie gdy zmiany wywołują nieoczekiwane zachowanie, jak to opisujesz) jest przejście przez kod za pomocą debugera .
Zacznij od przejścia przez coś, co wydaje się być główną pętlą / głównymi metodami programu. Użyj funkcji wchodzenia i wychodzenia, aby zobaczyć, co robią różne metody. Nauczy Cię to ogólnej struktury kodu.
Następnie dziel i podbijaj, przechodząc i ucząc się różnych części programu na głębszym poziomie. W większości debuggerów możesz badać zmienne i ich bieżące wartości . Sprawdź, jak się zmieniają i kiedy.
Określ punkty przerwania w metodach, które wyzwalają zachowania, które Cię dotyczą. Na przykład, jeśli próbujesz zmienić tekst w programie, a tekst powraca do pierwotnej wartości, ustaw punkty przerwania we wszystkich miejscach, w których tekst jest zmieniany, lub spróbuj przenieść wszystkie te zmiany do jednej metody. Użyj stosu wywołań, aby zobaczyć, skąd ta metoda jest wywoływana itp. Itp.
Jeśli zmiana wiersza kodu powoduje nieoczekiwane zmiany w innych miejscach, umieść punkt przerwania w tym wierszu i zobacz, co się tam dzieje, na przykład sprawdzając wartości bieżących zmiennych w zakresie, używając step into lub stosu wywołań, aby zobaczyć, skąd połączenie nadeszło.
Robiąc to, zaczniesz zaskakująco szybko poznawać strukturę kodu. Zacząłem tak jak ty podczas moich pierwszych zadań programistycznych, z dużą ilością kodu, który został napisany wiele lat temu i był zmieniany przez wiele osób przez wiele lat. Kod nie był mój tylko dlatego, że w tym samym czasie pracowali nad nim inni ludzie. W tym momencie nie mogłem przepisać wszystkiego. Pisanie testów dla całego tego kodu zajęłoby mi miesiące lub lata. Debuger naprawdę mnie uratował, nie wiem, jak bym się nauczył kodu bez niego ...
źródło
Pierwszą rzeczą, o której należy pamiętać, jest to, że więcej czasu spędza się na czytaniu kodu niż na pisaniu kodu. Poświęć czas na zrozumienie, jak pracował ten facet - jego styl i podejście do problemów.
Postaraj się jak najlepiej zastosować istniejący styl - w przeciwnym razie facet po tobie będzie musiał zrobić dwa razy więcej regulacji.
Radzenie sobie z kodem innej osoby jest normą, a nie wyjątkiem, musisz wprawić się w rozwiązywaniu problemu, w jaki inny facet rozwiązałby problem lub wdrożył funkcję. Gdy to zrobisz, łatwiej ci będzie poradzić sobie z jego kodem.
źródło
Nie bądź zbyt szybki, by założyć, że kod drugiego faceta śmierdzi.
Ale zawsze bądź podejrzliwy.
Ale tak, potrzeba czasu, aby zrozumieć kod innego dewelopera. Im bardziej funkcja lub obiekt jest używany przez wiele części systemu, tym bardziej musisz być ostrożny. Jeśli możesz rozwiązać problem bliżej objawu, może to czasem być pomocne. Na przykład normalizuj przychodzące dane z innego obiektu po stronie przeszkodowego obiektu po dostarczeniu danych, ale zanim cokolwiek innego się wydarzy.
To zły znak, gdy zmiana jednej rzeczy nieoczekiwanie psuje drugą. Jeśli masz innych bardziej doświadczonych programistów, na których możesz polegać w kwestii pomocy, zalecam, aby spojrzeli na rzeczy, które powodują problemy. Przynajmniej możesz wybrać kilka rzeczy, które obserwują ich debugowanie.
źródło
W idealnym świecie cały kod napisany przez danego programistę będzie dobrze udokumentowany, dobrze ustrukturyzowany i zrozumiale przetestowany, zarówno za pomocą automatycznych narzędzi, takich jak testy jednostkowe, jak i skryptów przypadków użycia, przez które przechodzi użytkownik, aby sprawdzić, czy uzyskasz oczekiwany wynik.
Pierwszą rzeczą, której się nauczysz, jest to, że nie żyjemy w idealnym świecie!
Wielu programistów nie dokumentuje poprawnie swojego kodu, jeśli w ogóle mieszają logikę biznesową z niepowiązanym kodem, a jedynym testem, jaki przeprowadzają, jest szybkie sprawdzenie, co będzie normalnym przypadkiem użycia.
Pracując z takim kodem, pierwszą rzeczą, którą musisz zrobić, to ustalić, co ma robić. Jeśli są komentarze, mogą dać ci wskazówki, ale nie licz na to. Z mojego doświadczenia wynika, że wielu programistów nie jest dobrych w wyjaśnianiu siebie, a nawet jeśli zostawiają komentarze, mogą być bez znaczenia. Jeśli jednak nie jesteś jedynym programistą w firmie, ktoś z pewnością musi mieć przynajmniej podstawowe pojęcie o tym, do czego służy kod i co ma robić. Zapytaj wokół!
Jeśli masz testy jednostkowe, to znacznie ułatwią ci życie. Jeśli tego nie zrobisz, część nauki bazy kodu może obejmować pisanie testów jednostkowych dla kodu, który już istnieje. Zwykle nie jest to uważane za dobrą praktykę, ponieważ jeśli napiszesz testy jednostkowe w celu dopasowania do istniejącego kodu, zakończysz się testami jednostkowymi, które uznają, że kod działa tak, jak jest (zostaną napisane, aby założyć, że zachowanie, które jest błędem, jest poprawne), ale przynajmniej daje podstawę. Jeśli później odkryjesz, że pewne zachowanie, które uważałeś za prawidłowe, jest w rzeczywistości złe, możesz zmienić test jednostkowy, aby sprawdzić, czy jest to oczekiwany wynik, a nie wynik, jaki daje teraz kod. Po przeprowadzeniu testu jednostkowego możesz wprowadzić zmiany i ocenić, jakie skutki uboczne mają wprowadzone zmiany.
Wreszcie, najlepszym zasobem, który masz do czynienia z nieudokumentowanym fragmentem kodu, jest zapytanie użytkowników końcowych. Mogą nie wiedzieć nic o kodzie, ale wiedzą, co ma zrobić aplikacja. Zbieranie wymagań jest pierwszym etapem każdego projektu, a rozmowa z potencjalnymi użytkownikami opracowywanego systemu jest zawsze jego ważną częścią. Pomyśl o tym jako o etapie przechwytywania wymagań dla nowego projektu, który akurat został już zbudowany.
Pamiętaj, że nawet dobrze napisany i dobrze udokumentowany kod może być trudny do zrozumienia dla osoby z zewnątrz. Kod jest zasadniczo wyrazem tego, jak osoba, która go napisała, myślała w tym czasie i każdy ma swój własny, unikalny proces myślowy. Musisz nauczyć się być trochę cierpliwym i być detektywem. Możliwość wejścia w proces myślenia innej osoby jest trudna, ale jest to niezbędna umiejętność dla programisty zajmującego się konserwacją istniejącego kodu. Ponieważ większość kodowania (około 70%) wiąże się z utrzymywaniem istniejącego kodu, ważna jest umiejętność uczenia się.
Aha, a teraz, gdy widziałeś ból, który może powodować źle udokumentowany, nieprzetestowany i pomieszany kod, nie zrobisz tego następnemu biednemu deweloperowi, prawda? :) Ucz się na błędach swojego poprzednika, dobrze komentuj swój kod, upewnij się, że każdy moduł ma jasno określoną odpowiedzialność, do której się wywiązuje, i upewnij się, że masz kompleksowy zestaw testów jednostkowych, które najpierw piszesz (dla metodologii TDD) lub przynajmniej obok opracowywanego kodu.
źródło
Pamiętaj, że umiejętność czytania kodu, którego nie napisałeś, jest bardzo cenną umiejętnością, prawdopodobnie bardziej cenną niż pisanie kodu. Niestety jest to powszechnie zaniżone i niedoceniane w szkołach.
Próbuję powiedzieć, że to normalne, że nie zawsze rozumiesz kod po przeczytaniu go za pierwszym razem (tak jak to normalne, że nie piszesz idealnego kodu za pierwszym razem). Jeśli zaakceptujesz, że uzyskanie obcego kodu zajmuje trochę czasu, nie będziesz miał nic przeciwko włożeniu dodatkowego wysiłku. Małe podsumowanie:
Testy jednostkowe byłyby idealne, ale nie zawsze realistyczne; zwłaszcza jeśli pracujesz w dużej organizacji z dużą biurokracją.
Naucz się prawidłowo korzystać z systemu kontroli wersji; nigdy nie złamiesz istniejącego (nie tak naprawdę nigdy , ale to dobra siatka bezpieczeństwa).
Nie zakładaj, że jest źle po prostu dlatego, że nie rozumiesz go od razu. Nie zakładaj, że jest dobry tylko dlatego, że działa. Ważne jest, aby zrozumieć styl kodu poprzedniego opiekuna i dostosować dodane linie do jego stylu. Opiekun, który przyjdzie po tobie, podziękuje ci za to.
W niektórych firmach niestety nie można nie docenić trudności w odczytywaniu kodu. Jest to powszechne w dużych korporacjach ze sztywnymi procesami. Często (domyślnie) wolą wypychać kod, który działa szybko, niż poświęcać czas na pisanie czegoś czystego. Od ciebie zależy, czy w tej kwestii stanie Twój zespół.
Wreszcie, nigdy nie zapominaj, że czytanie kodu to umiejętność . Im więcej to robisz, tym lepiej na tym zyskujesz. Innym sposobem na powiedzenie tego jest to, że jedynym sposobem na to, aby być w tym dobrym, jest ćwiczenie go wiele razy. Jak wspomniano powyżej, czytanie kodu jest i będzie znacznie większą częścią pracy niż pisanie.
źródło
Sądząc po twoich problemach z nieumyślnym zepsuciem rzeczy, zakładam, że kod nie jest objęty automatycznymi testami. Krok nr 0 polegałby na natychmiastowym zamówieniu i przeczytaniu Efektywna praca ze starszym kodem autorstwa Michaela Feathersa. Jest po prostu nieoceniony.
Podstawowe kroki, które zasugerowałem:
Celowo pomijam określenie smaku testów (jednostka, integracja, ...) - po prostu otrzymuję pewien rodzaj automatycznego testu.
(i tak, postępuj zgodnie ze stylem kodowania pod względem układu i nazewnictwa)
źródło
Jak wspomniano wcześniej: witamy w prawdziwym świecie. Mogę tylko zgodzić się z wcześniejszymi odpowiedziami. Chciałbym tylko rozszerzyć odpowiedź na moje doświadczenie zawodowe dotyczące szacunkowych czasów.
Dobra sugestia, aby wyjaśnić szefowi, zajmie trochę czasu, aby dowiedzieć się, jak myślą inni deweloperzy. Zazwyczaj zauważysz, że obecne rozwiązanie często zależy od wieku i doświadczenia programisty.
Jeśli masz szczęście, zadanie musi zostać przeanalizowane, a zrozumienie dokumentacji bardzo ci pomoże (ale często tak nie jest).
Z mojego doświadczenia wynika, że podczas modyfikowania kodu innego, staraj się nie zmieniać kodu, który nie wiąże się z twoim bieżącym zadaniem. Możesz znać lepsze rozwiązanie lub napisać je w bardziej intuicyjny sposób, ale jego zmiana często prowadzi do problemów takich jak:
Ale nie wahaj się powiedzieć szefowi, jeśli zobaczysz coś, co Twoim zdaniem powinno być inne (to po prostu pokazuje, że możesz myśleć).
Na koniec upewnij się, że masz wystarczająco dużo czasu na rozwiązanie. Szybsze rozwiązanie pochodzi z doświadczeniem. Jednak rzadko istnieje szybkie rozwiązanie, ponieważ jest to pierwszy / główny powód błędów i niemożliwego do utrzymania kodu.
źródło
Pomyśl o tym jak o wykonaniu operacji na osobie.
Zaglądasz do środka, aby rozwiązać problem, i zauważysz, że większość tętnic itp. Nie jest skonfigurowana tak, jak byś to robił - więc przecinaj je i siekaj, dopóki nie będą wyglądać dobrze, a następnie napraw problem.
O dziwo, twój pacjent umiera prawie natychmiast.
Starsze aplikacje są takie same. Mają już sposób działania - musisz zrozumieć różne komponenty oprogramowania i ich wzajemne relacje, a następnie wprowadzić zmiany, aby działało w ten sam sposób. Nie jest to ekscytujące, gdy pozwalasz swojej kreatywności szaleć, ale możesz to zrobić w projektach osobistych.
Poprosiłbym starszego inżyniera, aby usiadł z tobą przez około godzinę w każdy poniedziałek i wyjaśnił inny aspekt systemu. Rób notatki z jego wypowiedzi i wysyłaj je e-mailem do niego i do swojego przełożonego, aby sprawdzić, czy przełożony ma coś do dodania. W ten sposób powinieneś szybko przyspieszyć.
Jeśli chodzi o to, jak nie rozbijać rzeczy, przede wszystkim upewnij się, że rozumiesz, co robi system. Testuj wcześniej - wprowadź zmiany - testuj później. Nie ma magicznych formuł; w miarę zdobywania doświadczenia będzie ci się lepiej - lub chyba zwolniony!
źródło
Jednej rzeczy, której tak naprawdę tu nie widziałem - nie pracuj na wyspie.
O ile nie jesteś jedynym programistą w swoim stroju, na pewno będzie ktoś , kto ma większe doświadczenie niż ty, i prawdopodobnie wiele osób, na których możesz polegać.
Zadawać pytania. Wiele z nich.
Nie martw się o „denerwowanie” kogoś innego (w granicach rozsądku) - wolałbym, żeby ktoś mi przerwał na pytanie lub dwa podczas normalnego cyklu rozwoju, niż później musiałbym zgasić pożar w środowisku produkcyjnym.
Kiedy będziesz gotowy, aby coś sprawdzić, sprawdź to ze swoim mentorem (-ami). Powinny one być w stanie powiedzieć ci nie tylko, czy coś złamie coś innego, ale co ważniejsze, dlaczego. Przejrzenie kodu sprawi również, że mentor będzie lepszym programistą, dając mu / jej widok na system, na który inaczej by nie patrzyli tak często.
Pamiętaj - uczysz się nie tylko systemu, jak każdy nowy pracownik, ale uczysz się, jak zostać programistą.
Pięć lat później zachęć kolejnego Nowego Faceta, aby wykorzystał cię jako mentora.
źródło
Jeśli chodzi o kod debugowania, pamiętaj: zawsze istnieje powód . Kiedy próbujesz znaleźć i naprawić ten sam głupi błąd przez kilka dni i nie robisz żadnych postępów, kuszące jest, aby zacząć myśleć o jednym lub więcej z następujących elementów:
Po prostu nie jestem wystarczająco inteligentny, aby dowiedzieć się, jak działa ten kod
Facet, który napisał ten kod, nie miał pojęcia, co robi
W grę wchodzi magia: bardzo czarna magia
To są wszystkie formy poddawania się. Antidotum jest zawsze pamiętać, że komputery są deterministyczne: zawsze istnieje powód tego, co robią. Kod może pachnieć jak przypływ w sklepie z rybami i przypominać gigantyczną miskę linguine, ale będąc nieugiętym racjonalnym i zachowując otwarty umysł, zrozumiesz .
źródło
Niezależnie od tego, czy piszesz testy jednostkowe, jeśli to możliwe, czy piszesz małe aplikacje zawierające modyfikowany kod, będziesz musiał przyjrzeć się, zrozumieć, a następnie udokumentować logikę.
Jeśli kod działa głównie - brzmi tak, jak to działa - zachowałbym styl formatowania kodu dla tego modułu, niezależnie od tego, czy jest to twój styl, czy nie. Utrzymuje wszystko jednolite. Jednak dobre komentarze nigdy nie wychodzą z mody.
Radzę systemowi testowemu i platformie testowej, w których możesz modyfikować i testować ten kod, bez przerywania produkcji.
Jeśli możesz usunąć elementy kodu do biblioteki, zrobiłbym to, chyba że pracujesz nad biblioteką.
Z czasem, gdy zrozumiesz logikę, możesz przepisać i przetestować.
Ta rada jest uzależniona od używanego języka, możliwości uzyskania łóżka testowego i innych ograniczeń.
źródło
Spróbuj użyć narzędzi do analizowania kodu, aby znaleźć nieużywany kod, który można usunąć - więc przynajmniej nie musisz się martwić o ten kod.
źródło
Jak wspomniano powyżej, musisz zrozumieć cel systemu, a nie tylko szczegóły kodu. Programiści z wystarczającym doświadczeniem, aby napisać system wprowadzania zamówień, ogólnie czują się komfortowo z częścią „do przodu”, która obejmuje wybór produktów, formatowanie faktury i przetwarzanie płatności. Utkną w miejscu, gdy użytkownik zdecyduje „nieważne” i zacznie wycofywać transakcje lub gdy popełni błąd w przetwarzaniu płatności i naciśnie przycisk „Wstecz”. W tym momencie wielu programistów zostaje zdezorientowanych, ponieważ widzą kod „pojawiający się znikąd” i nie mogą zrozumieć, dlaczego on tam jest.
Krótko mówiąc, musisz zrozumieć nie tylko „normalny przepływ”, ale wszystkie cofanie się, które jest konieczne, jeśli ktoś popełni błąd lub zmieni zdanie. Sytuacja staje się jeszcze gorsza w przypadku zastąpień przez administratora, w których część kodu można uruchomić tylko z określonymi uprawnieniami do konta.
Jeśli ktoś napisze 10 000 wierszy kodu rocznie, a aplikacja ma „dziesięcioletnie życie”, programista odpowiedzialny za zbieranie cudzej pracy może być zmuszony zrozumieć 100 000 wierszy kodu. Podziel to przez 50 wierszy na stronę to 2000 stron. Jeśli program zostanie zapisany według wzorca projektowego, programista stwierdzi, że zrozumienie jednego „bloku” prowadzi do co najmniej ogólnego zrozumienia większości pozostałych. Jeśli nie, to należy przeczytać każdą ostatnią przeklętą linię.
Niektórzy programiści „po prostu robią to, co im kazano” i piszą spaghetti. Nigdy nie rozumieją „dużego obrazu” - po prostu wprowadzają poprawki, gdy użytkownicy narzekają. W takich okolicznościach dobrym pomysłem jest rozpoczęcie migracji wszystkiego, co się da, do odpowiedniego wzorca. W końcu może to oznaczać przekodowanie rzeczy, które nie są „zepsute”. Nie przejmuj się tym, po prostu upewnij się, że tak długo, jak jest to twój projekt, jest on stopniowo łatwiejszy w utrzymaniu.
źródło
Oto kilka naprawdę fajnych odpowiedzi. Myślę jednak, że warto również wspomnieć, jak bardzo pomocna może być znajomość dobrych wzorców projektowych , odczytywanie (dobrze napisanego) istniejącego kodu i pisanie czytelnego kodu.
Oczywiście może to być bardzo mylące, gdy napotkasz
SomethingFactoryistniejący kod, który w rzeczywistości nie jest zgodny z wzorcem fabrycznym . Ale na ile pozwala na to Twój zespół i struktura, może być korzystne ograniczenie takich przypadków do minimum.Postępowanie zgodnie z wzorami projektowymi (tam, gdzie pozwalają na to potrzeby biznesowe) może również znacznie ograniczyć powielanie kodu, co z kolei zmniejsza błędy w przyszłych modyfikacjach.
Są dobre źródła wzorców projektowych
http://sourcemaking.com/design_patterns
http://www.oodesign.com/
i oczywiście książka
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
źródło
Śledzenie przepływu kontroli między metodami jest bardzo ważne przy opracowywaniu mentalnej mapy logiki biznesowej.
Generowanie modelu danych przepływu pracy jest najlepszym sposobem analizy wszystkich ścieżek kodu:
A wizualizacja przepływu pracy jest idealna:
Bibliografia
źródło
Upewnij się, że korzystasz z programu, który pomaga znaleźć rzeczy w bieżącym pliku. Nie ma nic gorszego niż znajomość tego, czego szukasz, w bieżącym pliku, ale przewijasz i przewijasz i nie możesz go znaleźć. Widok konspektu w narzędziu używanym do edycji kodu naprawdę pomaga w rozwiązaniu tego problemu.
źródło