The right way - people first.

If you work with wimps who take everything personally, do not want to change their minds, are close for modifications and extensions and are scared of thinking about changing something then don't forget this:

PUT PEOPLE FIRST. 

Maybe the step you wanted to take was to big? Maybe there is a better way to explain something? Be smart and find another way, the RIGHT WAY to hack the wimp.

CodeRetreat w Berlinie

Bardzo sie ciesze, ze kolejny raz moglem wziac udzial w CodeRetreat (CR). Sa to warsztaty integrujace ludzi pracujacych jakkolwiek z kodem. Wedlug mnie dobrym polskim tlumaczeniem "Code Retreat" bedzie: "Rekolekcje dla programistow". CR stwarza mozliwosc do pomedytowania nad kodem, do wymiany refleksji nad jego stanem, do podjecia postanowien, do zmiany myslenia i wreszcie do uczenia sie od siebie nawzajem. Poza hardskillami w naturalny sposob uczysz sie softskilli. Pair programming, zmiana w parach co sesje, retrospekcje, wspolny obiad bez pospiechu - to wszystko sprzyja interakcji.

Tak bylo i tym razem. Dzieki zapalencom (no bo jak nazwac osoby zjezdzajace sie i to w niedziele po to zeby caly dzien razem kodowac) oraz sponsorom: @nokia, @crealytics, @klosebrothers udaly sie kolejne rekolekcje. Bardzo ciekawa relacje mozna przeczytac na blogu Staszka.

Testy jUnitowe sa do dupy

Mowilem ci juz o tym czy nie, ze testy jUnitowe sa do dupy? Nie ? No to sluchaj... tzn czytaj...Co to wogle sa te testy jUnitowe? WTF? Gdzies po drodze wsrod ton klepanego kodu, gdzies gdzie jedni chcieli cos usprawnic, drudzy tylko odbebnic, gdzie cialge brakowalo czasu zetknely sie dwa pojecia: test jednostkowe i jUnit. W wyniku tego zetkniecia powstalo nowe super cool pojecie "testy jUnitowe". I teraz nie wiedomo czy chodzi o testy jednostkowe, integracyjne, alibi, czy jeszcze jakies inne.Co to wogle znaczy, ze ktos pisze, ze mam w projekcie testy jUnitowe poza tym, ze pewnie uzywa biblioteki jUnit? Czy tak trudno uzywac pojecia "test jednostkowy", "unit test"?. Wiec co jakis czas trzeba odkurzyc ten temat co udalo mi sie zrobic.
W projekcie, w ktorym pracuje poprowadzilem prezentacje o testach jednostkowych i bibliotece mockito. Korzystajac z tego, ze Staszek blisko jest i dosc czesto mozna pogadac o sprawach waznych z punktu widzenia software developera przeprowadzilismy kilka deskusji o mockowaniu, testowaniu jednostek kodu (publicznego api klasy, pojedynczej metody) i izolacji obiektow na potrzeby tesotwania jednostkowego. Zebrane przemyslenia zostaly dopieszczonem, ubrane w prezentacje i przedstawione ludziom z projektu.

Przebieglo to mniej wiecej tak, ze przygotowalem prosty model w domenie samochodowej, ktora to domene kazdy w projekcie rozumie. Bez zadnych problemow podefiniodaem zaleznosci i prosta logike. Samochod ma silnik, rame, nadwozie, elektornike.

Pewne odpowiedzialnosci zakapsulkowane sa w danych jego elementach. Elementy te zaleza od siebie i wspolpracuja ze soba. 

Przedstawilem jak odizolowac obiekt samochod, ktory byl testowany - mockujac wspolpracujace z nim obiekty. Pokazalem jak to zrobic w sposob bez mockow (test setup sie mocno wydluzyl) i jak to samo zrobic z uzyciem mockito.

Wszystko bylo banalnie proste, zamokowalem doslownie dwie metody w klasie silnik - wspolpracujacej z klasa samochod. Hmm tak sobie teraz mysle, ze dobrze by bylo podpiac to pod githuba zebys mogl zobaczyc o czm dokladnie pisze... (TODO: podlinkowac repo z githuba). Ludzie patrzeli na pisany kod i mogli sami stwierdzic co jest przyjemniejsze i co im bardziej lezy. Pierwsze spostrzezenia jakie im przyszly pokazaly jak przez pisanie testow zmuszamy sie do tworzenia lepszego designu. A to ze statyczne pola jakos zmienne globalne sa slabe, baaardzo slabe (cokolwiek to znaczy), a to ze inicjalizowanie w obiektow zaleznych przez operator new w konstruktorze obiektu glownego jest tez slabe :) A ja tylko kiwalem glowa i sie usmiechalem.

Podparlem sie prezentacja Staszka i praktycznym jego podejsciem i opowiadzialem jeszcze o przewadze

assertEquals(expected, actual)

nad assertTrue(warunek)

jesli chodzi o ilosc informacji zwracanych jest przez jUnita w razie niespelnienia asercji.

o szablonie given-when-then
 

po to aby latwo mozna sie bylo polapac, ktory fragment metody testowej co robi.

... i o pewnej ciekawej ksiazce:

Na koniec nasz projaktowy leader zachecil wszystkich do prezentowania tematow, ktore zycie w projekcie uczynic moga lzejszy. Ja mam juz kolejny temat jednak zanim go zapodam musze przygotowac grunt pod zmiany. O tym co to znacz bedzie w jednym z nastepnych postow.

Ty, drogi czytelniku tez pewnie masz cos do powiedzenia. Nie czekaj wciaz wciskajac sobie kit, ze jeszcze potrzebujesz tego i tamtego, ze sa lepsi co nic nie przedstawiaja i ze nie ma co wychodzic przed szerego bo jeszcze sie skompromitujesz. Daj spokuj, zmien nastawienie, zacznij sie dzielic tym co masz i nie obawiaj sie wzbudzac skrajnych emocji. Jedni beda cie kochac inni cie wysmieja, a ja chetnie sie dowiem co za temat zapodales i komu...

Projekt - miejsce gdzie spedzasz wiekszosc dnia.

Bierzesz udzial w projekcie, w tworzeniu produktu (w moim przypadku jest to software). Narodzil sie on jakis czas temu, co kilka miesiecy ewoluuje o kolejne funkcjonalnosci. Cykl ewolucji powtarza sie z jednego wydania na drugie. W tym wszystkim obserwujesz przerozne formalizmy projektowe, ustawki, rozne formy wspolpracy, podkniecia, czkawki itd. Wszystko dziala w dosc sztywnej ramce, ktora potrzebuje z gory zdefiniwanych kosztow, terminow oddania, zakresu zmian, z gory okreslonego przadzialow prac dla osob w zespole, i calej masy innych z gory przewidzianych rzeczy. Ta ramke mozna co prawda usprawniac jednak wiaze sie to z praca w high tech czyli z ludzmi!
A gdyby tak zamiast myslec o kosztach pomyslec o ciaglych inwestacjach (brzmi troche inaczej)
Zamiast wersji i realeas'ow zalozyc ze produkt niegdy nie bedzie zakonczony za to ciagle rozwijany, ulepszany, malymi kroczkami.
Zamiast z gory okreslonego zakresu bedzie swiadome i ciagle odkrywanie nowych wartosci o jakie mozna go wybogacic, wsparte uczeniem sie w trakcie i umiejetnoscia obchodzenia sie z tym co jeszcze nieznane.
Zamiast zarzadzania zasobami (czyt. ludzmi) starac sie utrzymac balans miedzy tym co powinno zostac dostarczona, a tym ile jestesmy w stanie wytworzyc...

Ta, akurat, pitu pitu bedzie wiosna... juz to widze, ze to moze tak dzialac.

No i tu mozna przypomniec to co Jeff De luca powiedzial:

"I’m saying that
the Agile methods are more suited to types of people
and organisational cultures than types of project.”