W tym vlogu opowiadam o moim zdaniem trzech najważniejszych rzeczach, które pomogą Ci w rozwoju. I co ważniejsze będą ten rozwój wspierać przez długie lata twojej kariery. Nie ważne, na jakim etapie jesteś, to wprowadzenie właśnie tych trzech rzeczy pomoże Ci zrobić kolejny krok, żeby stać się dobrym programistą.
Poniżej znajdziesz link do playlisty z vlogiem:
Vlog w wersji Audio:
Inne platformy podcastowe:
https://open.spotify.com/show/5HQFAJg0N4o9mDEze8WVvi?si=cc72277bbd834760
https://podcasts.apple.com/us/podcast/vlog-programistyczny/id1606703834
https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy83ZDk2ZjEwNC9wb2RjYXN0L3Jzcw
https://castbox.fm/channel/Vlog-Programistyczny-id4743197?country=us
https://podcastaddict.com/podcast/3783474
Transkrypcja:
[Intro]
Tak naprawdę są tylko trzy rzeczy, które zawsze wspierają rozwój programisty i nieważne, czy dopiero zaczynasz swoją pierwszą pracę, czy masz już 5, czy 10 lat doświadczenia te trzy rzeczy nigdy się nie zmieniają
[/Intro]
Cześć witam Cię w kolejnym vlogu na moim kanale, ja nazywam się Mateusz Dąbrowski. Zanim jeszcze zaczniemy, krótkie ogłoszenie. W poniedziałek ukazał się kolejny z serii warsztatów o architekturach aplikacji.
Jest to warsztat o architekturze heksagonalnej i serdecznie do niego zapraszam. Link oczywiście do tego warsztatu znajdziesz w opisie do tego odcinka. Architektura Heksagonalna.
A w tym vlogu porozmawiamy sobie o trzech takich naprawdę bardzo istotnych rzeczach w rozwoju programisty i są to rzeczy, które naprawdę wspomagają bardzo bardzo rozwój programisty na każdym etapie jego kariery.
I pierwszą z tych rzeczy jest „Clean Code”. Clean code wziął się od nazwy książki Roberta C. Martina też nazywanego „Wujkiem Bobem”, o takim samym tytule, czyli „Clean Code”, czyli po prostu „Czysty kod”.
Książka ta opisuje różne techniki, różne podejście do kodu, to co powinniśmy robić, to czego nie powinniśmy robić jest ona bardzo pomocna, w tak jakby ogarnięciu swojego kodu i sama książka może nie jest strikte dla początkujących, ale każdy programista, czy to Javy, czy innego języka powinien do tej książki zajrzeć przynajmniej raz albo zaglądać do niej co jakiś czas.
Sama książka to tylko tak jakby część tego clean coda trzeba to przede wszystkim zastosować w praktyce.
Czyli zaczynając od znaczących nazw, poprzez odpowiednie komentowanie bądź niekomentowanie kodu. Poprzez takie techniki jak to, że jedna metoda, czy jedna klasa powinna robić tak jakby jedną rzecz i wiele wiele innych rzeczy, któe jest w tym zawarte i sam clean code jako taki pomaga bardzo spojrzeć inaczej na kod, który tworzymy
Gdy zaczynamy sie uczyć kodowania, to po prostu chcemy zrobić cos w ogóle, żeby zadziałało i to jest nasz pierwszy cel w kodowaniu tak jakby zrobić jakąś funkcjonalność, która będzie działać, później, jak już umiemy coś zrobić, że działa, staramy się robić nowe rzeczy, nie skupiając się na tym jak to robimy, natomiast cały clean code, jest to tak jakby podejście do tego jak robimy pewne rzeczy.
I im robimy te rzeczy lepiej, tym później mamy mniej problemów z naszym kodem przykładem niech tu będą znaczące nazwy, czyli drugi rozdział clean code i znaczące nazwy tak naprawdę odnoszą się do wszystkiego co piszecie w swoim kodzie to nie tylko metody, ale także to jak nazywacie pliki, pliki konfiguracyjne, czy cokolwiek innego.
Wszystko musi mieć jakieś znaczenie, czy to metoda klasa, czy pakiet, musi się odpowiednio nazywać. Jeśli nie nazywa się odpowiednio, to po jakimś czasie, gdy wracacie do tego kodu, zaczynacie się zastanawiać, po co to zostało zrobione, dlaczego to zostało tak zrobione i co to przede wszystkim robi.
Z clean code i podejściem takim, że nadajecie znaczące nazwy wszystkim elementom, których używacie, to wszystko staje się o wiele prostsze. Wtedy wracacie po jakimś czasie do kodu i widzicie, że ten kod pobiera np. produkty, albo pobiera zamówienia, albo robi coś innego, albo dodaje.
I czytając tylko same nazwy metod, nazwy klas, jesteście w stanie, od razu wiedzieć co się dzieje. Nie musicie zaglądać w kod, nie musicie analizować całego przepływu kodu, czyli klasa po klasie, metoda po metodzie.
Wystarczy, że patrzycie na jedną metodę, albo raczej na jej nazwę i już wiecie co to robi. I też spotkałem się z takim podejściem, że kod powinien być tak napisany, żeby czytał się tak jak dobra książka, żeby nie trzeba było zastanawiać się co to oznacza, tylko po prostu czytasz dana metodę, czytasz daną linijkę kodu i już wiesz.
Także to się odnosi do komentowania, że nie komentujesz niepotrzebnie, po prostu twój kod, nazwy w twoim kodzie, metody powinny mówić same za siebie bez konieczności komentowania co to robi.
Jeśli chcesz dodawać komentarze,to wtedy dodajesz komentarz tylko po to, żeby zaznaczyć, dlaczego to jest tak zrobione, a nie co to robi.
I takie podejście do kodowania do tego jak robimy nasz kod, sprawia, że proprostu pracuje się nam łatwiej i lepiej.
Przez co też możemy się jakoś rozwijać, możemy poprawiać cały czas to, co robimy, mając tę świadomości, jak powinniśmy pewne rzeczy robić.
Druga z tych bardzo istotnych, rzeczy to testy. Testy automatyczne, testy jednostkowe, testy integracyjne, czy nawet testy end-to-end. I tutaj, tak jakby najwięcej piszemy zawsze testów jednostkowych.
Jeśli zaczynasz kodować, to też nie zaczynasz od pisania testów, tylko starasz się tak jakby coś zbudować. Najpierw zrobić jakiś mały program, który będzie działał. Nie myślisz o tym, że trzeb pisać jakieś testy, bo w ogóle na początku nie wiesz, że istnieje coś takiego jak testy jednostkowe. Dopiero w pewnym momencie jak ktoś Ci powie, albo gdzieś przeczytasz, że trzeba przetestować kod
jednostkowo, to wtedy zastanawiasz się jak to zrobić.
I tutaj jest właśnie ten problem, że gdy piszesz kod, zanim nauczysz się testów, to ten kod jest taki dosyć bałaganiarski, dosyć rozwlekły. Często też zawiera konstrukcje, które uniemożliwiają testowanie testami automatycznymi, więc tutaj też przychodzi ta wielka zmiana, że nagle zaczynasz pisać i nagle twój kod, musi zacząć wyglądać inaczej.
Wtedy właśnie zaczynasz pracować sam na tym kodem, żeby on wyglądał tak, żeby można go było przede wszystkim przetestować.
Później widzisz już, że pewne rzeczy są zbędne, że pewnych rzeczy po prostu nie powinieneś dodawać. I przez to, przez testy automatyczne, też zaczynasz się rozwijać
I testy wspomagają też developera na każdym etapie rozwoju, nie ważne, czy będziesz miał rok doświadczenia, czy 5, czy 10, to zawsze testami możesz wszystko otestować, zawsze możesz wyłapać błędy.
Przede wszystkim testy jednostkowe służą temu, żeby wyłapać te najdrobniejsze i najpowszechniejsze błędy, bo dopiero jak zaczynasz je pisać, to te błędy jakoś powoli zaczynają znikać.
Dlatego pisząc ciągle testy, zawsze będziesz miał taką ochronę, że nie popełniasz najdrobniejszych błędów
Jeśli nie miałeś styczności z testami, nie wiesza jak je pisać, to zapraszam do mojego kursu o testach jednostkowych.
Link oczywiście znajdziesz w opisie. Kurs tety jednostkowe.
I ostatnią już trzecią rzeczą, która pomaga w rozwoju programisty, na każdym etapie kariery, jest code review.
I code review, to jest taka rzecz, która naprawdę może bardzo pomóc, zwłaszcza na tym początkowym etapie kariery, jeśli jesteście w teamie, gdzie robi się code review, a bardzo polecam wam szukać takich teamów, gdzie to code review się robi, gdzie są seniorzy, którzy mają już jakieś doświadczenie, potrafią zrobić, takie dobre code review i to code review zawsze będzie wam pomagać
I tak jakby, nie ma tutaj znaczenia, czy dopiero zaczynacie, czy macie 5, 10, czy nawet 15 lat doświadczenia, zawsze to code review będzie wam pomagać.
Będzie wam pomagać się rozwijać, znajdować nowe rozwiązani, nowe techniki, nowe podejścia także do problemu
To nie tylko jest tak, że w code review wyłapujemy jakieś proste błędy, często jest tak, że np. ja na code review poświęcam godzinę, dwie, trzy, a nawet czasem, ciągnie się to kilka dni, po pół godziny, po godzinie dziennie, żeby po prostu poprawić jakiś problem, który gdzieś tam ktoś zauważył. Często jest tak, że my jesteśmy tak jakby zamknięci na to, co widzimy, na to jak robimy (pewne rzeczy).
I często to spojrzenie drugiej osoby, pomaga nam spojrzeć na problem, z drugiej strony.
Np. ktoś patrzy i (pyta) Hej, dlaczego nie zrobisz tego tak, albo tak.
No i okazuje się, że tak to było w sumie oczywiste, ale przez to, że byliśmy zafiksowania na jakiś problem, na to co robimy, ewentualnie mieliśmy zły dzień i zrobiliśmy coś tak, żeby to zrobić, a okazuje się, że można to zrobić kilka razy lepiej, stosując jakąś prostą technikę, którą ktoś inny Ci podpowie na code review.
I code review to też nie tylko poprawianie błędów, to także rozmowy o kodzie. Dlaczego robimy go tak? Dlaczego może warto go zrobić lepiej? Często inne osoby, widzą po prostu, ten sam problem zupełnie inaczej, często też, można spotkać takie podejście, że każdy programista, ten sam problem rozwiązuje zupełnie na inny sposób.
I wtedy mając takie spojrzenie z boku, możemy wybrać to optymalne rozwiązanie.
Nie chcę tutaj mówić o tym, jak powinno się robić to dobre code review, bo tak jakby to jest materiał na osobny odcinek i może go kiedyś nagram, ale code review jest tym elementem, być może najważniejszym z tej trójki, który pomoże wam zawsze się rozwijać i w dodatku rozwijać się bardzo szybko, bo często nie macie świadomości pisząc sami jakieś projekty, czy robiąc coś sami, tak jakby gdzieś tam w domu wieczorami to nie macie świadomości, że pewne rzeczy można robić inaczej, pewne rzeczy można robić lepiej. I własnie code review, daje tutaj wam, to spojrzenie drugiej osoby.
I dlatego zawsze powinniście szukać teamu, gdzie to code review się robi. Gdzie to code review traktuje się bardzo poważnie, bo często też można spotkać sie z takim podejściem, że ok robimy code review, ale no dobra zaklikasz mi, zaklikam, super, fajnie jest zaklikany commit, jest zrobiona robota, wszyscy się cieszą, ale tak naprawdę code review w tym wypadku, to tylko strat czasu i tam,
gdzie traktuje się to code review poważnie tam jest rozwój, tam w projekcie łatwiej jest uniknąć pewnych problemów, zmniejsza się dług technologiczny i ogólnie projekt prowadzie się dużo lepiej i dużo łatwiej się z nim pracuje.
Bo jeśli ja puszczam coś na code review, jakąś brzydką rzecz, którą zrobił mój kolega, to w zasadzie można powiedzieć, że jest bardzo duża szansa, że za chwile ja w tym kodzie będę grzebał i będę musiał sam po prostu poprawić, to co ktoś inny zepsuł.
Więc dlatego takie poważne podejście na code review, jest bardzo pomocne, przez co każdy poprawia swój kod i swoją technikę przede wszystkim. Więc zachęcam do robienia code review
do szukania miejsc, gdzie robi się code review, gdzie robi się dobre review, warto też na rozmowie o pracę zapytać, czy tutaj w tym miejscu robi się code review, czy macie jakieś bardzo poważne podejście do tego code review.
Macie własne standardy do robienia code review? Jak w ogóle to wszystko wygląda?
Code review jest jednym z takich, bardzo ważnych elementów w rozwoju programisty, często też niedocenianym.
Podobnie też kiedyś było z testami jednostkowymi. Kidy zaczynałem pisać te testy jednostkowe, to tak trochę się z tym ukrywałem, bo bałem się, że ktoś mi powie:
„Hej tracisz czas na pisanie jakiegoś dodatkowego kodu”.
A tak naprawdę ten dodatkowy kod, jest bardzo pomocny w ogólnym prowadzeniu i rozwijaniu projektów.
Więc code review, testy jednostkowe, testy automatyczne i przedewszystkim clean code, który pomaga się skupić na tym jak robić rzeczy lepiej.
Te trzy rzeczy są naprawdę istotne i naprawdę bardzo pomocne na każdym etapie rozwoju kariery programisty.
Wiec w dzisiejszym vlogu, to już wszystko. Zachęcam Cię do stosowania tych trzech rzeczy na co dzień, bardzo pomagają w rozwoju.
Mi te trzy rzeczy bardzo pomogły.
I jeśli podobał Ci się vlog, to zachęcam do podzielenia się nim z innymi.
Ewentualnie zostawienia komentarza, bądź łapki w górę to też mi pomoże rozbudowywać ten kanał.
No i oczywiście jeśli nie subskrybujesz jeszcze mojego kanału, to zachęcam Cię do subskrypcji
Dzięki i do zobaczenia w następnym materiale.
