Witam
Mam pewien dylemat, od paru lat piszę w javie czy to na studiach czy teraz w pracy ale czuje że średnio ją umiem. Piszę różny kod ładny i brzydki ale często mnie język zaskakuje. Macie jakieś porady jak stać się lepszym. Jak lepiej poznać język nauczyć, wpoić sobie pewne dobre zasady i pracować z nim płynnie bez sytuacji że na wątkach traci się tydzien a chodzi to i tak że ...
0
1
Moja pomoc to: praktyka, praktyia i praktyka.
Do tego jeszcze jakaś książka, na temat wzroców i stosowania ich w kodzie.
3
@Mateusz321 najlepiej pisać kod ale jedncześnie mieć też code-review. Tzn ktoś na ten twój kod patrzy i rzuca WTFami.
3
Trochę będę korzystał z linków do własnego bloga, ale mam tam to uporządkowane.
Na początek zacznij stosować zasady DRY i KISS na co dzień. Obie są na tyle proste, i mają wsparcie w narzędziach, że nie powinieneś mieć problemu.
Kolejna rzecz to zasada SOLID > http://koziolekweb.pl/category/inzynieria-oprogramowania/solidne-programowanie/ poprawia kod.
Następnie pamiętaj o pisaniu testów. Wiem, że to uciążliwe gdy deadline goni, ale testy zazwyczaj pozwalają nie tylko na wyszukanie potencjalnych bugów, ale też dzięki nim możesz sprawdzić jak twój kod będzie "się używał". Jeżeli coś jest ciężko przetestować to oznacza, że i użycie będzie przysparzać problemów.
Kolejna sprawa to http://koziolekweb.pl/tag/ekstremalna-obiektowosc-w-praktyce/ poczytaj. To stare teksty, ale nadal aktualne. Nie trzeba się ściśle trzymać tych zasad lecz ich stosowanie znacząco ułatwia pisanie dobrego kodu.
@Madaoo wspominał o książkach. Ja powiem tylko o jednej http://koziolekweb.pl/2008/11/07/zrozumiec_tao/ . Książka, jak książka. Pozwala jednak zrozumieć jak działają wzorce obiektowe i kiedy nie należy ich stosować. To, wbrew pozorom, bardzo ważna rzecz, dzięki której można pisać lepszy kod.
Najważniejsze - praktyka. Najlepiej praktykuje się na projektach OSS. Zatem postaraj się tworzyć kod w oparciu o ww. zasady i udostępniać go szerszej publiczności.
1
Ja myślę, że samo pisanie testów nie jest tak ważne, jak to by przestać pisać kod, którego nie można przetestować. Jest wiele pozycji w necie na ten temat. I nie dziwi fakt że kod taki który jest lepiej napisany pod względem możliwości pisania testów jednostkowych jest czytelniejszy i po prostu lepszy.
1
@lipkerson, tyle tylko, że pisanie kodu, który łatwo się testuje jest najprostsze gdy piszesz testy. Widać wtedy jak na dłoni czy rozwiązanie jest OK czy NOK. Tu wchodzi kolejna sprawa test-first czy test-last? IMO test-first pomaga pisać dobry kod, a przy wsparciu narzędzi do refaktoryzacji pozwala na eleganckie rozwijanie kodu z poziomu bardzo prostego i pokrywającego tylko najprostsze wymaganie do bardziej złożonego i zgodnego z pełną specyfikacją.
0
Bardzo Wam dziękuję za wszystkie informacje. Dziś pewnie poczytam trochę bloga. A co możecie powiedzieć na sytuacje gdy ktoś chce się uczyć dobrze programować i pogłębiać samą wiedzę na temat języka głownie chodzi o Jave.
1
Pisz OSSy. Cokolwiek co ma ręce i nogi będzie dobre. Poszukaj sobie tematu i napisz apkę, która będzie miała kod na np. githubie. Daj ją na forum do oceny i DYSKUTUJ o zastosowanych rozwiązaniach.
1
Nie wiem, czy tak jest w istocie, ale myślę, że w programowaniu bardzo cenny jest wręcz paranoiczny perfekcjonizm idący w parze z wyczulonym zmysłem estetycznym. Bowiem prócz wielkiego brata spoglądającego na monitor przez nasze ramię i rzucającego ładefakami w sytuacji dostrzeżenia wypisanych przez nas różnorakich bzdur, to jednak nic nie zastąpi wewnętrznego irytującego głosiku szepczącego, że "twój kod nie wygląda tak, jak wyglądać powinien kolego... nie wiem co zrobiłeś nie tak, ale radziłbym ci poszukać w necie informacji dotyczących stosowania tego rozwiązania/funkcji/itd bo pachnie mi tu fuszerką". Na pewnych etapach rozwoju wiadomo, że należy kontrolować ów perfekcjonistyczny zapęd i za każdym razem iść na kompromis z samym sobą w celu akceptacji rozwiązań "dających radę i mieszczących się w pewnych grupowych standardach", jednak wyrobienie w sobie poczucia dobrego smaku i wyżej wspomnianego zmysłu estetycznego moim zdaniem jest bardzo istotną kwestią. Tak jak z grą na pianinie, tak i przy pisaniu książki, tak i przy kodzeniu po prostu "czuje się", że zastosowane rozwiązanie, czy forma w jakiej ujęliśmy jakąś funkcję jest brzydka, nieodpowiednia, nieelegancka, za długa, przestarzałą, niepoprawna itd itd.