Prawie każdy zaawansowany programista mówi, że bardzo przydatne jest czytanie kodu innych specjalistów. Zwykle doradzają open source.
Czytasz to czy nie? Jeśli tak, to jak często i jaka jest procedura czytania kodu? Ponadto początkującym trudno jest poradzić sobie z SVN - wiązką plików. Jakie jest rozwiązanie
Odpowiedzi:
Czytasz to czy nie?
Tak.
Jeśli tak, to jak często
Codziennie. Stale. Pracuję z wieloma projektami typu open source (głównie związanymi z Pythonem) i muszę przeczytać źródło, ponieważ jest to najdokładniejsza dokumentacja.
a jaka jest procedura czytania kodu?
Um. Otwórz i przeczytaj.
Ponadto początkującym trudno jest poradzić sobie z SVN - wiązką plików. Jakie jest rozwiązanie
Otwórz i przeczytaj. Czytaj dalej.
To nie jest łatwe. Nic nie ułatwia. Nie ma Royal Road do zrozumienia. To wymaga pracy.
W twojej zagadce jest kilka warstw. Najpierw zacznij od wysokiego poziomu, że tak powiem, widok z lotu ptaka. Po sprawdzeniu projektu w strukturze katalogów będzie kilka plików. Tak samo jest, niezależnie od tego, czy patrzysz na źródło otwarte czy zamknięte (kod źródłowy to w końcu kod źródłowy). Zacznij od tego:
Wymaga praktyki, ale jest to z pewnością wykonalne. Im więcej wiesz o bibliotekach i ramach, z których korzysta aplikacja, tym więcej wiesz, jak należy zorganizować kod i gdzie szukać odpowiedzi na określone pytania. Niektóre kody są nieco trudniejsze do naśladowania, szczególnie jeśli są dość pośrednie. Dlatego potrzebujesz ołówka i papieru. W końcu żarówka gaśnie w twojej głowie i dostajesz ją. To wtedy czytanie reszty kodu ma o wiele większy sens.
To nie jest tak, jak czytasz powieść, ale bardziej to, jak czytasz książkę informacyjną. Dobrym sposobem jest wybranie ostatnio naprawionego błędu z wiadomości sprawdzającej, zrobienie różnic co się zmieniło i przeczytanie odpowiednich części, dopóki nie zrozumiesz zarówno problemu, jak i rozwiązania. Dobrze rozpowszechnione luki w zabezpieczeniach to fajne błędy do wyboru, ponieważ na forach jest wiele dyskusji na ich temat. Następnie wybierz jeden z błędów „wiszących owoców” w narzędziu do śledzenia błędów i czytaj, dopóki nie zrozumiesz, jak to naprawić. Większość profesjonalistów czytających kod robi to przypadkowo w trakcie naprawy błędów lub dodawania funkcji.
Zwykle najlepsze próbki kodu są ledwo zauważalne. Natychmiast je zrozumiesz, nie czytając ich więcej niż raz. Sprawiają, że wygląda na to, że napisanie go było niezwykle łatwe, mimo że ten dobry kod zwykle przechodzi wiele szkiców. Powoduje to paradoksalne wrażenie, że oczywiście dany kod jest oczywistym sposobem na zrobienie tego, nawet jeśli nie jest to pierwszy sposób, o jakim myślałeś.
Kiedy natrafisz na taki kod, spróbuj zrozumieć wgląd w jego pisanie i związane z nim zasady projektowania, więc kiedy znajdziesz się w podobnej sytuacji w przyszłości, możesz mieć nadzieję, że zastosujesz te same zasady.
Jedną sztuczką, której używam dość często podczas czytania skomplikowanych funkcji, segment kodu jest rozpoczęcie refaktoryzacji go do czegoś bardziej czytelnego bez zmiany logiki.
Jak ciężko jest poradzić sobie z „wiązką plików”? Nie różni się niczym od pisania własnego kodu, z tym wyjątkiem, że nie posiadasz wcześniejszej wiedzy na temat jego organizacji, chyba że jest to udokumentowane.
Jeśli, jako rzekomy programista, nie jesteś w stanie zrozumieć struktury projektu na podstawie „zbioru plików”, to albo jest to wyjątkowo źle zorganizowany projekt, albo jesteś nieudolnym programistą (lub, w skrajnych przypadkach, jednym i drugim).
Zacznij czytać, spróbuj znaleźć punkty wejścia lub w inny sposób niezbędne klasy / metody przestawne i zbuduj zrozumienie, jak to wszystko się stamtąd łączy. Nie będzie natychmiastowy, zajmie trochę czasu, ale można to zrobić, nawet jeśli w ogóle nie ma dokumentacji.
Najlepszą rzeczą, na jaką możesz liczyć podczas czytania kodu innego projektu, niezależnie od tego, czy jest to interfejs API, czy oprogramowanie, jest to, że zmienne, funkcje i nazwy makr nie są skracane niejednoznacznie ani nazwane, abyś mógł zrozumieć ich zamiary.
Ale poza tym, potrzeba przyzwoitej wiedzy na temat języka, technik programowania, a także samego celu kodu, aby móc zanurzyć się w złożonym kodzie.
Obecnie próbuję zobaczyć, jak Lua robi część swojej magii, ale przechodzę do punktu powyżej, w którym wiele identyfikatorów jest nazwanych niejasno i raczej w skrócie do punktu, w którym nie mogę dowiedzieć się, która linia próbuje aby zrobić coś, co wiem, musi być zrobione w pewnym momencie w kodzie funkcji ... Często przychodzą mi do głowy zmienne jednoliterowe i raczej skrócone nazwy makr / funkcji.
Po spojrzeniu na „Po pierwsze, zacznij od wysokiego poziomu, widok z lotu ptaka”, jak sugerował @Berin Loritsch, możesz poszukać unittestów i / lub testów integracyjnych, jeśli takie istnieją.
unittests są interesujące, aby zobaczyć, jak działają (api) szczegóły.
test integracji zazwyczaj daje dobry przegląd procesów biznesowych.