Pytanie jak w temacie - jak przyswoić sobie dobre praktyki i nawyki programistyczne w samodzielnej nauce? Jestem na etapie że poznałem podstawy Pythona (i ostatnio zacząłem rozkminiać C++). Korzystając z SO/4programmers udaje mi się napisać działające (i to zgodnie z oczekiwaniami ;) ) skrypty. Mam radochę że to działa, ale podejrzewam że napisane jest to od d**y strony, a gdyby taki kod zobaczył profesjonalny programista to miałby niezłą bekę. Czyli potrafię coś napisać, ale chciałbym teraz wejść na poziom - napisać to dobrze ;)
Jak doskonaliliście Wasze umiejętności w samodzielnej nauce programowania?
- Rejestracja:około 8 lat
- Ostatnio:prawie 5 lat
- Postów:27
0
- Rejestracja:ponad 11 lat
- Ostatnio:ponad 4 lata
- Postów:2442
0
Wrzuć tutaj ten kod i pochwal się. Jest tutaj trochę kompetentnych osób, które z miejsca Cię naprowadzą na odpowiedni tok myślenia. Serio, serio.
Zwłaszcza, że dopiero zaczynasz więc będzie najprościej, bo najprawdopodobniej nie robisz kodu dla NASA.
edytowany 1x, ostatnio: grzesiek51114
- Rejestracja:ponad 6 lat
- Ostatnio:około 15 godzin
- Lokalizacja:Warszawa
- Postów:41
- Rejestracja:ponad 17 lat
- Ostatnio:27 minut
- Lokalizacja:Warszawa
- Postów:2251
1
Tak jak pisał @grzesiek51114 wrzucaj kod i UWAGA - nie bój się tego, że ktoś zjedzie Twój kod od A do Z. Wiem z doświadczenia że pierwszy code-review może być nieprzyjemny, zwłaszcza gdy robią go ludzie ze sporym doświadczeniem.
edytowany 1x, ostatnio: axelbest
- Rejestracja:około 11 lat
- Ostatnio:3 minuty
- Postów:8399
8
Pytanie jak w temacie - jak przyswoić sobie dobre praktyki i nawyki programistyczne w samodzielnej nauce?
Pisz większe projekty
Wtedy sam odkryjesz, że choćby pisanie metodą copy-paste jest nieskalowalne, że pisanie magic numbers utrudnia utrzymywanie itp.
Ew. jakbyś sam tego nie odkrył, to przeczytasz to w jakiejś książce. Tylko, że samo czytanie książek nie wystarczy, bo ty musisz rozumieć, o czym dany autor pisze, a do tego trzeba trochę własnych doświadczeń. Więc jednak warto pisać większe projekty (samemu albo w zespole)
Pisz projekty przez dłuższy czas
Pisanie projektu przez dłuższy czas także nauczy cię tego, że wszystko może się spieprzyć i zrozumiesz, dlaczego trzeba robić backupy. A jak będziesz miał kupę folderów z backupami typu moj_projekt_4_pazdziernika_2018, to zrozumiesz dlaczego warto korzystać z Gita.
Pisanie większego projektu przez dłuższy czas także pozwoli ci zrozumieć ideę pisania testów automatycznych (bo one pozwalają wykryć z automatu, czy czegoś nie zje*ałeś, a sprawdzanie tego ręcznie trwało by długo
Pisz projekty z ambitnymi i zmieniającymi się wymaganiami.
Np. dla kapryśnego klienta. Jeśli nie masz klienta, to sam sobie stawiaj wymagania "biznesowe" i je realizuj. Potem kombinuj, zmieniaj w trakcie. Pisząc samemu wyobraź sobie, że oprócz bycia programistą, jesteś jednocześnie swoim własnym klientem/docelowym użytkownikiem (który chce mieć ładny produkt, niezależnie od tego, czy to jest trudne czy łatwe dla programisty).
Bądź leniwy
Lenistwo to zaleta programisty. Np. załóżmy, że zrobiłeś grę w węża. Zrobiłeś planszę, sposób wyświetlania kwadracików, sposób wyświetlania menu, ruch węża itp.
I potem nagle cię najdzie, że chcesz zrobić grę w statki. I teraz tak - albo możesz ją zrobić całkowicie od początku, albo wykorzystać część kodu z poprzedniej gry (np. samą planszę, czy sposób wyświetlania kwadracików).
I teraz tak - jeśli napisałeś brzydko węża, to może się okazać, że nie da się wykorzystać istniejącego kodu do kolejnej gry (bo np. będzie duży coupling modułów, dużo ukrytych założeń, słaba separacja modułów itp.). Więc jesteś w dupie i masz teraz więcej roboty, bo musisz pisać wszystko od nowa.
Natomiast dobrze ukierowane lenistwo będzie cię motywować do tego, żeby pisać taki kod, który łatwo potem można użyć w kolejnych projektach.
Najlepiej cały czas kombinować, jak zrobić, żeby się nie narobić, to wtedy wejdą ci łatwo do głowy zasady DRY, YAGNI czy KISS (swoją drogą czasem bardziej KISS jest użyć copy-paste i złamać zasadę DRY https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction ).
edytowany 3x, ostatnio: LukeJL