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

12

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!

Jalal
źródło
3
poprosić o podwyżkę. to zawsze pomaga. (mogą z tego zrobić motywator)
Nazwa wyświetlana
2
uderzaj głową o biurko, aż wszystko stanie się jasne.
jellyfishtree,
19
Jak jesz słonia? ... Jeden kęs na raz.
Bill
1
@Jalal to co oni chcą, aby myśleć.
Mateen Ulhaq
2
@DisplayName, podejście do motywacji marchewki i kija okazało się złym rozwiązaniem dla każdej pracy, która wymaga podstawowych umiejętności poznawczych. Nauka motywacji jest bardziej złożona niż system nagród. Sprawdź „Drive: Zaskakująca prawda o tym, co nas motywuje” Dan Pink, jest to zdumiewająca lektura. Lub sprawdź to wideo na You Tube do skróconej wersji. youtube.com/watch?v=u6XAPnuFjJc
Ryan Taylor

Odpowiedzi:

37

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.

użytkownik1249
źródło
3
+1 i dobrym sposobem jest napisanie dokumentacji podczas przeglądania kodu źródłowego. I po co wysyłać swój wkład z powrotem do koordynatorów operacji?
1
+1 Również jeśli zmodyfikujesz kod, pamiętaj, aby zmienić również swoje komentarze, aby przyszłe pokolenia nie były zdezorientowane co do tego, co zrobiłeś. Szkoda robić tego doktora i niech ludzie go nienawidzą, bo to źle!
Michael K,
1
Jeśli oryginalny projekt znajduje się w rozproszonym systemie kontroli źródła (takim jak git), warto go rozwidlić, zatwierdzić zmiany stopniowo i zrobić to w taki sposób, aby opcjonalnie scalić je później z powrotem do oryginału
8
  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. ;-)

John MacIntyre
źródło
7
Zmiana losowych miejsc w kodzie produkcyjnym tylko dlatego, że jest łatwiejsza, nie jest zbyt dobrym pomysłem. Tylko żądania funkcji powinny powodować modyfikację kodu, ponowne faktoring jest żądaniem funkcji. Bez względu na to, jak dobry jesteś, łamanie kodu, czasem głupie skutki uboczne są tym, na czym polegają klienci. Refaktoryzuj tylko kod, którego jesteś pewien. I pamiętaj, nawet testy jednostkowe niczego nie gwarantują.
Koder
Zgadzam się, ale refaktoryzacja tylko w celu wypróbowania projektu może pomóc ci zrozumieć, dlaczego kod został napisany w taki sposób, w jaki jest (lub potwierdzić, że masz rację, że został wykonany źle / dziwnie). Nie musisz zachowywać tych zmian.
Ricky Clarkson
+1 Koder. I ta odpowiedź obecnie nawet nie wspomina o testach jednostkowych. Straszny.
MarkJ
Przepraszam, nie oznaczało to poważnego refaktoryzacji. Mówił więcej o drobnych procesach refaktoryzacyjnych i porządkach. W końcu dochodzimy do tego, że cel kodu jest oczywisty.
John MacIntyre
5

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!

Sri Kumar
źródło
Zwykle robię to również, dopóki nie napotkam projektu, który nie jest w stanie uruchomić w trybie debugowania! Zawsze ulega awarii podczas uruchamiania! :( Ale działa dobrze w trybie wydania: S
Afriza N. Arief
@afriza CO kurwa. To jest bardzo zły kod, sprawdź, jakie błędy on daje.
Daniel S
@afriza, pierwszą rzeczą do naprawienia!
4

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. :)

Stoły Bobby'ego
źródło
Faktem jest, że tekst w języku angielskim, który można „po prostu przeczytać”, jest zwykle liniowy. Powodem, dla którego kod często jest początkowo trudny do odczytania, jest na ogół to, że jest nieliniowy, a sztuczka po prostu go psuje. Mnóstwo różnych idiomów implementacyjnych, które używają programiści, ogólnie nie pomaga, ale pierwszym etapem jest zwykle uruchomienie kodu przez debugger i użycie punktów przerwania, aby zobaczyć, co jest co. Próba przeczytania go jest dość bezcelowym ćwiczeniem. Poważnie, kiedy ostatnio czytałeś napisany przez siebie kod? (to znaczy od początku do końca).
ocodo,
Właściwie dobrze napisany kod jest łatwy do odczytania, ale nie jako tekst. Wystarczy zeskanować, aby zobaczyć elementy składowe i zrozumieć strukturę rdzenia, bez konieczności czytania wszystkiego. Złe podejście do kodowania, takie jak stary kod skool lub nadużycie SOLID i wzorców może jednak bardzo utrudnić to zadanie.
Koder
4

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.

Michael Easter
źródło
Zabawne jest to, że doświadczenie Dave'a Thomasa polega na tym, że dokumentacja - poza ogólnym przeglądem - jest (prawie) bez wyjątku gorsza niż brak dokumentacji. (Z mojego doświadczenia wynika, że ​​większość dokumentacji to podstawa, która na poziomie powierzchni pozwala zrozumieć „co” lub „jak”, które niezmiennie pozostaje wtedy przestarzałe, aż do wprowadzenia w błąd.)
Michael Kropat
2

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. - )

użytkownik18893
źródło
1

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

Grrussel
źródło
2
To nie jest praktyczna opcja, gdy masz tysiące linii kodu (szczególnie, gdy mówimy o dziesiątkach lub setkach KLOC) i / lub jeśli część tego kodu jest w szablonach. Aby opanować nową (i słabo udokumentowaną) bazę kodu, należy również zaangażować firmę i spróbować zrozumieć kontekst, w którym kod ma działać. Jeśli potrafisz przejść przez kod za pomocą debugera i go zrozumieć, ta baza kodu nie była tak duża na początek (w większości przypadków korzystanie z debugera jest raczej niepotrzebne).
luis.espinal
Biada, jeśli baza kodu jest zbyt duża, aby debugować w debuggerze. Widok kodu reagującego na znane dane wejściowe i wyjściowe pomaga przekształcić wiedzę „co” na „jak”. Na pytanie „dlaczego” nigdy nie można odpowiedzieć za pomocą samego debuggera, ale mogą być wbudowane komentarze źródłowe, które można zobaczyć w IDE podczas debugowania.
grrussel
@grrussel Muszę się nie zgodzić, bo to nie to, co robię ... Nie mam pojęcia, czy jestem reprezentatywny, czy nie! Widzę, że używam nieparzystego punktu przerwania (ale nadal nie jawnie przechodzę) i używam funkcji IDE, aby umożliwić mi powiązanie jednego kawałka z drugim.
Murph,
1

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.

John R. Strohm
źródło
Debuger wyjaśnia niektóre konwencje oryginalnych konwencji twórców kodu o tym, czego oczekuje się od zmiennych (np. Czy oczekują pełnej ścieżki, nazwy pliku lub ścieżki względnej?) I wielu innych rzeczy, więc moim zdaniem jest to nadal ważne
Afriza N. Arief
2
-1 za myślenie, że jesteś fajny, ponieważ używasz słowa „
grok
1

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

Jon Hopkins
źródło
1

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

użytkownik18883
źródło
0

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.

Larry Coleman
źródło
0

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.

Darryl Hein
źródło
0

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.

matowe wilkie
źródło
0

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.

Bruce Alderson
źródło
0

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.

chooban
źródło
0

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.

Priyank Bolia
źródło
0

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.

Ricky Clarkson
źródło
-2

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.

Vasanth
źródło