Jak uczyć się rozumienia kodu napisanego przez innych?

Cześć, jak uczyć się rozumienia kodu napisanego przez innych? Interesuje mnie teraz frontend - czy są jakieś miejsca np. github gdzie można brać gotowy kod i edytować coś od siebie albo dodawać? Jeśli tak, to jak to robić, jeśli nie, to jakieś inne propozycje/rady?
Chciałbym przyspieszyć swój proces rozumienia kodu np. javascript, angular i inne powiązane technologie.

Jeśli są testy, to je czytasz i rozumiesz (mniej więcej) co tam się dzieje. Później po prostu analiza kodu, krok po kroku. Drogi na skróty nie ma.

Ktos1 napisał(a):

Cześć, jak uczyć się rozumienia kodu napisanego przez innych? Interesuje mnie teraz frontend - czy są jakieś miejsca np. github gdzie można brać gotowy kod i edytować coś od siebie albo dodawać? Jeśli tak, to jak to robić, jeśli nie, to jakieś inne propozycje/rady?
Chciałbym przyspieszyć swój proces rozumienia kodu np. javascript, angular i inne powiązane technologie.

Jeśli chcesz się nauczyć frameworka jak angular to najlepiej przeczytać całą dokumentację i próbować pisać coś swojego.

Jeśli chcesz pracować z czymś kodem, to ja sugerowałbym najpierw, przede wszystkim zacząć od uruchomienia aplikacji i pobawienia się z nią zanim w ogóle zajrzysz w kod - korzystając z aplikacji możesz dostać całkiem niezłe pojęcia nt tego jak ona działa i co robi. Dopiero potem wszedłbym w kod.

Ktos1 napisał(a):

Cześć, jak uczyć się rozumienia kodu napisanego przez innych?

Pisz dużo swojego kodu to zaczniesz rozumieć każdy kod

czy są jakieś miejsca np. github gdzie można brać gotowy kod i edytować coś od siebie albo dodawać? Jeśli tak, to jak to robić, jeśli nie, to jakieś inne propozycje/rady?

tak, dokładnie github. Każdy projekt open source teoretycznie powinien przyjmować kontybucje od wszystkich ale w praktyce muszą być dobrej jakości, czasem tylko od zrzeszonych firm i raczej nie przejdą żadne edycje od nowicjusza chyba że poprawiasz literówki w dokumentacji. Raczej możesz na początku tylko zobaczyć jak wyglądają poprawki wrzucane przez innych i przejrzeć kod całości.

Projekty do których można wrzucać swoje poprawki zazwyczaj mają plik CONTRIBUTING.md który opisuje co i jak wrzucać.

Chciałbym przyspieszyć swój proces rozumienia kodu np. javascript, angular i inne powiązane technologie.

No to open source na githubie to dobry początek. Proponuję wpisać w google "top github open source projects <nazwa technologii>"
Ale na samym początku przejdź przez tutoriale i spróbuj zrobić prosty własny projekt. Jak się samemu natkniesz na jakiś problem to będzie ci łatwiej zauważyć geniusz w cudzym kodzie, inaczej przescrollujesz go obojętnie.

z książek, takich gdzie są dłuższe przykłady dobrze wytłumaczone co robią

Wchodzisz w projekt i patrzysz, na to jak jest zrobiony, zaczynając od rzeczy, które są widoczne na pierwszy rzut oka:

• package.json jakie biblioteki są w zależnościach? Jak są zdefiniowane inne pliki konfiguracyjne (często te pliki z kropką na początku) itp.
• struktura folderów i plików
• możesz wchodzić w randomowe pliki i patrzeć, co w nich jest, żeby mieć ogólne rozeznanie, gdzie jest jakiego rodzaju kod.
• zwróć też uwagę na to, czy są testy i jak są napisane (szczególnie, że testy dają ci wgląd, jak się czegoś używa)
• czy jest jakaś dokumentacja? jeśli tak, to masz ułatwione zadanie
• dział issues na GH

I to da ci taki ogólny feeling projektu.

Natomiast później wypadałoby wejść np. w jakiś konkretny wybrany przez ciebie plik i zobaczyć np.

• jakie zależności importuje
• co eksportuje
• co mniej więcej robi (jak jest duży plik, to pełne zrozumienie będzie utrudnione)

Możesz też przejść do detalu i np. przyjrzeć się konkretnej funkcji. I patrzeć hmm, jaka sztuczka, nie znałem, albo o, więc ta funkcja bierze a, zamienia to na b, logiczne czy sposób implementacji budzi mojej wątpliwości, w mojej opinii jest to zły kod, bo coś tam (chodzi o to, że czytając cudzy kod jesteś jednocześnie uczniem, jak i recenzentem).

Ale też możesz poruszać się poza konkretny kawałek kodu a więc ta funkcja wywołuje funkcję fetchFoo(), która jest zdefiniowana w pliku foo.js. A co robi plik foo.js? I już wchodzisz w inny plik i sprawdzasz. A potem rekurencyjnie możesz w jeszcze kolejny plik wejść, żeby sprawdzić na jeszcze głębszym poziomie itp.

Tylko zauważ, że jeśli to duży projekt, to łatwo wejść zbyt głęboko w króliczą norę. I w rezultacie możesz wejść np. w 10 plików pod tobą i przejrzeć masę kodu, ale dalej nic nie rozumieć. Więc trzeba wiedzieć, kiedy powiedzieć stop i zaufać temu, że coś działa, ale nie wiesz do końca jak i może nie musisz na tym etapie. W większych projektach lepiej zbudować sobie taką ogólną siatkę wiedzy - pozostawiając sobie dużo pustej przestrzeni do ew. późniejszego uzupełnienia.

Czasami zrozumienie przychodzi też po czasie, jak mając różne fragmenty informacji, nagle zaczną ci się układać w całość.

Projekty Angularowe są przecież dość podobne do siebie (bo to porządny framework a nie jakieś pierdobiblioteki )

Przy zrozumieniu dłuższych fragmentów kodu często pomaga mi "przepisanie go od nowa".

Czyli wycinam dany fragment z pliku i po chwili ponownie przepisuje linijka po linijce tak jak było bez żadnych zmian odtwarzając proces myślowy autora :D

Jeszcze można po prostu spróbować opisać kod swoimi słowami (w języku naturalnym), zrobić taką jakby własną recenzję-dokumentację danego kodu, tak jakby kogoś chciało się nauczyć, co dany kod robi.

Mi pomaga

• napisanie testow do danej funkcjonalności, najlepiej na zasadzie BDD. Czyli given, when, then
• użycie debuggera i krok po kroku podgląd aktualnych zmiennych i wywołań,
• opisywane słownomuzyczne tego co kod i jak robi, czyli za co są odpowiedzialne klasy i metody składające się na dany przypadek użycia
• przeklinanie pod nosem autora/autorów danej funkcjonalności*

*tak, rozumiem, nie jest to nic osobistego, mnie też przeklinają bo moj kod nie zawsze kod jest clean i pure i nie mam problemu a nawet doceniam szczerość gdy ziomek przychodzi do mnie i pyta co za chałę w kodzie odwaliłem

Wrzuć kod do Chatu GPT, żeby Ci wytłumaczył.

Spine napisał(a):

Wrzuć kod do Chatu GPT, żeby Ci wytłumaczył.

przeciez on tego nie rozumie, znaczy ChatGPT nie rozumie co powtarza jak tresowana papuga

@Miang: No co Ty.
Wziąłem jedną klasę z mojego projektu (pisaną od zera) i nawet nieźle darmowy Chat ją skomentował.

Zadane pytanie:

Mógłbyś mi wytłumaczyć ten kod?
<wklejam klasę>

Odpowiedź:

Ten kod jest napisany w języku C# i jest częścią projektu w silniku Unity, który odpowiada za kontrolę granic kamery w grze. Poniżej przedstawiam wyjaśnienie poszczególnych części kodu:

1. Deklaracje zmiennych:

   • public PolygonCollider2D camBoundsCollider; - Ta zmienna publiczna przechowuje odniesienie do komponentu PolygonCollider2D, który reprezentuje obszar granic kamery.
   • const float projectileBoundsMargin = 1.5f; - Stała zmienna określa margines rozszerzenia granic obszaru widzenia kamery.
   • public Bounds projectileBounds { get; private set; } - Ta zmienna publiczna jest właściwością i przechowuje obiekt Bounds, który określa granice obszaru, w którym mogą się znajdować obiekty widoczne na ekranie.
   • public float boundsResizeDistance { get; private set; } - Ta zmienna publiczna jest również właściwością i przechowuje odległość zmiany rozmiaru granic obszaru widzenia kamery.

2. Metoda Awake():

   • Jest to jedna z metod cyklu życia obiektu w Unity, która jest wywoływana przy inicjalizacji obiektu.
   • W metodzie Awake(), wywoływane są dwie funkcje: ComputeProjectileBounds() i ResizeToScreenAspect(), które przygotowują granice obszaru widzenia kamery.

3. Metoda ComputeProjectileBounds():

   • Ta funkcja oblicza granice obszaru widzenia kamery na podstawie granic określonych przez komponent PolygonCollider2D (camBoundsCollider).
   • Najpierw uzyskiwane są granice obszaru kamer w postaci obiektu Bounds.
   • Następnie granice te są rozszerzane o margines projectileBoundsMargin w osiach X i Y, oraz o stałą wartość 500 w osi Z (głębokość).
   • Ostatecznie granice te są przypisywane do zmiennej projectileBounds.

4. Metoda ResizeToScreenAspect():

   • Ta funkcja jest wywoływana przed inicjalizacją kontrolera kamery i służy do dostosowania granic obszaru widzenia kamery na podstawie proporcji ekranu.
   • Oblicza różnicę pomiędzy rozmiarem kamery (orthographic size) a rozmiarem kamery w trybie widescreen (określonym przez CamController.WidescreenOrthoSize).
   • Następnie modyfikuje punkty granic obszaru widzenia kamery w taki sposób, aby dostosować je do proporcji ekranu i różnicy rozmiarów.
   • Na końcu przypisuje zmodyfikowane punkty do komponentu PolygonCollider2D.

Ten kod jest częścią bardziej skomplikowanego projektu w Unity i ma na celu dostosowanie granic obszaru widzenia kamery do proporcji ekranu oraz przygotowanie granic obszaru, w którym obiekty gry są aktywne lub widoczne.

Oczywiście nie jest to idealne - niektórych rzeczy źle się domyślił.
Ale zawsze to jakiś punkt zaczepienia. W najlepszym wypadku może zwrócić Twoją uwagę na szczegóły, na które Ty jeszcze nie zwracasz uwagi.

Spine napisał(a):

Wrzuć kod do Chatu GPT, żeby Ci wytłumaczył.

Dział prawny lubi to.

Z kodem biznesowym ktory jest IP i jest własnością przedsiębiorstwa trzeba uwazac bo bez zgody firmy będzie to naruszenie licencji czy tam praw autorskich.

U mnie w firmie jest duże parcie na uświadamianie ludzi by nie wrzucali firmowego kodu do chat-gpt i tego typu rzeczy.

@markone_dev: Ale OP chce się uczyć webdevu z publicznych repo GitHuba...

BTW. ostatnio stawiałem stronkę i ChatGPT bardzo fajnie wygenerował mi jej fragmenty, które potem dostosowałem do swoich potrzeb.
Np. skrypt + css + html galerii zdjęć. Tak, żeby były przyciski next, prev itd.
Jak się nie zna w zadowalającym stopniu JS, to wiele ułatwia i pozwala uniknąć typowych problemów ;)

Więc w sumie OP mógłby się uczyć nie tylko z kodu innych, ale też zadając pytania AI.

greendev napisał(a):

Jeśli są testy, to je czytasz i rozumiesz (mniej więcej) co tam się dzieje. Później po prostu analiza kodu, krok po kroku. Drogi na skróty nie ma.

testy xD

Odpuść.

Spine napisał(a):

@Miang: No co Ty.
Wziąłem jedną klasę z mojego projektu (pisaną od zera) i nawet nieźle darmowy Chat ją skomentował.

Zadane pytanie:

Mógłbyś mi wytłumaczyć ten kod?
<wklejam klasę>

Odpowiedź:

Ten kod jest napisany w języku C# i jest częścią projektu w silniku Unity, który odpowiada za kontrolę granic kamery w grze. Poniżej przedstawiam wyjaśnienie poszczególnych części kodu:

1. Deklaracje zmiennych:

   • public PolygonCollider2D camBoundsCollider; - Ta zmienna publiczna przechowuje odniesienie do komponentu PolygonCollider2D, który reprezentuje obszar granic kamery.
   • const float projectileBoundsMargin = 1.5f; - Stała zmienna określa margines rozszerzenia granic obszaru widzenia kamery.
   • public Bounds projectileBounds { get; private set; } - Ta zmienna publiczna jest właściwością i przechowuje obiekt Bounds, który określa granice obszaru, w którym mogą się znajdować obiekty widoczne na ekranie.
   • public float boundsResizeDistance { get; private set; } - Ta zmienna publiczna jest również właściwością i przechowuje odległość zmiany rozmiaru granic obszaru widzenia kamery.

2. Metoda Awake():

   • Jest to jedna z metod cyklu życia obiektu w Unity, która jest wywoływana przy inicjalizacji obiektu.
   • W metodzie Awake(), wywoływane są dwie funkcje: ComputeProjectileBounds() i ResizeToScreenAspect(), które przygotowują granice obszaru widzenia kamery.

3. Metoda ComputeProjectileBounds():

   • Ta funkcja oblicza granice obszaru widzenia kamery na podstawie granic określonych przez komponent PolygonCollider2D (camBoundsCollider).
   • Najpierw uzyskiwane są granice obszaru kamer w postaci obiektu Bounds.
   • Następnie granice te są rozszerzane o margines projectileBoundsMargin w osiach X i Y, oraz o stałą wartość 500 w osi Z (głębokość).
   • Ostatecznie granice te są przypisywane do zmiennej projectileBounds.

4. Metoda ResizeToScreenAspect():

   • Ta funkcja jest wywoływana przed inicjalizacją kontrolera kamery i służy do dostosowania granic obszaru widzenia kamery na podstawie proporcji ekranu.
   • Oblicza różnicę pomiędzy rozmiarem kamery (orthographic size) a rozmiarem kamery w trybie widescreen (określonym przez CamController.WidescreenOrthoSize).
   • Następnie modyfikuje punkty granic obszaru widzenia kamery w taki sposób, aby dostosować je do proporcji ekranu i różnicy rozmiarów.
   • Na końcu przypisuje zmodyfikowane punkty do komponentu PolygonCollider2D.

Ten kod jest częścią bardziej skomplikowanego projektu w Unity i ma na celu dostosowanie granic obszaru widzenia kamery do proporcji ekranu oraz przygotowanie granic obszaru, w którym obiekty gry są aktywne lub widoczne.

Oczywiście nie jest to idealne - niektórych rzeczy źle się domyślił.
Ale zawsze to jakiś punkt zaczepienia. W najlepszym wypadku może zwrócić Twoją uwagę na szczegóły, na które Ty jeszcze nie zwracasz uwagi.

Dla mnie to w ogóle nie jest wytłumaczenie tej klasy :| to jest jakby przeczytanie kodu.

Nie ma powiedziane w ogóle do czego ta klasa służy, jaką ma odpowiedzialność, jaki problem rozwiązuje, etc.

Riddle napisał(a):

Spine napisał(a):

@Miang: No co Ty.
Wziąłem jedną klasę z mojego projektu (pisaną od zera) i nawet nieźle darmowy Chat ją skomentował.

Zadane pytanie:

Mógłbyś mi wytłumaczyć ten kod?
<wklejam klasę>

Odpowiedź:

Ten kod jest napisany w języku C# i jest częścią projektu w silniku Unity, który odpowiada za kontrolę granic kamery w grze. Poniżej przedstawiam wyjaśnienie poszczególnych części kodu:

1. Deklaracje zmiennych:

   • public PolygonCollider2D camBoundsCollider; - Ta zmienna publiczna przechowuje odniesienie do komponentu PolygonCollider2D, który reprezentuje obszar granic kamery.
   • const float projectileBoundsMargin = 1.5f; - Stała zmienna określa margines rozszerzenia granic obszaru widzenia kamery.
   • public Bounds projectileBounds { get; private set; } - Ta zmienna publiczna jest właściwością i przechowuje obiekt Bounds, który określa granice obszaru, w którym mogą się znajdować obiekty widoczne na ekranie.
   • public float boundsResizeDistance { get; private set; } - Ta zmienna publiczna jest również właściwością i przechowuje odległość zmiany rozmiaru granic obszaru widzenia kamery.

2. Metoda Awake():

   • Jest to jedna z metod cyklu życia obiektu w Unity, która jest wywoływana przy inicjalizacji obiektu.
   • W metodzie Awake(), wywoływane są dwie funkcje: ComputeProjectileBounds() i ResizeToScreenAspect(), które przygotowują granice obszaru widzenia kamery.

3. Metoda ComputeProjectileBounds():

   • Ta funkcja oblicza granice obszaru widzenia kamery na podstawie granic określonych przez komponent PolygonCollider2D (camBoundsCollider).
   • Najpierw uzyskiwane są granice obszaru kamer w postaci obiektu Bounds.
   • Następnie granice te są rozszerzane o margines projectileBoundsMargin w osiach X i Y, oraz o stałą wartość 500 w osi Z (głębokość).
   • Ostatecznie granice te są przypisywane do zmiennej projectileBounds.

4. Metoda ResizeToScreenAspect():

   • Ta funkcja jest wywoływana przed inicjalizacją kontrolera kamery i służy do dostosowania granic obszaru widzenia kamery na podstawie proporcji ekranu.
   • Oblicza różnicę pomiędzy rozmiarem kamery (orthographic size) a rozmiarem kamery w trybie widescreen (określonym przez CamController.WidescreenOrthoSize).
   • Następnie modyfikuje punkty granic obszaru widzenia kamery w taki sposób, aby dostosować je do proporcji ekranu i różnicy rozmiarów.
   • Na końcu przypisuje zmodyfikowane punkty do komponentu PolygonCollider2D.

Ten kod jest częścią bardziej skomplikowanego projektu w Unity i ma na celu dostosowanie granic obszaru widzenia kamery do proporcji ekranu oraz przygotowanie granic obszaru, w którym obiekty gry są aktywne lub widoczne.

Oczywiście nie jest to idealne - niektórych rzeczy źle się domyślił.
Ale zawsze to jakiś punkt zaczepienia. W najlepszym wypadku może zwrócić Twoją uwagę na szczegóły, na które Ty jeszcze nie zwracasz uwagi.

Dla mnie to w ogóle nie jest wytłumaczenie tej klasy :| to jest jakby przeczytanie kodu.

Nie ma powiedziane w ogóle do czego ta klasa służy, jaką ma odpowiedzialność, jaki problem rozwiązuje, etc.

Dokładnie miałem takie wrażenie, nie ma nic o domenie. Tak to ja sam mogę sobie odczytać z kodu i to bez chata.

Riddle napisał(a):

Nie ma powiedziane w ogóle do czego ta klasa służy, jaką ma odpowiedzialność, jaki problem rozwiązuje, etc.

Jak to nie ma? Na samym końcu napisane:

ma na celu dostosowanie granic obszaru widzenia kamery do proporcji ekranu oraz przygotowanie granic obszaru, w którym obiekty gry są aktywne lub widoczne.

To jest komponent, który przypinam do kamery i on ustawia widoczny obszar tak, żeby niezależnie od proporcji ekranu, zawsze pokazywać tyle samo.

Spine napisał(a):

Riddle napisał(a):

Nie ma powiedziane w ogóle do czego ta klasa służy, jaką ma odpowiedzialność, jaki problem rozwiązuje, etc.

Jak to nie ma? Na samym końcu napisane:

ma na celu dostosowanie granic obszaru widzenia kamery do proporcji ekranu oraz przygotowanie granic obszaru, w którym obiekty gry są aktywne lub widoczne.

No okej, faktycznie, jest podsumowanie. To Ci przyznam.

Ale nadal proporcje szczegółów technicznych do faktycznego opisu jest bardzo duży. Wolałbym żeby były odwrotnie - czyli dużo opisu domeny, a szczegóły techniczne i implementacyjne powinny być w jednym paragrafie na dole.

Myślę że człowiek dużo inaczej opisałby tą klasę.

@Spine: a weź wklej tą klasę którą dałeś chatu?

Riddle napisał(a):

@Spine: a weź wklej tą klasę którą dałeś chatu?

Jak chcesz:

using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class CamBounds : MonoBehaviour
{
    public PolygonCollider2D camBoundsCollider;

    const float projectileBoundsMargin = 1.5f;
    public Bounds projectileBounds { get; private set; }
    public float boundsResizeDistance { get; private set; }

    private void Awake()
    {
        ComputeProjectileBounds();
        ResizeToScreenAspect();
    }

    void ComputeProjectileBounds()
    {
        Bounds bounds = camBoundsCollider.bounds;

        bounds.Expand(new Vector3(
            projectileBoundsMargin * 2.0f,
            projectileBoundsMargin * 2.0f,
            500.0f));

        projectileBounds = bounds;
    }

    /// <summary>
    /// Should be executed before CamController.Initialize(); !!!
    /// </summary>
    void ResizeToScreenAspect()
    {
        boundsResizeDistance = CamController.GetOrthoSize() - CamController.WidescreenOrthoSize;

        Vector2[] boundsPoints = camBoundsCollider.points;

        // figure out: bottom points, top points Y
        float minY = 500000.0f;
        float maxY = -500000.0f;

        for (int i = 0; i < boundsPoints.Length; i++)
        {
            if (boundsPoints[i].y > maxY)
            {
                maxY = boundsPoints[i].y;
            }

            if (boundsPoints[i].y < minY)
            {
                minY = boundsPoints[i].y;
            }
        }

        // resize collider vertically
        for (int i = 0; i < boundsPoints.Length; i++)
        {
            if (Mathf.Abs(boundsPoints[i].y - maxY) < 0.5f)
            {
                // resize top point
                boundsPoints[i].y += boundsResizeDistance;
                continue;
            }

            if (Mathf.Abs(boundsPoints[i].y - minY) < 0.5f)
            {
                // resize bottom point
                boundsPoints[i].y -= boundsResizeDistance;
            }
        }

        camBoundsCollider.points = boundsPoints;
    }
}

Spine napisał(a):

Riddle napisał(a):

@Spine: a weź wklej tą klasę którą dałeś chatu?

No to ja bym tą klasę komuś opisał zupełnie inaczej niż ten chat.

Moja subiektywna opinia wyglądałaby tak:

• Na plus:
  • Fajnie że jest mała
  • Fajnie że nie ma jednoliterowych zmiennych
  • fajnie że jest concise i to widać
  • fajnie że nie ma bezsensownych zmiennych
  • Nazwy metod ComputeProjectileBounds oraz ResizeToScreenAspect są bardzo dobre.
• Na minus (dla mnie):
  • Ja nie używam komentarzy, i dla mnie to jest minus że są. Jeśli jest komentarz // resize collider vertically, to czemu nie wydzielić tego do funkcji ReiszeColliderVertically()?
  • Pole camBoundsCollider dla mnie jest nie jasne, nie wiem czy jest odziedziczone, ale ma dzwiną nazwę dla mnie.
  • projectileBoundsMargin dla mnie się wydaje bezzasadna. Rozumiem że jest wydzielona, żeby było widać że *2 jest po to że margines jest z dwóch stron? Bo jeśli tak, to ja bym to wydzielił do mniejszej funkcji.

Spine napisał(a):

@markone_dev: Ale OP chce się uczyć webdevu z publicznych repo GitHuba...

Moja odpowiedź była bardziej ogólna. Wiadomo, że jak coś jest publiczne na GH to nie ma z tym problemu. Zwracam uwagę na to, że co raz więcej firm wprowadza politykę zakazującą wprowadzania firmowych informacji (nie tylko kodu) do publicznych narzędzi jak chat-gpt.

Na froncie to ma prosto, zazwyczaj jeden wątek + asynchroniczne doczytywanie zasobów + eventy. Polecam ustawić sobie breakpoint i lecieć step-by-step. Potrwa długo ale po tym czasie zrozumiesz że 80% kodu robi to samo tylko jest inaczej napisana bo wcześniejsi autorzy nie przejmowali się debuggerem i pisali po swojemu.

Riddle napisał(a):

Jeśli chcesz się nauczyć frameworka ...

To ważne. Jak już pojawiał sie framework (jakikolwiek, javascriptowy czy dowolny inny), pojawiają się silne konwencje "jak to robić", o wiele ważniejsze niż syntax języka.

Riddle napisał(a):

• projectileBoundsMargin dla mnie się wydaje bezzasadna. Rozumiem że jest wydzielona, żeby było widać że *2 jest po to że margines jest z dwóch stron? Bo jeśli tak, to ja bym to wydzielił do mniejszej funkcji.

W tym momemcie ujawniasz inny element. Jak framework, to prawie zawsze będzie miał coś do formatowania / ustawiania GUI w mm / pixelach / kolorowania itp

Pod kątem czytania kodu wymagane sie stają dwa fundamenty: język i koncepcje programowania / język i koncepcje graficzne.
Nie majac tego dobrze poznanego, trudno postąpić w "czytaniu kodu". Zgodził bym się, że jak interesuje nas kod "algorytmiczny", to znajmosc "grafiki" nie musi być mistrzowska, ale przynajmniej solidne podstawy

Wypowiadam się w szerokim sensie "frameworków" i szerokim spektrum języków, np ś.p. C++ MFC i GUI w filozofii WIn32

Dzięki za odpowiedzi!

A próbowałeś analizować jakiś kod?
Czy tylko tak pytasz, a nawet nie chciało ci się sprawdzić i teraz gdybasz jakby to było?

tumor napisał(a):

A próbowałeś analizować jakiś kod?
Czy tylko tak pytasz, a nawet nie chciało ci się sprawdzić i teraz gdybasz jakby to było?

Próbowałem, ale wolno mi to szło, stąd mój post pierwszy.

Ja się uczyłem w assemblerze czytać czyjeś kody, to najpierw się tłumaczy na język C z assemblera jakieś proste składnie, potem z C bez metadanych na C z metadanymi, metadane to są nazwy funkcji, nazwy obiektów.

I potem po prostu się wie na tyle ile trzeba jak coś działa, ale to zabiera mnóstwo czasu nawet cały dzień analizowania, ale i tak musisz wiedzieć co chcesz przeanalizować więc to generuje drugi problem.
Nie wiesz gdzie jest to co chcesz przeanalizować.

To w takim razie załóżmy, że to jest strona internetowa, np. 4p czy coś innego.
Chcesz wiedzieć czy to jakieś style to najprościej znaleźć element dom, tam masz style css i ich nazwy, możesz je wygrepować w repozytorium to znajdziesz pliki css z nimi.
Jak strona jest z kodem źródłowym, mapami to jak klikniesz jakiś element onclick, to tam jest podczepiona funkcja w dev toolsach możesz to otworzyć, dostaniesz miejsce kodu źródłowego gdzie jest ta funkcja.
Jak jest clean code napisana, ma czytelne nazwy, które same siebie tłumaczą i umiesz coś takiego sam zaimplementować to praktycznie od razu wiesz.

np. po najechaniu myszką na danie like na stronie 4p, jest wyświetlana lista osób, które polikowały, teraz jak dev tools otworzysz w to w network będziesz miał pod jaki endpoint api frontend uderzał.
https://4programmers.net/Forum/Post/Voters/ i na końcu id posta i to zwraca ci jsona.

Teraz wchodzisz na stronę 4p coyote github, tam wchodzisz do app -> routes i teraz możesz za pomocą grep znaleźć sobie tego forum/post/voters, albo ręcznie przeszukać.
Na szczęście jest to prostolinijne app -> routers -> forum.php.
Tam widzisz linijkę $this->get('Post/Voters/{post}', ['uses' => 'VoteController@voters']);, która jest odpowiada za api endpoint powyższy, teraz wiemy, że jest wywoływany VoteController@voters.

Teraz wchodzimy do Coyote -> App -> Http -> Controllers -> Forum -> VoteController.php, dość łatwo tam dojść lub skorzystać z wyszukiwarki tego VoteController.
W tym pliku mamy dwie funkcje index i voters, nas interesuje ta druga.

public function voters(Post $post)
    {
        $post->load(['votes', 'user' => fn ($query) => $query->select('id', 'name')->withTrashed()]);

        return [
            'id' => $post->id,
            'users' => $post->votes->pluck('user.name')
        ];
    }

To jest phpowy orm, dla mnie mało czytelny, więc dobrze też wcześniej znać tego eloquent orm.

Tak możesz sobie od jakiejś funkcjonalności do korzenia dojść, potem możesz iść dalej i zobaczyć implementację tego Post obiektu itp.

Możesz też chcieć analizować po stronie frontendu, to możesz znaleźć jakąś funkcję czy wywoływaną po onclick i w dev toolsach jak są source mapy to od razu masz położenie w projekcie gdzie to jest.
Jak nie ma to zawsze możesz grepować, za tym czego szukasz.

Najprościej się chwycić czegoś i iść po nitce do kłębka.
Też warto przejrzeć kod źródłowy jak mniej więcej to działa, ale to nie jest tak, że w 5minut zrozumiesz to są duże projekty, różne frameworki i decyzje architektoniczne podjęte.

Ale dużo rzeczy jest podobna, jak jakieś api, które zwykle jest najprostszą rzeczą, czy to w springu czy innych frameworkach.
Trudniej jest jak wszystko jest bardziej abstrakcyjne i nie znasz tych abstrakcji.