Projektowanie duzej aplikacji(kodu)

Cześć,

drodzy forumowicze, czy ktoś mógłby mi naświetlić jak się projektuje duże systemy/aplikacje - ale w obrębie jedego komponentu, tak to określę.

Wiem że jak mamy jakieś zależności, np. apka komunikuje się z cloudem to jest jasne że część kodu aplikacji za to odpowiada ale,
jak mam jeden duży "monolit" - core, aplikacji np. napisany w Javie który będzie zawierał z 200.000 lini kodu - z 5000 plików javovych - to jak się takie coś projektuje?

Pomyślałem na początku, że takie coś powinno się projektować za pomocą diagramów UML - ale dziś z kolei wyczytałem że takiego czegoś się już nie wykorzystuje od 20 lat. Jak zatem wy projektujecie wasz kod wiedząc że napiszecie z 30 plików a do tego chcielibyście aby to miało jakiś sens? Na kartce to rysujecie?

Ale projektowanie czego: przepływu danych, logiki biznesowej, UI, kodu, architektury?

Nie wiem skąd czerpiesz wiedzę, ale UML jest w dalszym ciągu stosowany. Fakt, że raczej odchodzi się od projektowania całego systemu czy kodu z góry (no design upfront), ale UML to nie tylko diagram klas, ale też diagramy sekwencji, przepływu, zależności, przypadków użycia i wiele innych, które mają znaczenie w przypadku, gdy trzeba opisać jakieś skomplikowane relacje czy przepływy aka procesy biznesowe. Oczywiście można to zrobić też za pomocą tradycyjnych bloczków czyli kolorowych beczek i prostokątów połączonych strzałkami, niemniej UML jest pewną notacją, która ma jakiś tam ustalony standard i potem nie trzeba się zastanawiać co architekt czy analityk miał na myśli.

Osobiście jeżeli firma dla której pracuję mi tego nie narzuca to do dokumentowania architektury systemu i komponentów stosuję model C4 https://c4model.com/ który swoją drogą też się ładnie mapuje na notację UML. A do opisu procesów notację BPMN.

Hmm, czyli rozumiem, że UML to jest coś co się wykorzystuje. Obecnie projektuje kilka plików (kilkanaście) i po prostu myli mi się już kilka rzeczy dlatego pytałem czy takie rozrysowywanie sobie rzeczy w ogóle jest jeszcze stosowane w IT :P

Tak, są firmy, które z tego korzystają (sam w takiej pracuję). Rozrysowywanie rzeczy jest jak najbardziej wskazane i pożądane zwłaszcza w złożonych systemach i aplikacjach. Jeśli dokumentujesz dla siebie to możesz dokumentować w czym chcesz i jak chcesz. Jeżeli pracujesz w zespole i rozwiązanie będzie rozwijane latami lub po zbudowaniu przekazane klientowi to wtedy warto dokumentację przygotować w jakimś znanym i ustandaryzowanym formacie.

Inne pytanie to co próbujesz rozrysować? Klasy, przypadki użycia, procesy, schemat bazy danych?

W poście pisałem o kodzie

Kodu w postaci klas się raczej nie wizualizuje. No chyba, że jakieś istotne fragmenty, żeby coś ważnego pokazać.

MateInf napisał(a):

drodzy forumowicze, czy ktoś mógłby mi naświetlić jak się projektuje duże systemy/aplikacje - ale w obrębie jedego komponentu, tak to określę.

Najpierw próbuje się robić waterfall - zaplanować wszystko dokładnie, piękną architekturę, co z czym ma się łączyć, a potem w praktyce okazuje się, że nie do końca wychodzi, więc robi się agile, czyli pisze się na spontana dokładając kolejne kawałki kodu spaghetti XD

Duża część programowania jest feedback driven: piszę kod tak, żeby po jego napisaniu mieć wiedzę co robić dalej. Oczywiście nie zawsze tak się da: przykładowo jak muszę wybrać bazę to muszę się zdecydować na coś konkretnego. Tak czy owak warto opóźniać decyzje projektowe, bo co z tego, że wszystko ładnie rozrysujesz jak rzeczywistość zweryfikuje, że tylko połowa ma sens

Projektowanie za pomocą UML rzadko działa, bo żeby umieć UML na wystarczająco ekspresywnym poziomie wyrażającym wszystko co istotne, to chyba trzeba 20 lat poświęcić na naukę tej notacji. Oczywiście niektóre diagramy (zazwyczaj w uproszczonej formie się przydają): flow, use case, component. Takich rzeczy oczywiście się nie robi na kartce tylko w (najlepiej) prostym programie do diagramów, np. draw.io

A projektowanie kodu... No cóż, trzeba po prostu wydzielać sensowne moduły (czyli zbiory biznesowo spójnych konceptów) z jednym punktem wejścia i enkapsulować to co powinno być enkapsulowane w ramach takiego modułu.

Sam kod pisać tak, żeby nie mieszać operacji inputu/outputu z logiką biznesową i wtedy wszystko zazwyczaj da się zrefactorować gdy po czasie okazuje się, że twój kod się źle zestarzał.

MateInf napisał(a):

jak mam jeden duży "monolit" - core, aplikacji np. napisany w Javie który będzie zawierał z 200.000 lini kodu - z 5000 plików javovych - to jak się takie coś projektuje?

Mało kto projektuje tak żeby było 200000 linii kodu :-)
Takie projekty się zdarzają, ale raczej rosną jak góra błota.
Prawie zawsze zaczyna się od małego projektu na kilka tygodni - kilkadziesiąt klas i dopiero seria przypadków, sukcesów i porażek powoduje, że takie projekty rosną.

UML się nie sprawdza, bo powoduje, że ludzie kłócą się o zupełnie nieistotne problemy, jaki kolor "szczałki" i czy diamencik zaciemniony czy nie.
Modelowanie na takim poziomie jaki jest przydatny w XXI wieku odbywa się na nieco wyższym poziomie abstrakcji. Jak mi jakiś architekt przychodził i rysował diagram klas to zmieniałem firme. (Kiedyś jak byłem architekte to na ośmiu koderów w zespole dokładnie jeden chciał, żeby mu rysować klasy, ale mu w końcu wyperswadowałem )
UML się też nie sprawdza, bo nie przeżywa spotkania z rzeczywistością - najdalej tydzień po starcie implementacji (danego modułu) diagramy UML przestają odpowiadać temu co jest w kodzie i powodują tylko wzrost zamieszania.

Obecnie czasem używa się C4 gdzie najniższy poziom to klasy (i nawet może to być zrobione w UML), ale przeważnie się tak nisko nie schodzi. Rysuje się moduły kodu (powiedzmy, że może to mieć odwzorowanie w pakietach, chociaż częście jest podprojektach (w gradle to podprojekt)).
I wykorzystuje się do tego tablicę, kartki lub painta.

Dokładniej projektuje się interfejsy/API Ale zamiast diagramów lepiej to robić w kodzie. (proto, openapi, czy po prostu klasy). Kod się czyta i modyfikuje przeważnie łatwiej niż diagramy (na pewnym poziomie).

TLDR;
Clean code > projektowanie w UML
Jak pilnujesz jakości i struktury kodu to projekt może się rozrosnąć od małego do całkiem sporego bez większego bólu i dodatkowego specjalnego projektowania.

@jarekr000000: UML się sprawdza i to bardzo dobrze. Jak ktoś nieumiejętnie go używa i modeluje w nim klasy to sam sobie winien. Ale UML to nie tylko diagram klas, jest wiele innych rodzajów diagramów. Nawet wspomniany C4 pokazuje jak mapować poszczególne poziomy abstrakcji na konkretne typy diagramów w UML bo jest on wciąż stosowany. Inaczej by tego Simon Brown i jego ludzie nie robili, gdyby nie widzieli w tym celu. Po prostu w niektórych firmach notacja UML jest standardem jeśli chodzi o dokumentację aplikacji i systemów, a to w jaki sposób ktoś modeluje system (na jakim poziomie abstrakcji) to inna para kaloszy. W całej dyskusji należy pamiętać, że UML jest tylko narzędziem.

Dzięki za odpowiedzi - sporo sie dowiedziałem ale też zaskoczyłem. A o C4 pierwszy raz usłyszałem ale się dokształcę.

MateInf napisał(a):

wyczytałem że takiego czegoś się już nie wykorzystuje od 20 lat. Jak zatem wy projektujecie wasz kod wiedząc że napiszecie z 30 plików a do tego chcielibyście aby to miało jakiś sens? Na kartce to rysujecie?

Być może same nazewnictwo uległo zmianie ale UML to dla mnie nadal podstawa. W małych systemach faktycznie czasem projekt rozrysowany jest tylko na tablicy ale jak już mam tak ponad 10 encji/obiektów to jednak trzeba to narysować w jakimś narzędziu.
Zazwyczaj piszę systemy bazodanowe więc podstawa to diagramy:

• ERD ( entity relationship diagram )
• DFD ( data flow diagram )
• Klasy ( przynajmniej te od strony biznesowej )
• czasem jakieś dodatkowe bazgroły...

Z większymi projektami w UML spotkałem się w życiu 2 razy:

1. na studiach
2. w firmie gdzie system miał ponad 1000 tabel i to co miał ten system robić wiedzieli tylko goście co wypluwali z siebie właśnie różne diagramy. Piałem w nim jakieś klasy i SQL'e i nie miałem pojęcia co to robiło i w jakim celu ale przełożeni byli zadowoleni bo pisałem szybko.

MateInf napisał(a):

Cześć,

drodzy forumowicze, czy ktoś mógłby mi naświetlić jak się projektuje duże systemy/aplikacje - ale w obrębie jedego komponentu, tak to określę.

..

jak mam jeden duży "monolit" - core, aplikacji np. napisany w Javie który będzie zawierał z 200.000 lini kodu - z 5000 plików javovych - to jak się takie coś projektuje?

Żeby z góry projektować ćwierć miliona linii to musiałby być jakiś jebutny korpo-waterfal (nigdy nie uczestniczyłem, nie wypowiem się) (a skoro korpo, to architektura nie po to, żeby coś Zrobić, tylko żeby robić, mieć etaty itd... )

realistycznie jest to tak:

jarekr000000 napisał(a):

Mało kto projektuje tak żeby było 200000 linii kodu :-)
Takie projekty się zdarzają, ale raczej rosną jak góra błota.
Prawie zawsze zaczyna się od małego projektu na kilka tygodni - kilkadziesiąt klas i dopiero seria przypadków, sukcesów i porażek powoduje, że takie projekty rosną.

Język OOP sztywno typowany (stara imperatywna Java - słowa @jarekr000000 z innego wątku) ma spore możliwości samo-dokumentowania.
Pamiętam za C++ Doxygen'em się malowało z kodu diagramy klas itd ... można to było wykastrować z informacji protected/private.
Dość to pozytywne nawet było ... Nawet to pozwalało np wchodzącym w projekt szybciej się zorientować przynajmniej w zakresie "do których obszarów mam pytania"

Fakt, inne lata, inna ilosc linii / klas ...

Nie ma czegoś takiego jak "jeden duzy monolit", to że całość aplikacji jest dostarczana w formie pojedynczego pliku i jest jednym projektem to jeszcze nie narzuca, że wszystko ma być w jednym pakiecie/module i mieć dostęp wszystko do wszytkiego.
Moim zdaniem rozpisywanie z góry wszystkiego na klasy nie ma sensu, bo UML to jednak papier, który wszystko przyjmie, a kompilator i rzeczywistość to już różnie. No i jeżeli te moduły są sensownie rozdzielone, to przecież programista to ogarnie i podzieli sobie sam. Ogólnie, ta część UML, która daje się przełożyć 1:1 na kod, to zwykle strata czasu.
Ogólnie podchodzę do tego tak:

• Czytam co system ma robić, na bardzo dużym poziomie ogólności. Np. pobierać dane z jakiejś kolejki/topicu i wrzucać je do DB.

• Na tej podstawie wiem, że będę potrzebował czegoś co te dane czyta z kolejki, jakiejś logiki, która je zinterpretuje, czegoś, co te dane zapisze do DB.

• Rysuję sobie 3 moduły, jakoś tam nazywam, niech będzie "message", "transformation", "persistance"

• Zastanawiam się jakie dane pomiędzy nimi mają przepływać i jakie mają być pomiędzy nimi interakcje, dopisuję na diagramie, albo w kodzie interface'y i DTOs

• Jeżeli któryś z tych modułów ma być bardziej rozbudowany, powtarzam dla niego ten proces rozkładając na kawałki...

  Oczywiście to dotyczy tylko rozpisania systemu na kawałki, projektowanie to nie tylko dzielenie na moduły/klasy.