Jak poprawić swoje umiejętności czytania kodu [zamknięte]

Pytanie brzmi w tytule - jak poprawić swoje umiejętności czytania kodu.

Środowisko programowe / sprzętowe, w którym obecnie pracuję, jest dość powolne w odniesieniu do czasów kompilacji i czasu potrzebnego na przetestowanie całego systemu. System jest dość stary / złożony, dlatego podział go na kilka mniejszych, łatwiejszych do zarządzania podprojektów nie jest możliwy w najbliższej przyszłości.

Zdałem sobie sprawę, że tak naprawdę przeszkodą w rozwoju są umiejętności czytania kodu. Jak poprawić umiejętności czytania kodu, aby wykryć większość błędów i problemów w kodzie, zanim jeszcze naciśniesz klawisz „do kompilacji”, nawet przed uruchomieniem debugera?

Przeczytaj więcej kodu

Ja, na przykład, mam dość przyzwoitą umiejętność czytania kodu z czytania pytań certyfikacyjnych, były bardzo trudne do naśladowania, ponieważ zostały źle napisane celowo

W końcu mają sprawdzić Twoją znajomość języka (w moim przypadku Java).

Im więcej kodu przeczytasz, tym więcej doświadczenia zdobędziesz, to takie proste

Ulepsz swoje środowisko programistyczne w jak największym stopniu, aby uzyskać informacje zwrotne, których możesz użyć.

Nowoczesne IDE mogą pomóc LOT-owi, jeśli możesz dostarczyć im niezbędnych informacji. Przykładami są:

• Kolorowanie składni: stałe w jednym kolorze, komentarze w innym, identyfikatory w trzecim, ciąg w czwartym itp. Niedawno znalazłem fragment kodu, który był ... dziwny ... Okazało się, że zmienna została nazwana jako stała byłaby - niewłaściwy kolor to zdradził.
• Złap proste błędy kompilacji. Większość języków ma prostą składnię, której można nauczyć edytora, dzięki czemu będzie mógł powiedzieć, że będziesz mieć błędy.
• Złap złożone błędy kompilacji. Wiele kompilatorów może generować pliki informacyjne, które można załadować do IDE, aby wiedział, ile argumentów bierze dana funkcja itp.

Istnieją również programy, które mogą identyfikować błędy logiczne w twoich programach, których możesz użyć, aby uzyskać jeszcze więcej informacji o swoim programie, z którego możesz się uczyć.

IDE może także pomóc w nawigacji po źródle, gdy zna się na tych wszystkich rzeczach. Dzięki temu możesz łatwo wyszukiwać, zamiast zapamiętywać wszystko

Sugeruję edycję pytania, aby uzyskać więcej informacji o środowisku, w którym pracujesz i programach, które piszesz, aby uzyskać lepsze sugestie.

Oprócz tego, co powiedzieli wszyscy inni, potrzebujesz cierpliwości, jeśli zamierzasz czytać kod (zwłaszcza jeśli nie jest on twój). Tak, czytanie na pamięć kodu na pamięć wymaga praktyki, ale wszystko jest tego warte, a także uczysz się stylów kodowania / sztuczek innych. Oto, co sprawdzam w kolejności:

1. nazwy zmiennych, pasujące nawiasy klamrowe, import itp.
2. sprawdź, czy warunki są odpowiednio umieszczone i czy wykryto błędy
3. wszystko inne - korzystanie z funkcji itp.

Jestem przyzwyczajony do kodowania w zwykłym edytorze tekstowym, więc Ctrl + F jest moim przyjacielem, ale IDE jest bardzo przydatne, szczególnie gdy czytasz z wielu plików.

Teraz, jeśli to ty będziesz pisać kod, nie bój się wstawiać białych spacji, wcięć i komentarzy. Szczerze mówiąc, jeśli nie wygląda przyjemnie dla oczu, staje się bólem w głowie.

Nawet gdybym mógł wykryć wszystkie błędy, zanim zacznę kompilować, nadal sprawdzałbym, testując i kompilując. Ufałbym tylko pozytywnemu testowi i działającemu programowi.

Myślę, że dobra umiejętność czytania kodu może doprowadzić cię do daleko idących hipotez dotyczących kodu. „Prawdopodobnie pójdzie źle!” I przetestuj to. I w poszukiwaniu błędów „może to być przyczyna, przetestujmy to”

Najlepszym sposobem na to jest samodzielne napisanie kodu. Drugim najlepszym sposobem jest to, że kod jest po prostu naprawdę dobry i wyjaśnia się (jeśli jest naprawdę trudny, kod po prostu nie jest tak dobry)

Jeśli to nie jest twój własny kod i nie jest napisany dobrze, jedynym sposobem na poprawę jest robienie, robienie, robienie. Przeczytaj kod, wypróbuj różne rzeczy, napisz testy przeciwko niemu, poznaj bazę kodu, refaktoryzuj. Narzędzia mogą pomóc, narzędzia, które mogą znaleźć, gdzie stosowane są metody, gdzie interfejsy są implementowane, gdzie deklarowane są zmienne itp. Oraz narzędzia, które dają przegląd przestrzeni nazw, ich relacji i metryk na ich temat.

W przeszłości miałem podobny problem - moją sztuczką było napisanie małego testu, zostawienie biurka na chwilę, powrót i symulacja testu na papierze. W ten sposób możesz przejrzeć swój kod ze świeżym spojrzeniem i masz określoną wartość do sprawdzenia (w przeciwieństwie do przeglądania kodu i mówienia „ahh ... ahh ... ma sens”)

Być może dobrze byłoby skupić się na nauce jednej umiejętności czytania kodu naraz, tak jak w formalnych przeglądach kodu każdy recenzent ma inną odpowiedzialność. Weź fragment kodu i spędź tydzień (powiedzmy) szukając po prostu złych nazw zmiennych. W tym tygodniu ponownie naciśnij ten sam kod, szukając potencjalnych wskaźników zerowych; w następnym tygodniu poszukaj duplikatów bloków kodu; następnie problemy z wielowątkowością itp.

Po poświęceniu czasu na doskonalenie różnych detektorów może się okazać, że możesz teraz czytać kod z kilkoma - a może wszystkimi - aktywnymi, dzięki czemu masz bogatsze wyczucie kodu w jednym czytaniu.

Jeśli mówisz o błędach kompilacji, tak się nie stanie. Najlepszym rozwiązaniem dla błędów kompilatora jest przypisanie osoby, która złamała kompilację, do opiekowania się kompilacjami, dopóki ktoś inny nie kompiluje kompilacji. Złamałeś go, naprawiłeś.

Błędy logiczne są znacznie trudniejsze do wykrycia. Jedną z technik zapobiegania prostym przypadkom jest pisanie testów jednostkowych / regresji.

Jedna wskazówka, którą usłyszałem dziś rano (w radiu SE), wzięła plik i zmniejszyła go do 3pt, a następnie poszukała wzorów w tekście. Nie będziesz w stanie odczytać tekstu, ale pojawią się różnego rodzaju wzory. To raczej niezła sztuczka.

I to jest jedno z tych miejsc, w których wiersz poleceń jest twoim przyjacielem, grep i rurociągi mogą zrobić wiele przydatnych rzeczy.

Przez kilka lat byłem instruktorem programowania. W tym okresie spędziłem dużo czasu czytając kod i komentując go. Obejmuje to wykrywanie błędów kompilacji (nie zawsze kompilowaliśmy kod studentów), błędów logicznych i projektowych oraz problemów z normalizacją.

Aby to zrobić dobrze, musieliśmy uważnie obserwować tego rodzaju błędy i móc „uruchomić” na sucho kod. Ten rodzaj działalności wystawił mnie również na wiele stylów kodowania. Dzisiaj moje umiejętności czytania kodu są dość dobre dzięki temu okresowi.

Więc moja propozycja dla ciebie jest następująca:

• Dokonaj przeglądu kodu z rówieśnikami.
• Zalecam przeczytanie ich kodu sam, zanim przejdziesz z nimi razem, abyś musiał dowiedzieć się, co kod robi dla siebie.
• Skomentuj strukturę i czystość kodu, standardy i logikę.
• Poprawi to jakość kodu, a także umiejętności czytania kodu.
• Kod zapoznaj się z własnym kodem jakiś czas po jego zakończeniu, w ten sposób będziesz mógł go ocenić „na nowo” i uczyć się na własnych błędach.

Powodzenia!