W tym wpisie postaram się zdefiniować dlaczego warto uczestniczyć w coderetreat.
Ja byłem już na dwóch takich warsztatach (cztery i pięć lat temu). Z każdego wyniosłem wiele, ale jedną zapamiętałem najbardziej. Był to czas kiedy zaczynałem moją karierę programisty, pisząc w NetBeans. Zasiadłem w parze z programistą zdecydowanie bardziej zaawansowanym ode mnie. To była 4 iteracja, więc problem już był raczej rozpracowany (implementacja oparta o zbiór aktywnych komórek, a nie żadna tablica dwuwymiarowa z booleanami). Z tych czterdziestu pięciu minut wyniosłem:
Warsztat składa się z 5 iteracji. Każda kolejna iteracja wprowadza inne ograniczenia, które można wybrać (lista przykładowych). Podczas warsztatu zalecane jest przestrzeganie Test Driven Development i 4 zasad tworzenia oprogramowania.
Praktyczne zapoznanie z podejściem Test Driven Development. Programowanie z podziałem na fazy:
Podczas pracy w parach ważna jest współpraca z drugą osobą. Na początku trzeba ustalić wspólną koncepcję. Zdecydować o kolejności w jakiej będziemy implementować rozwiązanie problemu. Dodatkowo warto sobie wypracować model współpracy, bo ostatecznie kod trafia na jedną klawiaturę.
Można zobaczyć warsztat innej osoby, a także podzielić się swoim. Najczęściej na pierwszy ogień idą skróty klawiaturowe oraz ciekawe funkcjonalności IDE. Ale na drugim miejscu jest sposób tworzenia kodu oraz sposób rozwiązywania problemów.
Wymiana spostrzeżeń w retrospekcjach jest bezcenna. Najczęściej zadawane są trzy pytania:
Często większość osób zaczyna z różnymi implementacjami opartymi o dwuwymiarową tablicę. W kolejnych iteracjach rozwiązanie problemu kierowane jest w stronę bardziej optymalnego rozwiązania (dodatkowym aspektem tego jest mieszanie się osób w kolejnych iteracjach podczas programowania w parach).
Rozwiązywanie kilka razy tego samego problemu mogłoby się okazać niezbyt ciekawe. Na szczęście kolejne iteracje dodają inne ograniczenia w rozwiązaniu tego samego problemu. Weźmy trzy przykładowe:
Moim zdaniem ciężko znaleźć bardziej wszechstronny warsztat, który zapewniałby wymianę wiedzy w tak krótkim czasie. Iteracyjny charakter i wymiana par ma na celu skomasować doświadczenia płynące od wielu osób z którymi można programować w parze. Dodatkowo retrospekcje całej grupy przynoszą często wiele nieoczekiwanych wniosków do których trudno dojść w pojedynczej parze.