Ostatnie dni upłynęły mi pod znakiem Test Driven Development (TDD). Kiedyś poświęciłam dużo czasu na doskonalenie tego procesu. Wykorzystywałam go nawet poza Coding Dojo. Kiedy oswoisz się już z traktowaniem testów jak obywateli pierwszej kategorii, starasz się to stosować wszędzie. Oczywiście z biegiem czasu ten proces ewoluuje, robisz pewne uproszczenia i skróty. Kiedy chciałam pokazać to na żywo, musiałam znów wrócić do zasad, żeby moje skrzywienia nie wpłynęły na czyjąś naukę.

 

Wyzwania

Najpierw przez pięć dni codziennie organizowałam webinary, na których prezentowałam rozwiązanie innego kata. Ludzie, którzy pojawiali się na webinarach dużo wnosili w sam proces. Byli suflerami, którzy podrzucali ciekawe pomysły. W trakcie tego tygodnia odezwali się do mnie znajomi, którzy też chcieli spróbować. Tak powstały dwa webinary TDD w formie pair programming, z Szymonem Przedwojskim i Łukaszem Drygałą. To jeszcze większa frajda, bo można z kimś na bieżąco konfrontować swoje pomysły. Oczywiście wyzwań technologicznych nie brakowało, ale co nas nie zabije…

Potem przyszedł czas na wyzwanie, żeby każdy mógł spróbować pisać TDD własnoręcznie. Myślę, że wiele osób nie doceniło tego procesu. Już po pierwszym dniu wyzwania pojawiły się głosy miałem już w głowie implementację, dlatego wg mnie poszło średnio”, albo „ciężkie było nierobienie rzeczy do przodu”. Były też objawienia! „fajne jest to, że mój kod jest lepiej przemyślany i uporządkowany”, czy „od razu dostaję info zwrotne i widzę co zepsułem oraz w jakim miejscu”. Takie przemyślenia bardzo mnie cieszą. Wiem po sobie, że w takich tematach, jak pisanie testów, czy refaktoryzkcja łatwo jest patrzeć jak ktoś pisze i wszystko wydaje się takie proste. Dopiero kiedy trzeba to zrobić u siebie, zaczynają się schody. 

 

Wszystko przychodzi z doświadczeniem.

Można czytać książki i słuchać wykładów, ale dopóki nie poświęci się czasu na własnoręczne przepracowywanie różnych scenariuszy, ta wiedza jest martwa. Dlatego kiedy zaczęłam pracować nas swoim kursem Pisz Lepsze Testy skupiłam się na praktycznej części. Ja dostarczam szereg dobrych praktyk, narzędzia i podstawy teoretyczne. Ale zapoznanie się z materiałami to tylko połowa sukcesu. Największą wartością jest praca z kodem. Dlatego zapewniam warunki do rozwoju opartego na doświadczeniu. Możesz dołączyć do tego programu do 1 kwietnia do 20:00.

 

Jakie są trzy kroki do lepszego TDD?

  1. Praktyka. Pierwszy problem jest bardzo trudny, kolejny trochę mniej, potem już z górki. Nawet jeśli dobrze znasz TDD, możesz szybko zardzewieć. Polecam raz na jakiś czas machnąć sobie kata, na przykład na żywo z publicznością – adrenalina gwarantowana!
  2. Pokora. Nie będziesz od razu robić tego dobrze. Żyj z tym. To jest proste, ale niełatwe. Popełniaj błędy i ucz się na nich. Jeśli możesz kogoś poprosić o pomoc – code review, może pair programming, zrób to! Druga para oczu jest nie do przecenienia.
  3. Prostota. Nie rozwiązuj problemu z wizją finalnego rozwiązania w głowie. Daj się ponieść metodzie małych kroków! Kiedy programowaliśmy w parze z Łukaszem Drygałą, każde z nas miało jakąś wizję, ale zdecydowaliśmy się pójść od zera. Efekt był taki, że rozwiązanie było lepsze, niż oba nasze pierwotne pomysły. Tutaj wchodzi w grę również inteligencja zbiorowa, ale to temat na inny wpis 🙂

Możesz posłuchać tego kawałka webinaru, gdzie mówię o tych trzech elementach. Na moim kanale znajdziesz więcej takich materiałów 😉