Artykuł o programowaniu w parach

15 stycznia 2012

W piątek miałem okazję przeczytać bardzo ciekawy artykuł o programowaniu w parach.

W skrócie: Opisany zespół, miał największą wydajność i najmniej bugów gdy:

  • Historyjki były dewelopowane przez programistów o najmniejszej wiedzy domenowej (w obszarze danej historyjki)
  • Historyjki były dewelopowane przez pary, które same wybierały nad czym chcą pracować
  • Historyjki nie były przypisane konkretnym osobą, cały zespół był odpowiedzialny za historyjkę
  • Pary rotowały co ~2 godziny. (Osoba która była dłużej w parze opuszcza parę).
W  podobny sposób pracowałem w czasie swojej praktyki w Pinesoft. Po 2 pełnych cyklach Pomodoro rotowaliśmy pary. Praca była bardzo intensywna, ale mega satysfakcjonująca.
Gdy uda mi się przekonać mój obecny zespół, wypróbujemy powyższy system z rotowaniem par po pełnym cyklu pomodoro (około 2h).
A Ty jakie masz doświadczenia z pair programmingiem?

Praktyki stosowane w moim zespole

15 stycznia 2012

W ramach „Poranku z Nokią i z SEnSem” poprowadziłem na PWr skierowany do studentów  wykład o praktykach stosowanych w moim zespole.

Ponieważ to jakie praktyki najlepiej się sprawdzą zależy od naszego kontekstu, zacząłem od opisania sytuacji mojego zespołu.

Zespół w którym jestem jest

  • mały (~7 osób)
  • wszyscy siedzimy w jednym pokoju
  • mamy wewnętrznego klienta / product ownera. Siedzi z nami na tym samym piętrze i ma dla nas czas
  • tworzymy ważny, ale wewnętrzny system

Dla każdej praktyki powiedziałem:

  • na czym polega
  • dlaczego/po co ją stosujemy
  • „dobre rady”

Oto lista praktyk, które aktualnie stosujemy w moim zespole:

Przeczytaj resztę tego wpisu »

Refaktoryzując test do String Kalkulatora

29 grudnia 2011

W ramach eksperymentu nagrałem wideo, w który refactoruje test do String Kalkulatora.

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)
Klika używanych skrótów:
  • ctrl+y – usuwa aktualną linie
  • ctrl+c – gdy nic nie jest zaznaczone, kopiuje aktualną linię
  • alt+ctrl+v – wyciąga zaznaczone wyrażenie do zmiennej
  • ctrl+shift+f10 – odpala testy
  • ctrl+w – rozszerzające się zaznaczenie (naciśnij kilka razy, a zaznaczony obszar będzie rósł)
Kod który refaktoryzuję, pochodzi z mojego innego wpisu (Refactor my code step by step).

Nowy Rok 2012! :)

26 grudnia 2011

Nawiązując do tradycji z poprzedniego roku czas na małe „zawodowe” podsumowanie i plany na następny rok :)

W roku 2011

Udało mi się:

  • W lutym zostać magistrem – uff! :)
  • Pracować w świetnym zespole!
  • Nauczyć się nowych rzeczy o testowaniu.
  • Pojechać jako wolontariusz na QCon w Londynie, XP w Mardycie i GOTO w AArhus
  • Być koordynatorem wolontariuszy w czasie konferencji ALE w Berline
  • Zorganizować razem z Markusem lipcowe CodeRetreat w Berlinie
  • Zorganizować i poprowadzić razem z Markusem CodeRetreat w Berlinie w ramach światowego dnia CodeRetreat w grudniu
  • Prowadzić w Nokii cotygodniowe Coding Dojo
  • Poprowadzić mały warsztat na temat „1-1 feedback” dla innego zespołu w Nokii. Poprowadzić Extreme Startup w ramach dojo.
  • Zapisać się i wygłosić 3 mowy w berlińskim klubie Toastmasters
  • Uczestniczyć w kilku spotkaniach #xtcb (Extreme Tuesday Berlin)
  • Rozpocząć naukę Scali i Rubiego
  • Zostać certyfikatowanym programistą Springa
  • Przeczytać: Release It, Presentation Zen, The Clean Coder, Managment 3.0, Kanban, Specification By Example, Lean Startup i rozpocząć kilka innych książek.
  • Poeksperymentować z Kanbanem.
  • Założyć konto na githubie
Nie udało mi się:
  • Czytać 1 książki na miesiąc
  • Pojechać na Agile2011 do stanów ani wziąć udział w Agile Testing Days w Berlinie
  • Zostać prelegentem na konferencji
  • Nauczyć się niemieckiego na tyle, by móc biernie uczestniczyć w spotkaniach prowadzonych po niemiecku.
W roku 2012 chciałbym:
  • Pracować z ludźmi, od których mogę się bardzo dużo i szybko uczyć (tak jak to było w roku 2011)
  • Pojechać jako wolontariusz na QCon i wziąć udział w 2 innych dużych konferencjach (XP? GOTO? ALE?)
  • Zorganizować coś otwartego w Nokii, np. co 2 tydzień robić otwarte Coding Dojo dla ludzi z poza firmy
  • Co najmniej raz w miesiącu brać udział w spotkaniu społeczności w Berlinie
  • Wziąć udział w CodeRetreat jako uczestnik
  • Wygłosić 6 mów w Toastmasters. Wziąć udział w konkursie na najlepszą mowę w klubie.
  • Czytać jedną książkę na miesiąc
  • Spopularyzować refactor-my-code step by step
  • Poprowadzić wykład dla studentów
  • Założyć anglojęzycznego bloga
  • Nauczyć się biegle innego języka niż Java (Ruby?).
  • Oglądać co najmniej jedną prezentację na tydzień (np. z infoq, ted)
  • Spróbować wcielić w życie koncepcję lunch with a stranger w pracy.
  • Zorganizować mini konferencję w pracy.
  • Stworzyć „continuous delivery pipeline” dla projektu, w którym teraz pracuję
  • Certyfikować się w jakieś kolejnej technologii
Jakie są Twoje plany na rok 2012? :)

Refactor my code step by step!

27 listopada 2011

Niedawno rozmyślałem nad skryptem w Ruby, który napisałem. Nie byłem z niego zadowolony. Co prawda działał, ale był dość „brzydki”.

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