Coderetreat - dlaczego warto tam być.

W tym wpisie postaram się zdefiniować dlaczego warto uczestniczyć w coderetreat.

Moja historia

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:

  • Tworzenie kodu na zasadach refactoringu
  • Dobre opanowanie IDE - IntellJ
  • Tworzenie kodu w metodyce DDD

Organizacja warsztatu

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.

Iteracja

  • Prezentacja ograniczeń iteracji - W tym kroku prowadzący prezentują jakie są ograniczenia danej iteracji (np. nie można używać myszki lub nie można używać pętli)
  • Implementacja problemu - 45 minut - Osoby siedzące w parach starają się zaimplementować algorytm gry w życie respektując ograniczenia nałożone przez prowadzących.
  • Usunięcie kodu - Trzeba usunąć kod który się stworzyło w obecnej iteracji.
  • Retrospekcja - Tutaj wszyscy uczestnicy dzielą się spostrzeżeniami na temat obecnej iteracji.
  • Zmiana pary - W kolejnej iteracji dobrze być w parze z osobą z którą jeszcze nie miało się okazji być w parze wcześniej.

Co decyduje o wyjątkowości tej formuły

Trening TDD

Praktyczne zapoznanie z podejściem Test Driven Development. Programowanie z podziałem na fazy:

  • Red - implementacja testu który nie przechodzi
  • Green - najprostsza implementacja która powoduje przejście testu
  • Refactor - refaktoryzacja kodu

Programowanie w parach

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ę.

Zobaczenie warsztatu kilku innych programistów

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 wiedzy na retrospekcjach

Wymiana spostrzeżeń w retrospekcjach jest bezcenna. Najczęściej zadawane są trzy pytania:

  • Co udało się Wam zrobić?
  • Czego nowego nauczyłeś się w ostatniej iteracji?
  • Co Cię zaskoczyło w ostatniej iteracji?

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).

Ograniczenia mające na celu zmianę spojrzenia na ten sam problem.

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:

  • Bez myszki - Powoduje to większe skupienie na skrótach klawiaturowych, funkcjach wbudowanych w IDE oraz skrótach systemowych.
  • Nazwy klas są czasownikami, a nazwy metod są rzeczownikami - To jest pogwałcenie ogólnie stosowanych reguł nazewnictwa w programowaniu obiektowym. Co pokazuje wagę tego aspektu w programowaniu.
  • Cichy ping-pong - Czyli jest podział na programistę i testera ale nie można ze sobą rozmawiać. Dlatego ciężko jest ustalić wspólne podejście do rozwiązywania problemu. Ważne jest aby kod wyrażał intencje programisty.

Podsumowanie

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.