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
spartanPAGE
warning: kodzenie może powodować błędy
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
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.
przeczytałem na próbę jeden artykuł i zapewne przeczytam kolejne :).
- Rejestracja:ponad 17 lat
- Ostatnio:ponad 2 lata
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ą.
no tak po inżyniersku to chyba na końcu należy testować. Trzeba mieć dobry team ludzi którzy już wiedzą co i jak to wtedy pisanie testu na początku jest rozsądne. Tak jak połowa sie uczy, połowa jest przerzucona z innych technologi to tylko dysonanse wyjdą i niepotrzebnie stracony czas. Ale to tylko moje zdanie z podwórka na którym ja się bawię:)
No tak po inżyniersku, ale inżynieria oprogramowania ma niewiele wspólnego z inżynierią. TS pozwala na "dogadanie" API takiego jakie jest rzeczywiście potrzebne.
- Rejestracja:około 12 lat
- Ostatnio:około 3 lata
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.