Witam, mógłby ktoś polecić jakąś książkę, bądź kurs przedstawiający standardowy sposób pisania skryptów/aplikacji w JS? Wiem, że istnieją jakieś wzorce, ale nie do końca je rozumiem. Jestem w stanie napisać wiele, może nie są to bardzo zaawansowane rzeczy, ale funkcjonalne. Niestety kod wygląda amatorsko i średnio czytelnie. Mółby ktoś na prostym przykładzie to wytłumaczyć/pokazać?
Pozdrawiam, serdecznie.
https://www.w3schools.com/
a dokładniej:
opcjonalnie:
Reszta to specyficzne rzeczy do specyficznych zastosowań.
Hm, nie byłem w stanie znaleźć tam jakiś patternów w zastosowaniu. Nie chodzi mi o to jak tworzyć obiekty, czy domknięcia. Miałem na myśli, czy są jakieś tutoriale, które pokazują jak używać wzorców. Jak pisać nasz kod, aby był czytelny. Tutaj także nie mam na mysli nazewnictwa zmiennych, czy sposobu ich deklaracji.
Wiem, że ludzie piszą zazwyczaj programy w ten sposób, że tworzą objekt np.
var myGame = {};
I w nim zawierają cały kod. Właśnie i coś takiego mi chodzi. I tutaj pytanie, czy można tak pisać zawsze? Nie ważne co byśmy wymyślili? Piszę trochę w JSie, uczę się go i chciałbym zacząć hermetyzować dane w poprawny sposób.
Czysty kod. Podręcznik dobrego programisty (niestety przykłady są dla C++/Java, a nie JavaScript, ale książka ma duże walory edukacyjne) - i oczywiście można ją kupić taniej niż w tej podanej księgarni.
I możesz pobrać przykładowy darmowy rozdział.
Niestety książka nie będzie miała tutaj zastosowania bo JS jest zbyt specyficzny.
Wzorce to coś zupełnie innego niż czytelny kod. Pisanie czytelnego kodu czyli samo dokumentującego się to umiejętność którą zdobywa się wraz z praktyką niezależnie od języka programowania. Najlepiej przyjąć jakieś zasady formatowania kodu i nazewnictwa trzymać się ich, a w razie potrzeby modyfikować tak by były coraz doskonalsze.
Twój przykład to wzorzec, chociaż osobiście moim zdaniem jest to naciąganie bo dla mnie to zwykłe dzielenie kodu na moduły - w innych językach byłby to biblioteki. Kiedy stosować? Nie da się tego tak wyjaśnić, musisz sam to trochę wyczuć i wynika to z doświadczenia. Zazwyczaj taki moduł tworzy się gdy masz kilka funkcji które robią coś i są one w jakiś logiczny sposób ze sobą powiązane. W tedy zamykasz je w jednym module aby mieć wszystko ładnie logicznie poukładane.
Napiszesz spaghetti code to zrozumiesz o co chodzi, w pewnym momencie jak będziesz miał np 10 funkcji które robią coś na użytkowniku to sam zauważysz że warto je zamknąć w module User.
O samych wzorcach możesz poczytać na internecie, jest tego cała masa z przykładami i bardzo często opisem w jakich sytuacjach stosować dany wzorzec. Na początek możesz poczytać o Module Pattern - ten którego przywołałeś. Jeśli chcesz więcej szukaj pod hasłem JavaScript Design Patterns.
Książek bym nie polecał, sam mam jedną o wzorcach projektowych i szczerze mówiąc utknąłem gdzieś w 1/3 i nie bardzo chce mi się ruszać bo po prostu jest to przerost formy nad treścią. Nie znaczy że taka książka nie dotarła by do Ciebie i Ci nie pod pasowała.
Ja ze swojego doświadczenia nie polecam książek o JS.
Pomijajac rozne ksiazki i kursy, polecam zaczac porzadnie uzywac narzedzi takiech jak lint i inne.
Tutaj jest cos co wyskoczylo dosc wysoko na google:
Dobry rule-set w eslint od razu wskaze wiele problemow w kodzie.
IDE takie jak WebStorm maja wbudowane pluginy i uzywaja lint tools automatycznie, w innych, jak np. sublime text, rowniez mozna takie pluginy dodac.
Tematy do szukania: modularnosc, komponenty, coupled/decoupled (zawsze (niemal) cod powinien byc decoupled), komunikacja miedzy modulami, code reuse, brak duplikatow
https://addyosmani.com/largescalejavascript/
Przykladowo, soft-standard jaki sami uzywamy:
Notacja Wegierska:
(uzywanie sName, sAddress, bIsAllowed, iNumberOfCars)
Nie wiecej niz 500 lini kodu w jednym pliku
nie wiecej niz 12 funkcji w pliku
pojedyncza funkcja nie powinna miec wiecej niz 30 lini kodu, i tylko kilka rozgalezien
Zawsze nazywaj zmienne w sposob, ktore okreslaja ich typ/uzycie. oCapacityRouterListenerFactory jest w pelni akceptowalne. (Inna sprawa, ze jezeli mialbym cos takiego, to pewnie stworszylbym namespace capacityRouter z factory, ktory stworzylby listener;) )
zreszta, tu masz calkiem ladna liste:
Zasada dziel i rzadz. Duzy problem lepiej podzielic na male problemy i kazdy z nich osobno rozwiazac. Tak samo duzy i nieczytelny kod lepiej podzielic na male moduly i kazdy z nich maksymalnie uproscic. Dzieki czemu latwiej znalezc wspolne elementy kodu i wydzielic je do jednej funkcji, zmniejszajac code duplication.
Zacznij uzywac unit tests, zawsze uzywaj git lub podobne (nawet jezeli tylko lokalnie), dawaj kod do sprawdzenia komus i uzyj jego uwagi do poprawy.