#Niezbędnik Juniora: Code Kata

By 2 September 2016 February 7th, 2017 Niezbędnik Juniora

Z naszego blo­ga mogliś­cie już poz­nać kil­ka skutecznych sposobów nau­ki pro­gramowa­nia. Było już o metodzie gumowej kaczusz­ki, debu­gowa­niu i rozwiązy­wa­niu prob­lemów, czy czy­ta­niu kodu na głos. Zebral­iśmy też dobre prak­ty­ki dla Junio­ra. Dzisi­aj kole­jny sposób na dojś­cie do pro­gramisty­cznego mis­tr­zost­wa, czyli Code Kata.

Czym jest code kata?

Za Wikipedią: code kata jest ćwicze­niem, które poma­ga pro­gramis­tom doskon­al­ić swo­je umiejęt­noś­ci poprzez pow­tarzanie. Ter­min ten został uży­ty po raz pier­wszy przez Dave Thomasa (które może­cie znac z książ­ki The Prag­mat­ic Pro­gram­mer) i jest naw­iązaniem do ter­minu kata wywodzącego się z japońs­kich sztuk wal­ki. Kata to ćwicze­nie w karate, które pow­tarza­sz wiele razy, za każdym razem robiąc małe popraw­ki, by w końcu dojść do mis­tr­zost­wa w ruchu. Więcej o samym pow­sta­niu kon­cepcji może­cie przeczy­tać tutaj, my zaś prze­jdziemy do praktyki.

Założe­niem tego sty­lu nau­ki jest ciągłe doskonale­nie się. Tak jak sportow­cy czy muzy­cy, muszą wiele razy pow­tarzać te same sek­wenc­je by osiągnąć w nich mis­tr­zost­wo, tak i my, pro­gramiś­ci może­my w ten sposób się rozwi­jać. Autor kon­cepcji pod­kreśla, że by być dobrym pro­fesjon­al­istą musisz mieć czas na ćwiczenia i naukę (i czas ten powinien być odd­zielony od Two­jej pra­cy). Możesz rozwiązy­wać ten sam prob­lem, zaczy­na­jąc za każdym razem od początku i nie wzoru­jąc się na swoim poprzed­nim rozwiąza­niu. Code kata może być więc świet­ną okazją do uczenia się na błę­dach, a w samych ćwiczeni­ach nie chodzi o rozwiązanie, a bardziej o drogę jaka do niego prowadzi.

Code kata w praktyce

Oczy­wiś­cie Twój tren­ing może wyglą­dać różnie, idąc jed­nak za autorem kon­cepji powin­naś znaleźć czas by codzi­en­nie rozwiązy­wać małe zada­nia z pro­gramowa­nia. 30 min czy godz­i­na powin­na wystar­czyć, ale pamię­taj by zapewnić sobie odpowied­nie warun­ki do nau­ki — niech to będzie czas dla Ciebie i dla Two­jego kodu. Możesz wziąć zadanie, które sku­pia się głównie na kodowa­niu, możesz wybrać takie, które wyma­ga więcej abstrak­cyjnego myśle­nia. Ory­gi­nalne katy znadziesz tutaj, a my od siebie może­my dorzu­cić wpis z zada­ni­a­mi z pro­gramowa­nia. Zaletą tych ćwiczeń jest to, że są oder­wane od two­jej pra­cy  — możesz więc poekspery­men­tować i sprawdz­ić rzeczy, które Cię zas­tanaw­ia­ją, albo wręcz prze­ci­wnie, nie sku­pi­ać się na teorii i po pros­tu pro­gramować, sprawdza­jąc potem, co moż­na było­by zro­bić lep­iej. Ekspery­men­tuj. Prak­tykuj. Baw się ;)

Code kata 2.0

Przeglą­da­jąc mate­ri­ały w internecie odnośnie takiego pode­jś­cia do ćwiczeń, znalazłam również artykuł, który pod­powia­da szer­sze spo­jrze­nie na code kata. Jego autor, cytu­jąc wpisy innych pro­gramistów odnośnie samo­d­oskonale­nia się sugeru­je, że nasze ćwiczenia mogą być znacznie bardziej abstrak­cyjne i skerowane na ludzi, a nie na kod :)

Poniżej lista pomysłów, które najbardziej mi się spodobały, uzu­pełniona o nasze propozycje:

  • Stwórz listę pro­gramistów, których podzi­wiasz. Pomyśl o swoich współpra­cown­ikach, osobach z bliskiego otoczenia. Zas­tanów się czego mógłbyś się od nich nauczyć.
  • Przez 20 min czy­taj czyjś kod. Zarówno czy­tanie bard­zo dobrego kodu, jak i tego okrop­nego może być bard­zo rozwi­ja­jące. Jeśli masz prob­lem ze znalezie­niem przykładu, poproś o pomoc bardziej doświad­c­zonego pro­gramistę. Możesz również podesłać te przykłady innemu pro­gramiś­cie i potem wspól­nie z nim o nich podyskutować.
  • Wybierz kogoś, kto jest mis­trzem w swo­jej dziedzinie, ale nie jest to pro­gramowanie. Pomyśl o tym jak doszedł do tego poziomu i czego możesz się od niego nauczyć.
  • Zaan­gażuj się w rekru­tac­je w swo­jej fir­mie. Spróbuj wysłuchi­wać np. tele­fon­icznego eta­pu rekru­tacji, a następ­nie samodziel­nie ocenić kandy­da­ta. Możesz również poprosić, by na tobie rkeruter przetestował przy­go­towane pytania.
  • Wyszukuj zada­nia pro­gramisty­czne i zaan­gażuj swój zespół we wspólne rozwiązy­wanie. Po 10–15 min poświęć­cie tyle samo cza­su na dyskusję o prob­lemie, nawet jeśli jeszcze nie skończyliś­cie rozwiązywać.
  • Spróbuj nauczyć się nowego języ­ka pro­gramowa­nia, który jest inny niż Twój doty­chcza­sowy (np. pro­gra­mu­jąc obiek­towo, zde­cy­duj się na język funkcyjny, tworząc back­end spróbuj fron­tu itp).
  • Dziel się wiedzą — wrzu­ci­aj swój kod na githu­ba (pra­ca, jaką będziesz musi­ała wykon­ać przy­go­towywu­jąc go do pokaza­nia światu jest naprawdę rozwi­ja­ją­ca), prowadź blo­ga (nawet, gdy jesteś początku­ją­ca — możesz opisy­wać swo­ją naukę wg danego źródła), wstępuj na spotka­ni­ach lokalnych społecznoś­ci (i na kon­fer­enc­jach), przy­go­towuj prezen­tac­je dla swo­jego zespołu.
  • Zaan­gażuj się w pro­jekt Open Source.
  • Zaglą­daj do swoich starych pro­jek­tów — sprawdź, co ter­az zro­biłbyś inaczej, ale też wery­fikuj, czy rozwi­jasz się w porzą­danym kierunku.
  • pow­tarzaj pod­stawy — co jak­iś czas wróc do algo­ryt­mów, albo teorii bliższej pro­gramowa­niu niskopoziomowe­mu. Staraj się zrozu­mieć jak dzi­ała two­ja ulu­biona bib­liote­ka i frame­work, nawet jeśli na co dzień, wystar­czy Ci, że jest to automagiczne.
  • Nie bój się code review czy pair pro­gram­min­gu — poma­gaj swo­je­mu zespołowi zawsze, kiedy tylko jest to potrzebne.
  • Spróbuj wytłu­maczyć pod­sta­wowe kon­cep­ty pro­gramowa­nia oso­bie, która zupełnie się tym nie zaj­mu­je. Opowiedz o swoim pro­jek­cie swo­jej bab­ci, albo młod­sze­mu bratu w sposób żeby mogli go zrozumieć.

Tyle od nas, a jak wyglą­da Two­je code kata?