blog.testowka.pl

TDD

Trzech developerów – czyli krótka historia z morałem

opublikowany przez 09, Kwi, 2015, w kategoriach Agile, Automatyzacja, TDD, Testowanie, XP

5597863793_60f320a45d_o

Trzech programistów zostało zapytanych o to jak długo zajmie im przejście przez pole do domu?

Junior Developer popatrzył na dystans dzielący go od domu i powiedział: „Nie wygląda żeby było daleko  – zajmie mi to 10 minut”. 

Senior Developer popatrzył uważnie na pole i powiedział: „Powinienem być w stanie dotrzeć tam w ciągu dnia”. Oczywiście zdziwiło to Junior Developera. 

Ninja Developer popatrzył na pole i powiedział: „Wygląda na dziesięć minut drogi, ale myślę, że piętnaście minut będzie odpowiednią estymatą”

Junior Developer wystartował ale po kilku krokach wybuchła pierwsza mina zakopana na polu co sprawiło, że Junior Developer musiał zboczyć z najprostszej drogi. Po tym jak wielokrotnie musiał zawracać wysadzając po drodze kolejne miny, po dwóch dniach udało mu się dotrzeć do celu. Oczywiście nie obyło się bez ran.

Senior Developer od razu rozpoczął swoją podróż na czworaka uważnie sprawdzając każdy metr drogi i przemieszczając się tylko tam gdzie jest bezpiecznie. Oczwiście kilka razy natknął się na minę ale zdążył dotrzeć do celu w trochę ponad jeden dzień. 

Ninja Developer wystartował i spokojnie przeszedł przez pole do celu. Dotarł tam po dziesięciu minutach. 

Dwaj pozostali programiści zszokowani zapytali: „Jak udało Ci się to osiągnąć?”, „Jak przeszedłeś przez pole nie wysadzając żadnej miny?”

„To było łatwe” odpowiedział Ninja Developer – „Po prostu nie zakopałem tam tych min wcześniej”.

[znalezione na Quorze  i przetłumaczone na nasze]

Konkluzja: Emergent Architecture – fajna sprawa, ale warto czasem pamiętać o reużywalności i możliwościach rozwoju naszego kodu. Warto też mieć testy automatyczne, które przez takie pole minowe nas spokojnie, może trochę powoli, ale jednak bezpiecznie przeprowadzą.

 

 

Dodaj komentarz więcej...

Coding Dojo – TDD Kata

opublikowany przez 31, Mar, 2014, w kategoriach Agile, Automatyzacja, CI, TDD, XP

Kanji-shu-ha-ri507
Kilka tygodni temu miałem przyjemność poprowadzić dla jednego z moich klientów krótki warsztat w formie Coding Dojo. Na codzień z tymi zespołami pracujemy nad wdrożeniem Continuous Delivery oraz innych praktyk związanych z Agile. Dojo nie było częścią regularnego Agile Coachingu, ale pomyśleliśmy, że może być dobrą formą oderwania się od codziennej pracy, wyjścia ze strefy komfortu i nauczenia się czegoś nowego. I tak też chyba się stało.

Po pierwsze czym jest Coding Dojo?

Dojo to termin pochodzący z języka japońskiego oznaczający „miejsce treningu”. Odnosił się on do trenowania sztuk walki takich jak Kendo czy Aikido. Nie jest to zwykła sala treningowa, gdyż obowiązują na niej pewne zasady, wchodząc do Dojo zgadzamy się postępować zgodnie z obowiązującymi tam normami.

Coding Dojo to również miejsce gdzie chcemy potrenować nie tyle sztuki walki co sztuki tworzenia kodu. Tutaj też obowiązują pewne zasady, o których za chwilę…

Podczas Coding Dojo zgromadzeni programiści próbują rozwiązać określony problem. W naszym przypadku podeszliśmy do problemu „String Calculator” – prosty kalkulator obliczający sumę parametrów podanych na wejściu. Backlog do tego zadania udostępniłem tutaj.

Zasady

Dojo zorganizowaliśmy w formie TDD Kata oraz podzieliliśmy je na 4 iteracje. Każda iteracja to 30 minut kodowania, 6 minut na code review i 6 minut na wspólną retrospekcję.

Uczestnicy programowali w parach. Po każdej iteracji zmiana pary, poniżej więcej na ten temat.

W przeciwieństwie do typowego Code Retreat po każdej iteracji nie usuwaliśmy wytworzonego kodu tylko kontynuowaliśmy poprzednio zaczętą pracę.

Przebieg Coding Dojo

Pierwsza iteracja to dla większości uczestników pierwsze kroki w TDD (niektórzy mieli już pewną wprawę, niemniej jednak przypomnienie zasad każdemu się przydało) – programujemy zgodnie z zasadą Red -> Green -> Refactor. Co 3 minuty zmienia się osoba przy klawiaturze – to wymuszało komunikację. TDD Kata to ćwiczenie służące do doskonalenia swoich umiejętności.

Po blisko pół godziny tworzenia kodu przyszedł czas na Code Review, ze względu na to, że było około 20 osób postanowiliśmy, że w ramach Code Review wymieszamy pary, praca każdej pary musiała zostać przejrzana przez kogoś z innej pary. Ta praktyka pozwoliła bardzo szybko pokazać różnice pomiędzy parami i poszczególnymi uczestnikami, a następnie pozwoliła wymienić się zdobytą wiedzą i spostrzeżeniami.

I oczywiście wspólna retrospekcja, podczas której rozwiewaliśmy wszelkie wątpliwości i omawialiśmy problemy oraz spostrzeżenia.

W drugiej iteracji wprowadziłem dwie zmiany – po pierwsze postanowiliśmy stosować TDD ping-pong. Jest to metoda programowania w parze polegająca na tym, że pierwsza osoba pisze test, druga pisze funkcjonalność spełniającą ten test, pierwsza refaktoryzuje, druga pisze test itd. To ćwiczenie pozwoliło uczestnikom lepiej dostrzec różnice pomiędzy poszczególnymi etapami w pętli TDD, oraz to czym się różni TDD od Test-First.

Drugą zmianą (nie do końca w mojej ocenie udaną, powinienem zostawić to na trzecią iterację) był zakaz rozmawiania podczas kodowania. Znacznie lepiej było by, gdybyśmy wprowadzili to w następnej iteracji, po tym jak już uczestnicy opanowali podstawy pętli TDD. Celem wprowadzenia tej zasady było wymuszenie pisania na tyle czytelnego kodu by druga osoba mogła łatwo zrozumieć intencje. Niemniej jednak było to całkiem zabawne nawet pomimo tego, że jeszcze nie wszyscy zrozumieli dobrze zasady TDD w tej iteracji. Braki nadrobiliśmy w kolejnej.

Trzecia iteracja po Code Review i Retrospekcji była podobna do poprzedniej z tą różnicą, że teraz można było już rozmawiać. To zaowocowało ożywionymi dyskusjami, oraz dzieleniem się pomysłami, które nagromadziły się w poprzedniej iteracji, oraz podczas Code Review. W efekcie było dużo refactoringu.

Iteracja czwarta – „porzuć swój kod”. Ponieważ w życiu programisty bardzo często bywa tak, że musi grzebać się w kodzie, którego sam nie tworzył postanowiłem podczas naszego Coding Dojo również zrobić taki eksperyment. Tym razem zasada przy dobieraniu się w pary była prosta – wszyscy wstają od komputerów przy których siedzą i starają się dobrać w pary z kimś z kim jeszcze nie programowali oraz wspólnie usiąść przy komputerze przy którym jeszcze nie siedzieli.

Była to chyba jeden z najciekawszych eksperymentów jaki przeprowadzałem na ludziach (i ich kodzie) ;-). To niesamowite jak bardzo różnie można zaimplementować te same funkcjonalności oraz na jak wiele różnych pomysłów można wpaść w zależności od tego z kim się pracuje. Podczas tej iteracji niektórzy zawzięcie refaktoryzowali (pamiętając o zasadach TDD) inni starali się dodawać nowe funkcjonalności przyjmując zastane konwencje.

W ramach przedłużonego Code Review po tej iteracji poprosiłem by wszyscy wracali do wszystkich komputerów, przy których mieli okazję wcześniej pracować i dokładnie przejrzeli co stało się z „ich” kodem odkąd opuścili to miejsce (nie tylko w ostatniej iteracji ale także w poprzednich).

Wnioski

Pojawiło się kilka ciekawych pytań i wniosków oto kilka z nich:

„Tworząc kod w ten sposób widzę, że implementując w sumie prosty problem poprzez stosowanie TDD wydłużył się czas implementacji oraz tak na prawdę spadła jakość tego co zrobiłem – gdybym nie stosował TDD to zrobił bym to szybciej i lepiej”. 

Moja odpowiedź brzmiała: Tak! Gdybyś dzisiaj to zaimplementował bez TDD to zrobił byś to ładniej (i może nawet napisał byś testy). Niemniej jednak w TDD Kata chodzi właśnie o dążenie do perfekcji i doskonalenie swoich umiejętności. Tego typu ćwiczenia wykonujemy właśnie po to, by za którymś razem napisać ten kod jeszcze lepiej i szybciej używając TDD, gdyż ta metoda ma wiele innych zalet, które warte są poświęcenia czasu potrzebnego na jej dobre opanowanie.

„TDD jest proste, gdy tworzymy nową funkcjonalność – a co jeśli mam już sporo kodu i to nawet z testami i nagle przychodzi zmiana wymagań. Co jeśli mam na przykład 5000 testów? Mam teraz szukać i zmieniać wszystkie testy zanim wprowadzę zmiany?”

Moja odpowiedź: jeśli wiesz, które testy trzeba zmienić i możesz to w miarę prosto i szybko zrobić to to zrób. Jeśli nie wiesz to… napisz nowy test, wprowadź testowaną zmianę w zachowaniu aplikacji, odpal testy i zobacz które testy przestały przechodzić. Potem zastanów się czy testy, które przestały przechodzić zrobiły to. bo zmieniło się zachowanie, czy dlatego, że coś zepsułeś. Następnie przemyśl, czy poprawiając testy przypadkiem nie duplikujesz tych, które przed chwilą napisałeś. Jeśli nie, to zastanów się, czy zmiana w funkcjonalności, którą wprowadziłeś nie była przypadkiem zbyt duża i nie miała jeszcze innych niechcianych konsekwencji. Jeśli wszystko jest ok, to powtórz powyższą pętlę aż wprowadzisz wszystkie zmiany.

Moja ogólna rada – nie bójcie się czerwonych testów. One właśnie po to są by często nie przechodziły i pokazywały Wam status systemu. Jeśli zastosujecie zasady z Clean Code oraz dobrze przemyślicie swoje testy to analiza tego dlaczego nie przechodzą będzie łatwa i przyjemna, a co za tym idzie wniesie to znaczną wartość do Waszej pracy.

Reasumując

Coding Dojo w tej formie jest w mojej ocenie bardzo fajnym ćwiczeniem wartym polecenia każdemu zespołowi. Przedmiotem Dojo wcale nie musi być TDD Kata – możecie spróbować zmienić się z zupełnie innym problemem nawet niekoniecznie programistycznym. Najważniejsze jest to, by wykonywane ćwiczenia wnosiły jakąś wartość i pozwalały Wam poszerzyć wiedzę.

Dojo, które przeprowadziłem z zespołem B&T Skyrise miało na celu przede wszystkim poszerzenie wiedzy na temat TDD oraz nabranie wprawy w praktykach Code Review. Myślę, że cel został osiągnięty.

PS: Niezmiernie ciekawi mnie, czy któryś z uczestników spróbował później podejść do samodzielnego rozwiązania jakiejś TDD Katy… Sprawdzę to przy najbliższej okazji.

1 komentarz więcej...