Nauka mvc, oop javascript // co przed frameworkiem.

Przed frameworkiem warto poznać podstawowe narzędzia typu NPM, webpack, moduły, robienie bundla. To tego TypeScript też się przyda. Co do klas, to w JS można bez tego żyć, wydzielając funkcje i stosując moduły. Funkcyjny React pokazuje, że bez klas można się obyć, chyba że wolisz Angulara. W backendzie w Node też można stosować funkcyjne podejście i zapomnieć o this.

To, co @SkrzydlatyWąż napisał oraz naucz się refaktoringu.

Często za dużo rzeczy w global scope, i ogólnie syf.

Jak się zaczyna projekt, to wygodnie jest robić wszystko w jednym pliku i używać zmiennych globalnych.
Jak masz kilkadziesiąt linijek kodu, to naprawdę nie trzeba tego dzielić na 10 różnych plików ani robić super eleganckiego kodu.

Problem jest, żeby wychwycić moment, kiedy zacząć refaktorować i wydzielać rzeczy do modułów (albo do osobnych funkcji, do osobnych klas itp.)

• Jeśli zrobisz to za późno, to będziesz walczył z długiem technicznym i kodem spaghetti. Wtedy jeśli projekt jest mały, to najlepiej przepisać od nowa, jak projekt jest duży, to już się nie będzie opłacało przepisywanie i co najwyżej można wprowadzać małe zmiany stopniowo.

• Jak zrobisz to za wcześnie, to prawdopodobnie wydzielisz złe abstrakcje i zrobisz jakiś przeinżynierowany potworek, bo nie będziesz jeszcze czuł projektu.

Jakie źródła prócz dobrze napisanych apek w repo, można wziąć pod uwagę i przeglądać ?

Źle napisane apki. Serio, najwięcej można się nauczyć ze złych projektów (tylko sam kod nie wystarczy - musi być kontekst. Czyli albo trzeba samemu pisać zły kod, żeby się nauczyć pisać ładny, albo można pracować ze złym kodem napisanym przez kogoś innego i wtedy też widzisz, dlaczego dany kod jest zły, bo widzisz, że to się źle utrzymuje. Można też pójść na skróty i przeglądać projekty na Githubie i czytać issues. Tam bardzo często można prześledzić historię jakiegoś ficzera albo dowiedzieć się, że coś było źle zaprojektowane w przeszłości. Czyli takie turbodoświadczenie / ty tylko sobie czytasz dyskusję programistów i w ciągu godziny możesz zyskać wglądy, do jakich oni dochodzili przez miesiące developerki).

Czyli - lepiej się uczyć ze złych projektów i z błędnych wyborów. Bo dobry projekt to nawet jak zobaczysz jakąś technikę, to jak nie będziesz wiedział, dlaczego ona jest dobra, co najwyżej możesz ją skopiować na zasadzie cargo cultu. Tzn. to też może być dobre, czasem warto zobaczyć jakąś technikę i ją naśladować, albo w ogóle eksperymentować, pisać kod inaczej. Np. robiłeś na klasach, to zrób bez klas. Czyli randomowe wprowadzanie zmian, trochę jak ewolucja w biologii. Tym niemniej ludzie nie wiedzą, że to ewolucja i chcą robić rewolucję (tj. myślą, że użycie jakiegoś wzorca projektowego od razu sprawi, że ich kod stanie się dobry, mimo, że to tak nie działa).

Nie ma tak łatwo :D

Musisz rozumieć problemy na jakie próbujesz znaleźć rozwiązanie oraz musisz zdawać sobie sprawę z możliwości i ograniczeń jakie wnoszą poszczególne rozwiązania.

To jest główna część jaka wynika z myślenia. Sam zapis to tylko obróbka, zajęcie dla wyszkolonej małpy.

Także jak skupisz się zbytnio na czystych kodach to w efekcie będzie to wyglądać tak jakbyś poprzez formę chciał ukryć swoje braki.

Jak pisać lepiej?

Interesuj się problemami, identyfikuj je, analizuj, zdobywaj wiedzę, doczytuj, pytaj, dyskutuj z ludźmi, sięgaj do fachowej literatury, wyprowadzaj własne rozwiązania, analizuj rozwiązania innych ludzi, próbuj zmieniać perspektywę, a następnie powtórz.

@LukeJL: @pan_krewetek:
Może faktycznie za szybko... Problem w tym, a może własnie nie problem... że zdaję sobie z tego sprawę. Zadałem sobie zadanie, wzorowałem się na innym projekcie na klasach. Ale na zasadzie przeglądnę max 1h, zamknę i robię swoje. No i niby projekt działa i tak jak mówicie, człowiek zdał sobie sprawę że w pewnym momencie za szybko leciał z tematem.

Mówią żeby na początku nie tracić czasu na pierdoły i nie spuszczać się 3h nad jedną rzeczą - nie mówię o rozwiązaniu problemu który się napotka, a bardziej o kwestie np. performance. Czy uzyć listenera i eventdelegation. To taki przykład bo na początku wydawało mi się, że nauczę się kiedy - i co używać. Ale widzę że to tak nie działa.

Projekt na pewno będę chciał jeszcze rozwinąć, ale pewnie go przepiszę jak zdobędę trochę wiedzy. By nie robić tego 2-3 razy.

Czyli waszym zdaniem olać sprawę i przyjdzie to samo z czasem? Może się wam wydać że przyszedłem tu szukać złotego środka na naukę, nie chcę być źle zrozumiany. Po prostu widzę że jak coś zaplanuję, to nauka idzie lepiej. Chodzi mi o focus nad jedną rzeczą, a nie skakanie po zagadnieniach bez celu.

Obejrzałem 3 projekty taskList - jakkolwiek banalnie to brzmi i nudnie. 3 różne podejście. MVC, zwykłe funkcyjne i trzecie na zasadzie fabryki ( chyba, bo nie mam wiedzy, ale kod przypominał tworzenie komponentów za pomocą dodatkowo ręcznie napisanej biblioteki ).

Pewnie trzecie podejście to przerost formy nad treścią. Ale zastanawiałem się jak takie publiczne apki, wypuszczone od profesjonalnych devów wyglądają.
To tylko przykłady które zamieszały mi w głowie.

Jak się zaczyna projekt, to wygodnie jest robić wszystko w jednym pliku i używać zmiennych globalnych.
Jak masz kilkadziesiąt linijek kodu, to naprawdę nie trzeba tego dzielić na 10 różnych plików ani robić super eleganckiego kodu.

Problem jest, żeby wychwycić moment, kiedy zacząć refaktorować i wydzielać rzeczy do modułów (albo do osobnych funkcji, do osobnych klas itp.)

Rozumiem. Zauważyłem też, że zbyt szerokie skupianie się na problemie powoduje że ciężko zacząć. Jak podzielę to na mniejsze problemy i implementuję to jakoś leci, i jeszcze niemożliwe wcześniej po 3h jest napisane ( dunno how ).

Także jak skupisz się zbytnio na czystych kodach to w efekcie będzie to wyglądać tak jakbyś poprzez formę chciał ukryć swoje braki.

Chyba faktycznie zacząłem za dużo myśleć.

Przed frameworkiem warto poznać podstawowe narzędzia typu NPM, webpack, moduły, robienie bundla. To tego TypeScript też się przyda. Co do klas, to w JS można bez tego żyć, wydzielając funkcje i > stosując moduły. Funkcyjny React pokazuje, że bez klas można się obyć, chyba że wolisz Angulara. W backendzie w Node też można stosować funkcyjne podejście i zapomnieć o this.

TypeScript wypada kojarzyć czy warto coś umieć napisać. Nie wiem w którą stronę chciałbym iść. Na pewno spróbuje Reacta na początku. Na razie daję sobie rok z Jsem.

Trochę mnie podbudowaliście. Wrócę na ścieżkę nauki którą kontynuowałem i będę wracał do zagadnień które poruszyłem w tym projekcie co robiłem. Pobijając błędy które tu zrobiłem.

Nie chciałem się żalić, ale taki post chyba wyszedł. Jestem otwarty jeszcze na jakieś rady.

Wrócę do braków: Fetch, moduły, npm, babel itd..

sięgaj do fachowej literatury

Chodzi o książki czy arty znanych pro / publicystów programistów ?

Czyli waszym zdaniem olać sprawę i przyjdzie to samo z czasem?

Wątpię. Są osoby, które pomimo długiego stażu programowania wciąż tworzą szajs, także tak zbytnio się nie dowiesz jak rozwiązywać problemy.

Po prostu na początku zwróć uwagę, że rozwiązywanie problemów != klepanie kodu.

Ciekawe problemy notuj sobie na boku, zadawaj do nich pytania, wracaj do tego regularnie, bo wraz z rozwojem zmienia się trochę perspektywa. Czasem niewielka zmiana, nowa infromacja jaka pozyskasz może sprawić, że podejdziesz do problemu w zupełnie inny sposób niż pierwotnie zakładałeś.

Chodzi o książki czy arty znanych pro / publicystów programistów ?

Nie wiem. Ja czytam wszystko co mnie ciekawi i co w jakimś stopniu nawiązuje do problemów /pytań z moich projektów.

Ale zastanawiałem się jak takie publiczne apki, wypuszczone od profesjonalnych devów wyglądają.

Pamiętaj, że kontekst jest ważny.

Profesjonalne apki działające na produkcji (te, które zobaczysz w firmach) z definicji będą miały dużo chaosu w sobie, bo będą wymęczone przez zmieniające się wymagania i długą listę ficzerów. Miejscami kod będzie ładny, miejscami brzydki, ale będzie na pewno chaos i tajemnice. Bo tak ma być, a historii tego kodu i tak byś nie zrozumiał. Ale działa? Działa.

Apki z tutorialów z kolei będą wyglądać inaczej i tu też zależy, jaki tutorial weźmiesz, ale zwykle autorzy albo przesadzają w jedną albo w drugą stronę. Albo autor próbuje "ogłupiać" kod i w tutorialu jest bardzo doraźny i nieskalowalny kod, coś, co dobre jest do tutoriala, a nie do poważnej aplikacji. Albo niektórzy autorzy tutorialów próbują na siłę być mądrzy i proste apki są napikowane niepotrzebnymi wzorcami.

Jeszcze inna kategoria to używane przez tysiące osób biblioteki open source. Trzeba wtedy brać poprawki, że autorzy takich bibliotek muszą myśleć o tym, żeby różni użytkownicy biblioteki byli zadowoleni (co skutkuje większym skomplikowaniem, bo taką bibliotekę użytkownicy będą chcieli skonfigurować, będą chcieli, żeby im działała w jakimś nietypowym use case'ie itp. itd.). Czyli popularne biblioteki open source z natury będą bardziej skomplikowane niż rozwiązanie, które byś napisał tylko dla siebie.
(no i w długo utrzymywanych projektach open source również będzie dużo chaosu).

Czy uzyć listenera i eventdelegation. To taki przykład bo na początku wydawało mi się, że nauczę się kiedy - i co używać. Ale widzę że to tak nie działa.

Lepiej zaakceptować, że będzie się ignorantem w wielu sprawach, a dopiero potem się stopniowo douczać. A eventy akurat to śliska sprawa i to temat bardziej skomplikowany niż tylko dylemat listener vs delegation, szczególnie biorąc pod uwagę różnice między przeglądarkami czy urządzeniami. Czy nawet biorąc pod uwagę, że to się ciągle zmienia, pewne rzeczy stają się przestarzałe (np. pewne właściwości eventów), więc też trzeba to śledzić.

Polecam wstawić apkę tutaj: https://4programmers.net/Forum/Oceny_i_recenzje i przeczytać otrzymany feedback

@Tyvrel: Poprawię jeszcze co się da, bo wstyd... i wrzucę.

Dobry wieczór :)
Dziękuję wszystkim za odpowiedzi z końca kwietnia. Może jak napiszę tutaj to dostanę odpowiedź.
Nie chciałbym wyjść na męcybułe szukającego złotego środka. Zrobiłem jakiś tam krok w przód. Tzn napisałem a raczej przepisałem 2 apki. I zrobiłem jedną z api, i statem z którym miałem problem.
Powtórzyłem to co pisaliście wyżej, umiem robić bundla z parcela, jakiś prosty skrypt z dokumentacji. Podstawy npma. Zrobiłem gita i codziennie comituje na brancha ćwiczac.

Poruszyłem ostatnio temat MVC i zrobiłem apkę w oparciu o ten model, ale na klasach. Spodobało mi się to bo kiedyś pisałem w javie lata temu jakieś "pierdoły"
Doczytałem że ten paradygmat programowania raczej rzadko się stosuje ze wzgledu na to że klasy w js są takie trochę pseudo.

I teraz do sedna. Programowanie funkcyjne - jak sie go uczyć. Wiem że do nauki znowu podchodze książkowo.
Czy w małych projektach jest sens trzymania się własnie tej metody ? Czy jest sens się w ogóle go uczyć - tak typowo, rozwiązując jakieś proste zadania ?

Pytam bo zastanawiłem się aby powoli przechodzić na react. Czy jest w ogóle już na to czas. A to ze względu na to że komercyjne projekty w jsie, z valid formem - chodzi mi o jakieś strony firmowe.
To za mało żeby się gdzieś dostać. W międzyczasie pewnie coś takiego zrobię, ale chodzi mi o ten kamień milowy.

Czy np lepiej spróbować przepisać kod teraz na funkcyjne rozwiązanie.
Ta na klasach w jsie pobierała przepisy kulinarne, a także wysyłała na serwer, byl valid form, + typowy CRUD + sortowanie listy. Dodatkowo kilka zapytań api z array metods, bardziej szczegółowych. Dodawanie do ulubionych, liczenie składników zależnie od ilości osób - takie pierdoły.

Strasznie fajnie mi się to na klasach pisało, ale teraz w oparciu o funkcyjne rozwiązanie wydaje mi się że miałbym problem z tym jak sobie to w głowie poukładać.

Rady dostałem tego typu:

• nie stawiaj na razie na styl
• weź się za typescript i później react, albo na równi
• ucz sie testów

I ostatnie chyba najważniejsze: ogarnij jeszce jakiś projekt ucz się reacta z jakimś stackiem i wal na jakiś projekt open, albo rób cos większego z kimś.
Nie wiem czy te rady znajomego są godne uwagi, ale od większości osób słyszę że za stronę firmową mnie nie przyjmą do pracy.
Na razie jestem sfocusowany na jakieś zdobywnie wiedzy myślę z rok - dwa dlatego te moje pytania.

Z tym mvc o którym wspomniałem wcześniej i klasach trochę zabrnąłem ale sporo sie nauczyłem - nie sądzę żebym zmarnował wtedy czas.

Dodam jeszcze jedną rzecz. To podejście deklaratywne jest dla mnie cięzkie. Tzn mam problem z wydzieleniem logiki a raczej się jej pozbyciem.