Jak czytać tysiące wierszy kodu bez dokumentacji? [Zamknięte]

Wcześniej szukałem dobrej kontroli TimeLine dla projektu WPF. Znalazłem odpowiedź tutaj, która kieruje mnie do tego projektu CodePlex .

Teraz chcę zmienić kod, aby zaspokoić moje potrzeby kulturowe. Ale są pewne niedopasowania!

Moje pytanie brzmi:

Jak wchodzisz w interakcje z takimi tysiącami wierszy kodu?

EDYTOWAĆ:

Każdy skrót będzie świetny!

Dodajesz komentarze do kodu źródłowego, jeśli zrozumiałeś go wystarczająco, aby to zrobić. Przeanalizuj te komentarze energicznie, ponieważ rozumiesz coraz więcej.

1. Przejdź przez kod
2. Zmień nazwę w razie potrzeby
3. Refaktoryzuj w razie potrzeby
4. Powtarzaj, aż całkowicie zrozumiesz

... a kod Ci za to podziękuje. ;-)

Wykonaj pojedyncze działanie, debuguj (ponownie i ponownie) kod, aby dowiedzieć się, jak to działanie zostało wykonane. Zapisz to samo prostym językiem, aby uzyskać lepsze zrozumienie!

Coś, co Joel Spolsky napisał dawno temu na swoim blogu (nie może teraz znaleźć artykułu) naprawdę utkwiło we mnie w związku z tym:

Powiedział, że kod nie jest naturalnym ludzkim językiem, ale jako programiści łatwo uśpiliśmy myślenie, że tak jest i że powinniśmy być w stanie go odczytać jako taki. W związku z tym wielu z nas patrzy na nowy kod i oczekuje, że będziemy mogli go po prostu „przeczytać” i zrozumieć od razu, tak jakby był to blok tekstu w języku angielskim.

Myślę więc, że kluczem jest po prostu powolność, metodyczność i wiedza naukowa. I jak powiedzieli inni - komentuj to (a nawet refaktoryzuj) w trakcie podróży. Nie wpadaj w sposób myślenia „powinienem po prostu na to spojrzeć i natychmiast zrozumieć”.

Och, i tak, czasami wciąż wpadam w tę pułapkę. „Rób, co mówię, a nie jak ja” i tak dalej. :)

SE-Radio przeprowadziło wywiad z Dave'em Thomasem na ten temat

Ten odcinek podcastu zawiera wiele wskazówek i technik pozwalających wejść w „kulturę” projektu i zrozumieć, jak żyli pierwotni mieszkańcy.

Musiałem to ostatnio zrobić z projektem o wartości ponad 100 000 LOC. Mój pierwszy pomysł polegał na tym, że łatwiej jest zobaczyć wzorce na wykresach 100 lub nawet 1000 węzłów niż na 100 000 linii tekstu.

Spędziłem więc 45 minut i napisałem krótki (<100LOC) program w języku Python, aby przeanalizować to, czego potrzebowałem, i narysować relacje między obiektami. Wygenerowałem źródło Graphviz , które jest naprawdę łatwym językiem do wygenerowania. (W Pythonie nie ma nic specjalnego: Ruby, C #, Common Lisp lub cokolwiek innego, co mogłoby to zrobić równie dobrze.)

W innych projektach widziałem, jak ludzie używają Graphviz do zależności modułów, wykresów wywołań, historii wersji i wszelkiego rodzaju rzeczy. Największe meta-narzędzie do wizualizacji programu.

(Może dlatego, że wziąłem kompilatory , ale wydaje mi się dziwne, że gdy programista napotyka problem, odpowiedź zawsze brzmi „napisz program!”, Z wyjątkiem sytuacji, gdy problem dotyczy kodu źródłowego programu. - )

Uruchom go w uruchomionym debuggerze, jest to prawie jedyny sposób na zrozumienie nowej, dużej bazy kodu.

Zrozum, że tak naprawdę nie ma żadnych skrótów do pełnych smaku (A jeśli masz problem z tym zwrotem, twoja edukacja została SORELNIE zaniedbana. Pochodzi z „Stranger In a Strange Land” Roberta A. Heinleina.)

Przeczytaj ją, jedna strona na raz, jedna rutyna na raz. Dodaj Komentarze. Narysuj zdjęcia głównych struktur danych. Rozpoznawanie algorytmów. Czerp z wcześniejszej wiedzy.

Oprzyj się pokusie uruchomienia debuggera. Rzutnia debugera jest zbyt mała: widzisz jedną linię na raz, ale tak naprawdę nie widzisz, gdzie byłeś ani dokąd zmierzasz.

Cokolwiek robisz, pisz tyle, ile się da, więc nikt nigdy nie znajdzie się w takiej samej pozycji, jak ty.

musisz użyć wskazówek. uzyskaj wskazówkę dotyczącą tego, czego szukasz i intensywnie korzystaj z funkcji wyszukiwania w swoim środowisku lub środowisku IDE, które mogą doprowadzić cię do żądanej sekcji kodu, w której musisz wprowadzić zmiany.

czytanie 14 tysięcy linii kodu Java nie ma żadnego sensu. Funkcja wyszukiwania to Twoja oszczędność życia

Różni ludzie mają różne style uczenia się, więc YMMV. Pierwszą rzeczą, którą robię w tej sytuacji, jest przeczytanie całej bazy kodu przynajmniej raz. To daje mi ogólny pogląd na to, gdzie wszystko jest. Następnie wybieram sekcję do zbadania bardziej szczegółowo. Struktury danych byłyby dobrym miejscem do rozpoczęcia. Kiedy już mam ogólne pojęcie o tym, co się dzieje, robię to samo z inną częścią kodu, która wchodzi w interakcję z pierwszą. Po wystarczającej liczbie iteracji dobrze rozumiem, jak działa kod.

Najlepszym sposobem, podobnie jak w przypadku wszystkich programów, nie tylko dużych kawałków niezakomentowanego kodu, jest rozbicie go na części. Jest to coś, co powinieneś zrobić zarówno w głowie, jak i wizualnie w kodzie. Może to oznaczać dodawanie dużych pogrubionych komentarzy lub wielokrotne łamanie wierszy. Pomaga to podczas przewijania, aby zobaczyć elementy. Spróbuj znaleźć logiczne fragmenty kodu.

Oczywiście, gdy rozumiesz bity, komentuj je według tego, co wiesz w tym czasie, prawdopodobnie umieszczając notatki o czymś, czego nie rozumiesz.

Poleciłbym również nie próbować zrozumieć całego utworu od samego początku. Zamiast tego spróbuj zrozumieć elementy, które musisz znać teraz, a resztę później.

Zacznę od użycia edytora Leo w trybie @shadow z aktywnym użyciem sklonowanych węzłów . Umożliwia to dodawanie notatek i komentarzy do każdej badanej sekcji kodu bez zmiany kodu , a adnotacje zawsze będą kontekstowe, obok kodu, o którym mówi. Oto przykładowy obieg dokumentów:

Na przykład, kiedy naprawiam błąd w Lwie, tworzę zwykły węzeł, który reprezentuje błąd. Ten węzeł błędu jest moim widokiem wszystkich danych w kodzie źródłowym Leo, które odnoszą się do błędu. Gdy odkrywam kod związany z błędem, klonuję ich węzły i przenoszę je pod węzeł błędu. Dodam również zwykłe węzły jako dzieci węzła błędu. Te węzły zawierają oryginalny raport o błędzie, opisy, w jaki sposób naprawiłem błąd, dane testowe lub inne uwagi, które chciałbym zachować.

Po utworzeniu węzła błędów koncentruję się tylko na tym węźle i jego dzieciach. Mogę zbadać węzeł błędu i jego dzieci bez konieczności przeskakiwania dookoła. Wszystko czego potrzebuję jest w jednym miejscu. Kiedy zaczynam naprawiać błąd, mogę to zrobić, zmieniając klony. Znowu nie muszę skakać po konturze. Nie ma znaczenia, jak duży lub złożony jest cały zarys: mam do czynienia tylko z węzłem błędu i jego dziećmi. To niezwykle wąskie podejście znacznie ułatwia naprawianie błędów.

Narysuj diagramy źródła: relacje danych, relacje funkcjonalne, relacje obiektowe. Określ agregację, przepływ danych i przepływ kodu. Zdjęcia są znacznie lepsze niż komentarze i mogą być przechowywane oddzielnie od kodu.

Zanim cokolwiek zmienisz, napisz testy. Wiele testów. Bardzo specyficzne testy dla małych bloków kodu, które są co najmniej wywoływalne, ponieważ będzie to zależeć od sposobu pisania odziedziczonego bałaganu.

Zaletą pisania testów na początek jest to, że musisz mieć jakieś zrozumienie kodu, zanim będziesz mógł go przetestować, więc mam nadzieję, że każdy napisany test będzie odrobiną zdobytej wiedzy. Możesz również mocno skomentować testy wraz ze swoimi założeniami wraz z twierdzeniami.

Wykonując najpierw test, nie ryzykujesz zmiany w kodzie, który wywołuje efekt domina, o którym nie wiesz. Będziesz także mieć siatkę bezpieczeństwa, kiedy przyjdziesz do zmiany kodu.

Używam narzędzi takich jak doxygen, aby wygenerować ogólny schemat klas, niż rozumiem, co robią poszczególne klasy.

Następnie wybieram łatwy błąd z kolejki błędów (zanim mój menedżer przypisuje mi trudny: P), następnie uruchamiam tę funkcję do debuggera i próbuję wygenerować przybliżony przepływ danych lub model przepływu kodu.

Na przykład funkcjonalność eksportu w niektórych programach: więc staram się zrozumieć, w jaki sposób odczytuje się dane źródłowe, skąd w kodzie (interfejs podstawowy) mogę ocenić, czy dane zostały odczytane poprawnie, korzystając z moich diagramów przepływu klas i kodu, za które klasy są odpowiedzialne jaki rodzaj eksportu itp. Myślę, że połowa zrozumienia została zakończona, gdy masz już diagramy klas i schematy blokowe.

Podejdź do trywialnej wady, np. NullPointerException. Na początku unikaj czegokolwiek dotyczącego współbieżności, wszystko, co z natury wymaga jednoczesnego zrozumienia dużej części kodu.

Po usunięciu kilku błędów prawdopodobnie będziesz mieć całkiem niezły pomysł. W każdym razie działa dla mnie.

Zasadniczo czynność napisania czystego kodu powinna rozpocząć się od samego projektu. Jeśli kodujemy w języku OOP, wymyślmy UML, podzielmy się z rówieśnikami i przekonajmy się, że projekt nie jest niejednoznaczny. W każdym razie nasi programiści powinni przekonać się, że projekt rozwiązuje problem, a nie dwuznaczności.

Jeśli chodzi o kodowanie, musimy upewnić się, że projekt jest konwertowany na kod, tj. Encję do klasy lub struktury, operację do działania itp.

I przeszedłem przez białą księgę http://queue.acm.org/detail.cfm?id=2063168, która mówi o stylu kodowania lub o tym, jak możemy używać spacji, wcięć i zmian czcionek, ponieważ większość IDE może pisać DUŻO Kod CLEANER, w którym my, ludzie, możemy zrozumieć tyle samo, co maszyny. Kładzie większy nacisk na pisanie kodu bez komentarzy, aby nasz kod pojawiał się jako akapity.