- Ustal priorytety np. 1) struktury danych i algorytmy, 2) programowanie obiektowe, 3) LINQ, 4) bazy danych, 5) grafika/refleksja/serializacja...
przykładowo jeśli nie umiesz wystarczająco dobrze i nie stosujesz swobodnie programowania obiektowego to nie zaczynaj nauki baz
danych, czy refleksji, bo wszystko ci się pochrzani
Sztywne podejście. Po prostu dobieraj narzędzia do projektu. By działać nad projektem dajmy na to do 10LOC bardzo często nie potrzebujesz wiedzy specjalistycznej. Wystarczy, że zaczniesz badać wybrany temat gdy napotkasz jakiś większy problem. Poza tym Twoja pierwsza wersja projektu nie musi być idealna, jak będziesz z czasem poprawiać błędy to też będzie git.
2 ) konsultuj pomysły/projekty. Jeśli zrobisz jakiś projekt koniecznie daj go do sprawdzenia komuś bardziej doświadczonemu a z pewnością wytknie ci mnóstwo błędów np brak refaktoryzacji, wzorców projektowych, nieużywanie bloku try and catch, zasady SOLID itp
Sęk w tym, że te błędy czasem nic nie znaczą. Osoba, która sprawdza Twój projekt opiera się na pewnym zbiorze zasad do przestrzegania. Jesli zapytasz osobę, która rzeźbi bardzo duży system, to pewnie powie Ci, że nie masz tego czy tego wzorca (albo powie, że masz niewydajne zapytanie itp), a jak zapytasz kogoś kto pisze mniejsze aplikacje to ten powie Ci, że już strasznie komplikujesz (i że Twój problem to nawet bez bazy da się rozwiązać). I kto ma wtedy rację?
Na początku dużo eksperymentuj i niech Twoim sędzią będą Twoje doświadczenia z systemem. Przykładowo jeśli dostajesz wiele zgłoszeń o błędach to może dlatego, że nie masz testów. Jak wybrane testy ciężko dodać to może dlatego, że w pewnym miejscu przydałby się bardziej ogólny styl. Ale to nie znaczy, że od razu musisz wszystko ogólnie pisać. I to samo co do narzędzi. Jak apka wolno chodzi, to pierw zrozum dlaczego i jeśli faktycznie zapytanie będzie wolne to poducz się tematu, zbadaj z czego wynika i popraw.
Jako żółtodziub nie masz doświadczenia, a wszelkie rady i tak możesz źle zinterpretować. Jak chcesz mieć doświadczenie zbudowne poprzez rozwiązywanie problemów to reaguj na problemy - nie twórz ich z góry sam sobie.
- stawiaj sobie realne cele i uparcie do nich dąż, np jeśli uczysz się asp.net mvc to pierwszy projekt niech będzie dość prosty, tak żebyś bezstresowo go zrobił np. jakaś aplikacja do podliczenia rachunków, opłat, (wypełnienie prostych formularzy), potem nieco trudniejsza np strona internetowa z danymi wyświetlanymi z bazy, a potem jeszcze trudniejsza np sklep, forum itp
Trochę tak, ale w takim przypadku nie robisz projektu tylko uczysz się asp.net W normalnej sytuacji byłoby odwrotnie. Piszesz projekt, który jest ważny dla Ciebie i najpierw dobierasz jak najprostsze narzędzia, a jak sytuacja tego wymaga to podkręcasz swój warsztat.
- selekcja informacji. Nie kupuj/pobieraj pierwszej lepszej książki, tylko sprawdz jej spis treści, opinie, porównaj z innymi. Najlepiej kupuj dość tanią i skondensowaną treść,
- nie czytaj książek od deski do deski. Jeśli robisz jakiś projekt i potrzebujesz bardziej szczegółowo wiedzieć o czymś to doczytaj o tym np w ksiażkach czy dokumentacji. Czytaj o czymś jeśli akurat tego potrzebujesz, a nie na zapas.
Jeśli punkty 4 i 5 dotyczą dajmy na to książek o obsłudze frameworka to prawdopodobnie masz rację, ale tylko wtedy. Zacznij czytać więcej klasyki :-)