[Java] Czego uczyć się dalej? Etapy nauki.

0

Trochę historii:
Najpierw wystartowałem z książką i kilkoma kursami – czytanymi i oglądanymi. Leciałem przez nie pobieżnie + coś tam pisałem. Efekty takiego stylu nauki były marne – elementarne błędy, w dodatku popełniane co jakiś czas (bo już wyleciało z głowy).
Wedle zasady „zbudowania silnych podstaw, które będą procentowały w przyszłości” wróciłem do początku. Planem nauki (kolejnością przerabiania) uczyniłem spis treści Java Podstawy wyd. 10 Horstmanna. Przerabiałem szczegółowo każdy temat i opracowywałem karty-notatki (skondensowana wiedza). Poza tą książką korzystałem z jsystem blog, javastart, kanałów Coraxa, kakaboc i Andrzej R (te 2 ostatnie mało popularne, ale polecam) + inne na różnych etapach.

Przyświecała mi myśl: najpierw poznam składnię i podstawowe mechanizmy, i wtedy wrócę do pisania. Zajęło to o wiele więcej czasu niż się spodziewałem.
Jestem na etapie: 5 rozdział - dziedziczeniem i polimorfizm za mną.
I tu przyszła refleksja, że najwyższa pora wrócić do pisania.

Pytania:

  1. Czego uczyć się dalej?
    Wiem, że: pisać – opanować w praktyce to co poznałem po dużej części w teorii.
    Ale co z nowych tematów opanować jak najszybciej? Z czym zapoznać się, a co dokładnie zgłębić? Kierując się tytułem książki Horstmanna to zostało drugie tyle rozdziałów. Patrząc na inne kursy to one jedynie liznęły kolejne rozdziały.

  2. Jaki kolejne etapy rozwoju? Jakie technologie? Frameworki?
    W dziedzinach:

  • aplikacje internetowe
    JEE?
  • back-end
    Czy tu w ogóle sama java może wystarczyć i we współpracy z programistą języka front-endu można postawić stronę www?
  • gry i aplikacje mobilne
    Co do gier wiem, że są silniki np. LibGDX, w których programuje się w javie.
    A co z aplikacjami? Czytałem, że Java, a Java for Android to różne bajki. Gdzie to się rozjeżdża?
3
rżwirek napisał(a):

Jestem na etapie: 5 rozdział - dziedziczeniem i polimorfizm za mną.
I tu przyszła refleksja, że najwyższa pora wrócić do pisania.
...

  1. Czego uczyć się dalej?
    Wiem, że: pisać – opanować w praktyce to co poznałem po dużej części w teorii.
    Ale co z nowych tematów opanować jak najszybciej?

Sam w zasadzie bardzo dobrze sobie odpowiedziałeś na pytanie. Po prostu pisać pisać i pisać. Każdy z nas może Ci tu sypnąć listą frameworków i tooli z których się aktualnie korzysta ale jaki to ma sens skoro jesteś na podstawch podstaw? Ja bym na Twoim miejscu zaczął od algorytmów. Nie ma znaczenia co tam będziesz kodował, sortowania bąbelkowe, quicksorty czy inne sita na kilka różnych sposobów. Chodzi o to abyś nauczył się samodzielnie rozwiązywać problemy, projektować jakieś rozwiązania mając na wejściu określone dane. Bardzo wiele osób które dopiero zaczynają naukę z programowaniem powtarzają w kółko "wiem co trzeba zrobić ale nie wiem jak to zrobić". Dopóki nie pokaże się krok po kroku jak coś zrobić to sobie nie radzą. Chodzi więc o to abyś sam potrafił nawet akiego bubble sorta sobie na kartce rozpisać w jakieś bloki albo pseudokod i implementować to bez żadnych problemów. Nie chodzi tu o wymyślanie koła na nowo ale o nauczenie się sposobu myślenia i radzenia z podstawowymi problemami.

Potem proponuję wziąć się za implementację wszystkich przewałkowanych na sto różnych sposobów tematów czyli księgarnie, kwiaciarnie czy inne banki. Bez żadnych baz danych ale na jakichś ciekawszych kolekcjach a nie tylko lista. Do tego trochę wyjątków itp. Wiele osób które zaczynają mówi że to takie banalne i szkoda im czasu a potem jak trzeba zrobić jakąś prostą apkę banku która ma generować numery kont, jakieś karty kredytowe, przelewy, pełna historia wszystkich operacji itd to okazuje się że nie wiadomo jak się za to zabrać...
Nie chodzi o to żeby to było idealne odwzorowanie rzeczywistych systemów ale o to żeby pisać proste programy i na ich podstawie uczyć się już prostej architektury żeby sensownie dzielić aplikację a nie walić wszędzie gdzie popadnie println albo robić z kodu jakąś lasagne.
Przy okazji warto też podszkolić się z testów i pisać je sensownie korzystając z np. JUnita, AssertJa, Mockito itp żeby potem wstydu nie było że masz kilka lat doświadczenia a różnicy między mockiem a stubem nie widzisz.

Do tego dorzuciłbym kilka prostych wzorców projektowych: Budowniczy, fabryka, strategia itp.
Dopiero potem w ogóle jest sens myśleć nad przejściem dalej. Dorzuć sobie jakieś proste bazy danych. Zrób to na JDBC i sam z palca napisz trochę zapytań żebyś wiedział że hibernate nie jest czarodziejem który magicznie robi operacje na bazach tylko tam latają "normalne" SQLe... Niestety wiele osób już tak pochłonęło się Hibernatem czy nawet teraz Spring data że jak mają coś z palca napisać to jest tylko "wtf? Tego nie było."
Jak zrobisz sobie tego JDBC to wrzuć właśnie jakiś framework, może być nawet Hibernate ale będziesz już rozumiał co i jak działa. A potem możesz śmigać dalej, jakieś Springi czy inne wynalazki choć póki co na etapie abstrakcji w której jesteś bym sobie tym w ogóle główy nie zajmował.

0

eL dziękuję za odpowiedź.
Podsumowanie:
Pisać, stopniowo poszerzając wiedzę.

  1. Tematy dalej z „Podstaw” Horstmanna:

rozdz. 6. interfejsy, wyrażenia lambda i klasy wewnętrzne
rozdz. 7. wyjątki, asercje i dzienniki
rozdz. 8. programowanie generyczne
rozdz. 9. kolekcje
rozdz. 14. współbieżność

  1. Algorytmy.
    Wykraczając poza to co Horstmnn opisał w rozdziale 9 :).
  2. Budowa prostych aplikacji
eL napisał(a):

Potem proponuję wziąć się za implementację wszystkich przewałkowanych na sto różnych sposobów tematów czyli księgarnie, kwiaciarnie czy inne banki.

  1. Testy jednostkowe.
  2. Wzorce projektowe, podstawy.
  3. Podstawy bazy danych.

I dopiero myśleć o frameworkach, o konkretach: aplikacje internetowe czy gry i aplikacje mobilne. A o pracy, jeszcze daleko potem :).

Ktoś by coś dodał? Ma inna opinię, w którymś punkcie?

1

Przerabiałem szczegółowo każdy temat i opracowywałem karty-notatki (skondensowana wiedza).

Ten czas mógłbyś spożytkować na kodzeniu.

Przyświecała mi myśl: najpierw poznam składnię i podstawowe mechanizmy, i wtedy wrócę do pisania.
Zajęło to o wiele więcej czasu niż się spodziewałem.

Jak chcesz poznać składnię, jeśli nie będziesz pisać? Składnia to coś, co ma siedzieć w twojej głowie i w palcach, coś, co od razu będziesz umiał dostrzec jak zobaczysz i coś, co jesteś w stanie napisać z automatu.

Inaczej będziesz się godzinę zastanawiał nad tym, czy napisać nawias po if czy nie. Albo nad sensem błędu, który ci zgłasza kompilator.

I dopiero myśleć o frameworkach, o konkretach: aplikacje internetowe czy gry i aplikacje mobilne.

O konkretach powinno się myśleć jak najszybciej. Mierząc siły na zamiary. Jak aplikacja internetowa to prosta (a nie "drugi Facebook"), jak gra to prędzej memory niż klon GTA, a aplikacja mobilna to prędzej kalkulator niż Uber.

Nauka na sucho nie ma wiele sensu, bo:

  • i tak nie spamiętasz tego, co przeczytasz, wylecą ci z głowy najważniejsze fakty
  • twoje praktyczne umiejętności rozwiązywania problemów się nie polepszą. A prawdziwe programowanie potrafi mocno zaskakiwać i nasuwać dziwne problemy, z którymi musisz sobie jakoś poradzić. Nie programując(a tylko czytając), nie będziesz miał tych problemów, więc nie będziesz mógł trenować ich rozwiązywania.
  • niewiele zrozumiesz, w książkach może być niejasno coś opisane, a nawet jak jest jasno napisane, to jest duża szansa, że będzie to uproszczony naiwny obraz programowania specjalnie przygotowany pod początkujących.

Jestem na etapie: 5 rozdział - dziedziczeniem i polimorfizm za mną.
I tu przyszła refleksja, że najwyższa pora wrócić do pisania.

Np. mogą ci klepać do głowy historie o zwierzątkach, które dają głos (hau, miau) w zależności od klasy. Nie ma nic złego w takim przykładzie na początek (bo zwierzęta są fajne), ale mimo wszystko programując rzadko będziesz używać dziedziczenia (a raczej: na początek pewnie będziesz używać często, ale z nabywaniem doświadczenia coraz rzadziej, bo zobaczysz jego wady oraz to, że możesz osiągnąć co chcesz innymi sposobami).

W książkach również popadają w drugą skrajność - przykłady żywcem wzięte z wielkich aplikacji enterprise, gdzie miałbyś dziedziczenie czy inne wzorce projektowe wyjaśnione na kontach bankowych. To też nie ma wiele sensu, bo i tak nie będziesz pisać kodu do kont bankowych w najbliższym czasie, a jakbyś pisał to i tak nie tak jak w książce.

Dlatego nie ma co się zagłębiać w naiwne przykłady z książki, tylko trzeba samemu to przetestować na wymyślonych przez siebie przykładach, które faktycznie będą robiły coś konkretnego. Np. pisząc klasy do gry memory albo do prostej aplikacji.

1 użytkowników online, w tym zalogowanych: 0, gości: 1