Coding Dojo w Espeo  drukuj

Podczas ostatniego spotkania technologicznego urządziliśmy Coding Kata.
Jako, że to było pierwsze Dojo dla większości uczestników postanowiłem uprościć zasady maksymalnie – tak by pokazać istotę samego spotkania. Było to jednym z celów. Drugim elementem było ćwiczenie TDD, które jest w firmie wykorzystywane, lecz praktyki nigdy za wiele.
Najpierw o założeniach. Przyjęliśmy formułę Randori, czyli para programuje przy użyciu rzutnika, zmienialiśmy pary co 4 minuty, całość trwała godzinę, z czego ostatnie 10 minut przeznaczyliśmy na retrospekcję.
Podczas dojo rozwiązywaliśmy Kata Misswaper.
Mimo krótkiego czasu udało się wysnuć kilka wniosków. Jednym z nich był problem jaki wyszedł z TDD. Po refaktoryzacji powstała nowa klasa, podzieliły się metody. Po czym trudno było napisać test do nowej metody, który by nie przechodził… Wychodzi na to, że TDD sprawdza się w oparciu o gotowe założenia, czy testy akceptacyjne. W przypadku testów jednostkowych pojedynczych metod, testy te tracą na jakości.
Podczas retrospekcji wyciągnęliśmy też kilka wniosków co do samej organizacji. Dla niewielkiej liczby osób nie jest konieczne programowanie w parach (o ile właśnie tego nie ćwiczymy). Krótki czas powinien być dobrze przygotowany, opóźnienia techniczne zjadają dużo cennego czasu.

Parę dni później, gdy rozmawiałem o sensie prowadzenia przeglądu kodu i przewadze programowania w parach, pomyślałem, że Coding Kata mogło by być z powodzeniem wprowadzone do katalogu technik XP. W ten sposób można rozwiązywać nie tylko problemy natury ogólnej filozofii programowania, ale też konkretne problemy projektowe.
Podsumowując, Coding Dojo jest bardzo integrującą i efektywną wymianą doświadczeń. Może być przydatne, jeśli mamy kilka zespołów pracujących długo nad oddzielnymi projektami.