Format

Format Legacy Code Retreat został zaproponowany przez  J. B. Rainsbergera i jest podobny do „normalnego” Code Retreat – składa się z 6 sesji, w których pracujemy w parach i po każdej sesji kasujemy nasz kod. W przeciwieństwie jednak do normalnego Code Retreat nie zaczynamy od zera pisać „Grę w życie” a pracujemy już z dostarczonym kodem gry Trivia i naszym celem jest jego zrozumienie i bezpieczne zrefaktoryzowanie.

Nasz event poprowadzony został przez Martina Klose, który świetnie spisał się w roli facylitatora. Rozpoczęliśmy od krótkiego wprowadzenia, gdzie Martin omówił „4 rules of simple design” i algorytm refaktoryzacji legacy kodu. Z ciekawostek, event prowadzony był po angielsku, z czego bardzo się cieszę, jako że byłem jedyną osobą która nie potrafiłaby pracować po niemiecku..

Fajnym motywem podczas rozpoczęcia dnia było ćwiczenie, które wykonaliśmy by „szybko się poznać” w grupie. Martin polecił nam ustawić się w szeregu, gdzie na jednym końcu były osoby, które uważały się za wymiataczy w TDD a na drugim końcu, osoby, które dopiero rozpoczynały swoją przygodę z TDD. Następnie Martin zasugerował by osoby początkujące pracowały w ciągu dnia z osobami doświadczonymi.

• Sesja 1 – Zapoznanie z kodem
• Pierwsze starcie z kodem. W tej sesji rozpoczęliśmy pisanie testu charakteryzacyjnego i zajęło nam to praktycznie cały dostępny czas (przy czym prawie 10 minut zmarnowaliśmy na skonfigurowanie JUnita, który z jakiegoś powodu nie chciał dodać się do projektu, ech…). Dev z którym pracowałem w parze nigdy nie pisał w Javie, także trochę czasu spędziliśmy również na wytłumaczenie podstawowych rzeczy na temat Javy.
• Sesja 2
• Martin sugeruje wszystkim zastosowanie techniki Golden Master. Sprowadza się to mniej więcej do tego co robiłem w poprzedniej sesji, więc z moim nowym dev partnerem ruszamy do kodowania. Po parunastu minutach mamy już gotowy test, który porównuje wykonanie programu z naszą „złotą kopią”. Jesteśmy pewni siebie i wtedy pojawia się Martin z pytaniem „Skąd wiecie, że wasz test jest wystarczający?” „Jaką macie pewność, że pokrywa on wszystko to, co robi kod?”. Jako stary wyjadacz „testowania mutacyjnego” nie daję się zbić z tropu i przystępujemy do „testowania” naszego testu poprzez celowe wprowadzanie błędów do kodu produkcyjnego i obserwowanie czy nasz test to wykrywa. Martin miał rację.. Są pewne modyfikacje, których nasz test nie wyłapuje. Resztę sesji spędzamy na udoskonalaniu naszego testu.
• Sesja 3
• W tej sesji skupiliśmy się na refakoryzacji kodu. Konkretnie poprawialiśmy czytelność (łatwość zrozumienia) instrukcji warunkowych, np. „if (roll % 2 != 0)” na „if(canLeavePenatlyBoxAfter(roll)”

• Sesja 4
• Refaktoryzacja kodu małymi kroczkami. Reguły: Ustaw timer na 2 minuty. Pracuj z kodem i wrzucaj swoje zmiany do repozytorium kodu. Jeśli w ciągu 2 minut nie zdążysz wrzucić niczego do repo, cofnij swoje zmiany do momentu ostatniego commitu w repo i rozpocznij od nowa. Po drugim razie, gdy dopadł nasz timer, pracowaliśmy w naprawdę malutkich kroczkach i w sumie daliśmy radę! Generalnie, im częściej wrzucamy nasze zmiany do repo tym lepiej (mniej konfliktów, częstszy feedback), także myślę że ćwiczenie wykonane w tej sesji było wartościowe.
• Sesja 5
• Celem tej sesji było zidentyfikowanie fragmentów kodu, które dało się zamienić w „pure functions„. Podczas tej sesji pracowałem w Rubym (wszystkie poprzednie były w Javie) i odczułem na własnej skórze, jak wspaniałe wsparcie do refactoringu ma Java.. (Np. IDE w Javie było dużo sprytniejsze w znajdywaniu duplikacji w kodzie). Jedną z zalet „wyciąganych” przez nas funkcji było to, że można je było stosunkowo łatwo przetestować.
• Sesja 6
• W czasie tej sesji, po zidentyfikowaniu i stworzeniu kilku „pure functions” mieliśmy przyjrzeć się im bliżej i zastanowić się, gdzie można by je przenieść – jednym słowem, zaczęliśmy „wyciągać klasy”. Cały schemat refactoringu można opisać mniej więcej tak:
• Extract method
• Replace fields with parameters to the method
• Make method static
• Test the method
• Find a new home for the method, move to (and maybe create) new class
• Alternatywnym sposobem, wypróbowanym przez niektórych uczestników było zastosowanie refaktoringu „pull up” i przeciągnięcie pewnych funkcjonalności do „nowej” klasy bazowej, a następnie zastosowanie refakoryzacji „replace inheritance with delegation” – coś, co mam w najbliższym czasie przetestować.

Scala

Po trzeciej sesji mieliśmy długi lunch, w czasie którego rozmawiałem o Scali. Temat, który mnie interesował to testowanie i jak w podejściu funkcyjnym radzimy sobie z problematycznymi zależnościami kodu, takimi jak baza danych czy odwołania do innych systemów. W podejściu obiektowym, używamy w tym celu „mocków’. Z tego co zrozumiałem, w Scali ważnym pojęciem jest kompozycja funkcji, i właśnie odpowiednio korzystając z kompozycji możemy „wstrzykiwać” albo prawdziwą funkcję, która pobiera dane z bazy danych, albo funkcję „testową”, która tylko udaję bazę danych. I tak testowanie takiego systemu sprowadza się do przetestowania funkcji, z których składa się nasz system na poziomie jednostkowym, a następnie przetestowanie całego systemu (złożonej funkcji), gdzie być może niektóre funkcje zastąpione są zmienikami na potrzeby testów.

Organizacja

Jeśli chodzi o organizację tym razem kupiliśmy małe śniadanie w piekarni a na obiad poszliśmy do restauracji – wyszło to dużo taniej niż zamawianie kateringu.

Generalnie, bardzo nam się podobało i już myślimy o kolejnym evencie, może w czerwcu?

Zachęcam Cię do organizacji Legacy Code Retreat w swoim mieście!

Ps. Zdjęcia z wczoraj można zobaczyć tutaj..

Daj znać innym

Nasz idealny proces powinien:

• Zapewniać szybką informację zwrotną na temat jakości.
• Kierować się zasadą „jakości wbudowanej w proces„.

Ps. Jakiś czas temu opisałem na tym blogu różne rodzaje testów automatycznych.

Daj znać innym

Wideo można zobaczyć tutaj: Refactoring of test

Filmik trwa 5 minut podczas których:

1. Rozbijam jeden duży test na kilka mniejszych (by testy były łatwiejsze do zrozumienia, a gdy nie przechodzą by dokładnie było wiadomo co nie działa)
2. Zamieniam assertEquals na assertThat (naturalniej się czyta)
3. Zastępuje komentarze opisowymi nazwami testów (by samo zerknięcie do raportu w ciągłej integracji wystarczyło do zorientowania się, co się dzieje)

Daj znać innym

Pomyślałem, super by było, gdyby ktoś mi pokazał jak napisać to lepiej.. „Refactor my code”.. Po krótkim googlowaniu okazało się, że jest już taki serwis: http://refactormycode.com/

O ile nazwa jest już zajęta .. to mój pomysł miał jeszcze jeden istotny składnik. Założyłem, że ważne jest by „mój” kod nie tylko został poprawiony, ale żeby został poprawiony w małych kroczkach z wytłumaczeniem „dlaczego”, tak bym mógł się nauczyć i następnym razem sam napisać coś porządnie..

W gruncie rzeczy, to marzy mi się „coding dojo” rozproszone w czasie i przestrzeni. Piszę kod, który zapewne może zostać napisany lepiej. Chciałbym abyś wziął ten kod i w małych kroczak go ulepszył. Po każdym kroczku zrób commit i wyjaśnij co i dlaczego zrobiłeś.

Prototyp tego co mam na myśli dość szybko udało mi się stworzyć przy pomocy githuba.

https://github.com/dziemid/refactormycode

Napisałem  dość brzydką wersję String Calculatora , którą następnie trochę  poprawiłem .. Nie mniej wersja końcowa nie jest aż tak ciekawa jak sam proces jej tworzenia, gdzie każdy mały kroczek został udokumentowany.

Pomysł został podchwycony przez Martina, która zrefaktoryzował mój kod krok po kroku (tutaj jeden z jego kroków w raz z moim komentarzem).

Dziś wrzuciłem kolejny kod do poprawienia: Grę w życie w Javie. Kod jest napisany średnio. Miejscami jest brzydki, niektóre klasy są w ogóle niepotrzebne, inne klasy robią rzeczy, które być może powinny być gdzie indziej.

Zachęcam Cię do zrobienia „Fork”a i zrefaktoryzowania tego kodu krok po kroku. W każdym commicie napisz co i dlaczego robisz. W ten sposób razem stworzymy coding dojo rozproszone w czasie i przestrzeni

Daj znać innym

Na otwarcie konferencji Google przygotowało niespodziankę – nowy język programowania Dart. Dokładnie, została zaprezentowana wczesna wersja języka, nad którym ciągle trwają prace.

Jest to język opcjonalnie typowany. Możesz używać typów, ale nie musisz. Jeśli będziesz używał typów, kompilator pomoże Ci podpowiadając co dany typ potrafi lub sugerując, że chyba używasz nie poprawnego typu. Nie mniej kompilator nie będzie Cię do niczego zmuszał – to czy Twój program będzie działał czy nie, okaże się po uruchomieniu (podobnie jak w przypadku JavaScript).

Po co nowy język?

• Dart ma być językiem, w którym „trudno” jest pisać nie wydajne programy. Google chce ułatwić swoim programistom pisanie aplikacji, które działają szybko.
• Dart kompilowany jest do JavaScriptu, więc może działać na większości „nowoczesnych” przeglądarek. Trwają również prace nad maszyną wirtualną Darta, która będzie częścią przeglądarki Chrome. Jedna z ciekawszych opcji: „snapshot” kodu (kod może zostać prekompilowany i dostarczony do przeglądarki w postaci gotowej do wczytania do pamięci), ułatwiający bardzo szybki i wydajny start aplikacji.
• Model konkurencji zaczerpnięty z języka Erlang. Izolaty na wzór aktorów.
• Przemawia do ludzi z dwóch obozów (języki dynamiczne (JavaScript), języki silnie typowane(Java)
• Być może zastąpi Javę na platformie Android?

• http://try.dartlang.org/
• http://www.dartlang.org/
• http://dartinside.com/

Język wydaje się fajny. Na następnym dojo zaproponuje, by rozwiązać w nim jakiś problem. Ciebie również zachęcam do poeksperymentowania

Daj znać innym

W telegraficznym skrócie:

Niedziela

• Warsztaty A user user manual z Chrisem Nodderem. Porady na temat tego jak tworzyć przyjazne i łatwe w użytkowaniu oprogramowanie + teoria na temat tego, jak zachowują się użytkownicy i dlaczego.

Poniedziałek

• Google prezentuje nowy język programowania – Dart

Wtorek

• TODO

 Środa

• TODO

Czwartek

• Warsztaty „Evolutionary Architecture – How to Make it Work” z Martinem Fowlerem i Rebeccom Parsons
• Warsztaty ”Influence Strategies for Practitioners” z Linda Rising

Piątek

• Warsztaty ”Maintaining and Evolving Legacy Systems” z Frankiem Buschmann

Ogólne komentarze i podsumowanie:

W tym roku do materiałów konferencyjnych dołączone zostały dwie małe książeczki: „The 3 pillars of personal effectiveness” oraz „Priming Kanban” - oryginalne i fajne posunięcie.

I tak na przykład w „Priming Kanban” wyczytałem, co robić gdy osiągamy limit „work in progress„. Jest to moment na dyskusję. Do wyboru mamy albo powiększyć limit (co będzie skutkować zwiększeniem czasu, jaki jest potrzeby by historyjka przewędrowała od „koncepcji” do „wdrożenia”) albo usprawnić/wspomóc „wąskie gardło”. Np. gdy „testowanie” jest wąskim gardłem, może jako programiści możemy zautomatyzować wrzucanie nowej wersji na środowisko testowe? Tak czy inaczej, osiągnięcie limitu „work in progress” jest pretekstem do dyskusji.

Konferencja to również męczące wydarzenie (pełno wrażeń, codziennie integracja), nie mniej z niecierpliwością czekam na kolejną konferencję organizowaną przez Trifork, QCon 2012 w Londynie

Daj znać innym

Podczas tego warsztatu zadaniem uczestników jest napisanie aplikacji webowej, która odpowiadać będzie na zapytania „wirtualnych” klientów. Uczestnicy warsztatu nie wiedzą, co ich czeka i z logów serwera muszą wywnioskować, czego chcą klienci.

Klienci będą między innymi pytać:

• Ile jest 2 + 5?
• Która z tych liczb się największa: 4, 234, 2, 4?
• Jaki kolor ma banan?

W warsztacie wzięło 8 osób, zostały uformowane 4 pary. Zaczęliśmy o 1700 i około 50 minut zajęła nam sesja próbna, gdzie uczestnicy konfigurowali sieć tak, by móc połączyć się z serwerem i odpowiedzieć na proste zapytanie „Jak masz na imię”.

Około 18 zaczęliśmy ”prawdziwą” rundę z normalnymi pytaniami. Niestety z braku czasu, runda trwała tylko około 45 minut. Na przyszłość, „normalna” runda powinna trwać co najmniej 90 minut. Na potrzeby warsztatu przygotowane jest 6 zestawów pytań i wczoraj dobrnęliśmy tylko do trzeciego, a tak naprawdę mało który zespół miał poprawnie zaimplementowane wszystkie pytania z 2 pierwszych zestawów.

Z 4 zespołów tylko jeden pisał testy. Wszystkim zespołom poszło „podobnie źle” – zdobyły po około -2000 punktów. Prawdopodobnie gdyby warsztat trwał dłużej, to w miarę implementowanie poprawnych odpowiedzi dla kolejnych pytań, pary wyszłyby na prostą.

Pary, które używały „cięższych” serwerów aplikacji (jak Jetty ) traciły sporo punktów podczas redeployu aplikacji. Niestety nikt nie pokusił się o rozwiązanie z load balancerem

Technologie jakich używali uczestnicy

• Scala
• Node.js
• Groovy
• Smalltalk, a potem z powodu problemów Java

Ogólnie chyba się podobało .. Może powtórzymy ten warsztat za jakiś czas…

Daj znać innym

Na razie założyłem tylko grupę na googlach i szukam chętnych do pomocy. Przed nami „trochę pracy”. Musimy znaleźć sponsorów, salę, przeprowadzić rejestrację, zorganizować obiad i załatwić wiele innych małych rzeczy. Damy radę! Po ostatnim CodeRetreat w Berlinie, ludzie są pozytywnie nastawieni

Światowy dzień CodeRetreat odbędzie się w sobotę, 3 grudnia 2011. Na razie na liście miast uczestniczących w projekcie nie ma żadnego miasta z Polski, mam nadzieję, że wkrótce się to zmieni ;)

3 grudnia, przez około 32 godziny, gdzieś na świecie odbywać się będzie CodeRetreat. W czasie przerw pomiędzy iteracjami będziemy łączyć się na wideo konferencjach z innymi lokalizacjami i na bieżąco będziemy wymieniać się wrażeniami i pomysłami.

Czy weźmiesz udział w światowym dniu CodeRetreat? W jakim mieście?

Daj znać innym

Ostatnio eksperymentowaliśmy z innymi językami niż Java. Wypróbowaliśmy Clojure, Scale oraz Ruby. Kilka obserwacji:

Dojo zaczynamy z „czystym” projektem (startujemy od zera).

W przypadku Clojure i Ruby kodowaliśmy od zera. W przypadku Scali, zostało zaprezentowane i omówione gotowe rozwiązanie. Dużo bardziej podobało nam się kodowanie od zera, gdyż każdy miał szansę zrozumieć co się dzieje (dla wielu języki były obce), a bardziej zaawansowane osoby miały szansę zobaczyć krok po kroku sposób rozwiązywania problemu przez innych.

Prezentowanie gotowego rozwiązania raczej się nie sprawdziło, gdyż osoby dla których język był nowy nie do końca rozumiały co się dzieje, a dla osób zaawansowanych samo finalne rozwiązanie nie było aż tak ciekawe.

Ćwiczymy jedną rzecz na raz

Celem Dojo jest ćwiczenie. By robić to dobrze, warto skupić się na jednej rzeczy na raz. Średnim pomysłem jest ćwiczenie rozwiązania problemu w sposób obiektowy, gdy większość grupy nie potrafi nawet programować w danym języku (w takiej sytuacji można spróbować coś takiego: ekspert w danym języku ma klawiaturę i zamienia sugestie uczestników na temat rozwiązania obiektowego w kod).

Ponieważ spotykamy się tylko na jedną godzinę, dobrze jest wybrać za cel ćwiczenia coś bardzo konkretnego. Poniżej kilka przykładów:

• Eksplorowanie  (nowego) języka (Ruby)
• Eksplorowanie  (nowego) języka (Scala)
• Ćwiczenie (szybkiego) cyklu RED, GREEN, REFACTOR w TDD (w języku, który zna grupa) (np. chcemy by cykl trwał mniej niż 3 minuty)
• Ćwiczenie programowania obiektowego (w języku, który zna grupa) (np. chcemy by każda klasa przestrzegała zasad SOLID)
• Ćwiczenie nazewnictwa (chcemy, by każda nazwa ujawniała intencję twórcy)
• Ćwiczenie w pisaniu krótkich metod (np. max liczba linii to 4)
• Ćwiczenie w obsłudze IDE (tylko skróty klawiszowe, refactoring)

Daj znać innym

1) Instalacja schematu kolorow: http://tedwise.com/2009/02/26/dark-pastels-theme-for-intellij-idea/

2) Dodanie szablonu do testow (Settings -> Live templates):

@Test
public void should$NAME$() throws Exception {
 // Given
 $END$

 // When

 // Then
}

Daj znać innym