Nie chce pozniej sie skupiac na tym co musze przepisac albo zmienic, bo cos zle zostalo przemyslane albo w ogole.
Czemu nie? Refaktoring i zmiany to normalna rzecz w procesie budowania większej aplikacji.
Nie wiem rowniez jak sobie rozpisac klasy, metody, moze sa jakies sensowne narzedzia?
Kartka i długopis. W porywach kolorowe cienkopisy.
Chciałem zrobić pierwszą taką poważniejszą aplikacje webową i chciałbym zacząć od odpowiedniego zaprojektowania wszystkiego,
ale nie wiem jak się za to zabrać. Począwszy od tego czy ma być to jedna aplikacja typu monolit czy mikroserwisy
(nie będzie jakas bardzo rozbudowana), czego uzyc do frontendu (nie uzalezniam wyboru od znajomosci bo nie znam sie w ogole na froncie),
backend to to co znam dosc dobrze czyli java + spring.
Jak dla mnie tworząc coś większego trzeba zachować odpowiednie proporcje teorii i praktyki (albo: planowania i działania). Niestety wszystko się ze sobą wiąże i nie zaplanujesz na sucho większej aplikacji, jeśli nie byłeś w okopach i nie pisałeś podobnych aplikacji wcześniej. Będzie to tak do bólu naiwne i zapewne przeinżynierowane (albo niedoinżynierowane), że w połowie robienia swojego projektu (kiedy wyniknie ci x problemów, o których nie pomyślałeś) i tak pewnie stwierdzisz "cholera, nie zaprojektowałem tego dobrze. Robię od nowa!" (been there, done that).
Począwszy od tego czy ma być to jedna aplikacja typu monolit czy mikroserwisy (nie będzie jakas bardzo rozbudowana)
Jeśli nie wiesz, to znaczy, że albo nie miałeś styczności z aplikacjami typu monolit, albo nie miałeś styczności z mikroserwisami (swoją drogą te 2 podejścia wcale nie są jedyne, i też nie sądzę, że się wykluczają). Więc, żeby rozwiązać ten problem wypadałoby sprawdzić i to i to. Czyli napisać (jakąś) aplikację w ten sposób, jakąś w inny.
Dlatego mówi się, że doświadczenie programistyczne jest ważne - bo ludzie, którzy długo programują po prostu widzieli wiele rzeczy w praktyce - dlatego mają własne zdanie. A jeśli nawet czegoś nie wiedzą, to po prostu próbują różnych podejść (niekoniecznie na produkcji).
Dlatego moim zdaniem lepiej skupiać się na tym, żeby zdobywać praktyczne doświadczenie programistyczne (w sensie "zakodowałem aplikację, dużo spaghetti kodu, klasy nie takie jak trzeba, ale przynajmniej mogę teraz spojrzeć wstecz i uczyć się na własnych błędach") i dopiero potem projektować (bazując na doświadczeniu) niż się rzucać z motyką na słońce (chociaż rzucanie się z motyką na słońce też jest dobre, ale głównie po to, żeby się przekonać, że to błędna droga).