Jakie są dobre techniki utrzymywania twojego miejsca w kodzie?

Rozumiem, że zakładki służą do zapamiętywania jednego punktu w kodzie. Jak jednak śledzić przepływ badanego kodu? Np .: wiele zakładek i kolejność, w jakiej zostały utworzone.

Przykład:

1. Raport o błędzie: „Zderzenia nie działają na rogach ścian”

   1. Reprodukcja błędu powoduje, że niektóre wielokąty nie kolidują.
   2. Kod kolizji został napisany przez niedostępnego programistę. Więc dochodzenie przebiega mniej więcej tak:

Podczas dochodzenia, szczególnie podczas przeglądania elementów innych niż kodowe, takich jak Google, można zasadnie oczekiwać, że utracą one swoje miejsce w kodzie ( czy już sprawdziłem tę ścieżkę kodu? Lub Którą ścieżkę kodu badałem? do tej funkcji itp.). To samo dotyczy nieuniknionych przerw (Szef: Potrzebuję [Długiego Bezcelowego Raportu] TERAZ itp.)

Przydatne byłoby posiadanie zasobu technik lub narzędzi umożliwiających śledzenie własnego miejsca w kodzie.

Edycja : Powyższy przykład ma służyć jako potencjalna ilustracja, a nie rzeczywisty problem wymagający odpowiedzi.

Innym sposobem sformułowania tego pytania jest:

Kiedy uczysz się nowego systemu, jak śledzisz swoje umiejętności uczenia się kodu? Nie chodzi o zrozumienie, dlaczego kod robi to, co robi (do czego powinny służyć komentarze), ale jak to robi (czego można się nauczyć tylko poprzez czytanie kodu, a nie komentarze).

Interfejs bąbelków próbuje rozwiązać ten problem, wyświetlając jednocześnie kilka bitów kodu. (Utknąłeś w przeglądarce w Google). Wygląda niesamowicie, ale jeszcze tego nie próbowałem. Ta wersja pomysłu jest implementacją Visual Studio dla Visual Studio Ultimate.

Poza wszystkimi wymienionymi wspaniałymi technologiami odkryłem, że staromodny kawałek papieru A3 stanowi doskonałą pomoc w tych kwestiach. Zapisz swoje pomysły i uporządkuj je w stylu mapy myśli.

Zarówno mój edytor, jak i debugger mogą przejść do definicji funkcji i mieć wielopoziomowy przycisk „wstecz”, podobnie jak przeglądarka internetowa, aby powrócić tam, gdzie byłem wcześniej. Zazwyczaj wystarcza mi to do śledzenia złożonego przepływu debugowania. Pomaga także mieć kontrolę źródła, która pozwala dużo popełnić . To daje mi komunikat zatwierdzenia wyjaśniający, dlaczego próbuję czegoś, a także szybki sposób wycofania się ze zmiany, jeśli to nie działa. Poza tym prosta tablica z listą potencjalnych i zbadanych potencjalnych klientów wypełnia wszelkie pozostałe luki dla mnie.

Wiele sposobów śledzenia:

• Zapisz to . Masz spotkanie za dwie minuty? Napisz, co robiłeś i gdzie. Zawsze mam przy sobie długopis i papier, żeby zapisywać rzeczy podczas pisania.
• Zakładki . Mam 10 ponumerowanych zakładek, które mogę ustawić.
• Stacktrace . Możesz łatwo przeglądać całą hierarchię kodu, przez który przechodziłeś. Mój edytor pozwala mi również skopiować ślad stosu i go zapisać. Następnym razem, gdy otworzę mój edytor, mogę załadować stacktrace do szybkiej nawigacji.
• Nawigacja w edytorze . Idź do członka bazy, przejdź do spadkobiercy, znajdź zwyczaje, przejdź do odniesienia ...

Korzystam z prostego rozwiązania - nigdy nie zamykaj niczego, dopóki nie skończę zadania. Oznacza to, że zwykle jedno z około 50 otwartych okien / kart zawiera coś, co przypomni mi, o czym myślałem, kiedy wrócę do tego.

Zdobądź prawdziwe narzędzie deweloperskie / IDE, co zawsze będzie Ci się podobało. Vi, Emacs, Eclipse lub cokolwiek innego (wybór jest tak duży, jak spory co do tego, co jest najlepsze, ale to kolejny problem) i naucz się go właściwie używać . nie, podobnie jak zbyt wielu, używaj go jak Notatnika z podświetlaniem składni. Naucz się korzystać z klawiszy skrótu, a nie polegać na myszy w przypadku typowych działań (jest zbyt wolny). Duży ekran (minimum 1920 x 1200) jest korzystny.

Moje narzędzie deweloperskie nadało nazwy (wolniejsze, ale przydatne nazwy sprawiają, że są trwałe) i nienazwane (szybkie wstawianie i usuwanie) zakładki, przeglądanie do przodu i do tyłu oraz przeglądanie odnośników w jednym, todo i notatkach dla programistów (osobistych i grupowych) dołączonych do konkretna linia kodu źródłowego. Robi każdy język pod słońcem, bez konieczności instalowania kolejnej wtyczki.

Pracuję na bazie kodu składającej się z kilkunastu lub więcej modułów 1 Million plus SLOC, używając pół tuzina języków. Oczywiście nie pracuję nad wszystkimi z nich na raz, raczej skupiam się na małych częściach jednego lub dwóch, ale mogę nawigować za pomocą kilku działań do dowolnego punktu w kodzie, który jest zależny od tego, co robię.

W programie Visual Studio podczas sesji debugowania możesz użyć okna „Stos wywołań” (możesz włączyć je w Debug / Windows / Call Stacklub za pomocą skrótu Ctrl+Alt+c), aby śledzić przepływ kodu.

Dziwi mnie, że nikt nie wspomniał o wielu narzędziach, które mogą tworzyć wykresy połączeń. Uważam, że doxygen jest świetną pomocą. Nie musisz nawet zobowiązać się do używania doxygen w całym swoim programie, możesz po prostu oznaczyć funkcje, które chcesz śledzić.

Używam trybu org do emacsa, który jest narzędziem opisującym uber. Za jego pomocą mogę napisać kontur, który naśladuje stos wywołań kodu i zawierać bezpośrednie linki do samego kodu źródłowego (poprzez org-store-link). Możesz dołączyć tekst objaśniający, linki do stron internetowych itp. (Np. Kiedy wyszukujesz magiczne liczby w Google)

To nie jest idealne. Na przykład struktura konspektu nie ma pojęcia powrotu o poziom, więc trudno jest prześledzić ścieżkę wykonania, a nie tylko stos. Ale to kolejna najlepsza rzecz do diagramów na papierze, które znalazłem.