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

Wymowne nazwy metod i kontekst.

Metoda malych kroczkow wprowadzam do kodu, z ktorym na codzien pracuje pewne konwencje. Piszac testy staram sie nazwac metode testowa tak aby w pewien sposob oddala kontekst testu. Jednak na nic te konwencje jesli tylko ja bede ich uzywal. Wiec pokazalem jednemu koledze moj kod z takimi dlugasnymi nazwami metodami (okolo 100 znakow na nazwe) i poprosilem o komentarz. 100 znakow! WTF! No wybacz, sa taki jezyki (nie programowania), ktore potrzebuja duzo miejsca. Podobno jezyk finski przebija wszystkie.

zwracaTrueDlaProcesowZewnetrznychTechnicznieZwalidowanychWersjonowanieRozpoczete

No wiec pokazje koledze pierwsza motode.... a on czytajac ja w polowie dostal stackoverflow. Czyta drugi raz i znowu. Mowi do mnie, ze to nie przejdzie, ze to do dokumentacji, ze jak dla niego 3 wyrazy i basta. Na koniec podkreslil jeszcze dobitnie, ze to za duzo. Sie zdziwilem, ze tak od razu, ze sie nie reebotuje i nie walczy no ale coz. Dla mnie jego zdanie jest wazyne bo przeciez na jednym kodzie pracujemy. Staram sie jednak mu pomoc i go zachecic. Czytam mu nazwe metody i robie przerwy. On to zwuwazyl i mowi mi, ze z tymi przerwami juz kmini ale ich w nazwie nie widzi. No wiec edytuje kod:

zwracaTrue_DlaProcesowZewnetrznych_TechnicznieZwalidowanych_WersjonowanieRozpoczete

Kolega jeszcze sie krzywi, no jest lepiej ale. Pokazuje mu inna, stara nazwe metody testowej:

rodzajSourcinguZmieniony

i pytam czy ta nazwa mu cos mowi. Kolega zaczyna parsowac, glowi sie, patrzy w kod (zaslonilem mu na chwile ;)). No nic, z samej nazwy metody nic nie wyprodukuje, nie wie w ktorym kosciele dzwoni. Odslaniam kod testu. W sumie pogorszylo tylko sprawe :D
No ale nie cisne na sile. Skoro jemu trudno to odczytac i woli w dokumentacji to mu pokazuje dokumentacje klasy i szeroko opisan kontekst. Swieteni, robi sie jasniej. Zmarszczki na czole powoli sie prostuja ( mam nadzieje, ze pod czaszka nastepuje proces odwrotny). W powietrzu czuc porozumienie. No to ide za ciosem. Cialo metody:

// GIVEN
wstepny kontekst, setup, ustawienie stanu systemu
// WHEN
zdarzenie faktycznie testowane (np. wywolenia metody)
//THEN
sprawdzenie wynikow tesotwanej metody, asercja

I tu pozytywna reakcja. Weszlo jak w maslo, sa pochwaly, jest dobrze. Rownoczesnie patrzymy na inne metody testowe napisane dawno temu. Czy ktos myslal kiedys o tym, ze inni beda je czytac szukajac powodu defektu? Czy ty myslisz o tym, piszac kod?

water-scrum-fall to norma

Goraco polecam tekst o water-scrum-fall oraz dyskusje czytelnikow jakie mozna znalezc pod artykulem na infoq.

Zajawka na infoq
http://www.infoq.com/news/2011/12/water-scrum-fall-is-the-norm

Tekst w sdtims
http://www.sdtimes.com/content/article.aspx?ArticleID=36195&page=3

Opracowanie
http://www.cohaa.org/content/sites/default/files/water-scrum-fall_0.pdf

Crowdsourcing w tlumaczeniach

Jakis czas temu zabralem sie za tlumaczenie opowiadania na temat Real Options. Jest to swietny przyklad crowdsourcingu i sily jaka mozna uzyskac z spolecznego zaangazowania ludzi. Nie jest to w sumie nic nowego, m.in. OSS od dawna powstaje w podobny sposob. Samo pojecie nie podoba mi sie. Owszem jest cool, jest marketingowe jednak gubi sie w nim istota. W tlumie najcenniejsze sa jego skladowe, ludzie. Mozliwosc czerpania z ich wiedzy i doswiadczenia - nieoceniona plastycznosc mysli, ciagla krytyka oraz dostepnosc 24/7. Wiec na potrzeby marketingu crowdsourcing, a jak dla mnie to ludzie.

O estymacji

Koncze pisac specyfikacje, a co sie z tym wiaze zblizam sie do aktualizacji wstepnych oszacowan.
Podczas rozmowy z jednym z kolegow z projektu na temat tych wlasnie oszacowan uslyszalem cos czym chcialbym sie podzielic.

"Prognozowanie jest trudne zwlaszcza jesli chodzi o przyszlosc."

"Dlaczego nasz leader prosi nas co piatek o aktualizacje oszacowan?
On gra w totolotka i uwaza, ze jestesmy najlepszym generatorem liczb losowach."

Ha ha ha ha...

Po co to cale szacowanie?

W uproszczeniu szacowanie to okreslanie przyblizonej wartosci jakiejs wielkosci przy posiadaniu niepelnych danych.
Spotykamy sie z nim caly czas. Kiedy zony gotujac obiad dzwoni do meza wracajacego z pracy i pyta: "O ktorej bedziesz w domu?" prosi go o oszacowanie czasu jaki zajmie mu dojaz. Odpowiadz jaka udzieli obarczona jest bledem nawet jesli uda mu sie przybyc na czas.Co z tego, ze maz ma super szybka fure jesli nie wie bidulka, ze dwa skrzyzowania dalej byla stluczka i objazd nie jest mozliwy. Co to spowoduje w konteksie rodzinnego obiadu? To zalezy czy maz zadzwoni do zony i zaktualizuje wczesniej przekazane jej informacje.Moze jednak zalozyc, ze jego super szybka fura nadrobi stracony czas na kolejnym etapie drogi do domu i w zwiazku z tym, zakladajac, ze nic dodatkowo nie zakluci jego jazdy, nie ma sensu dzwonic i zawracac zonie glowy. Brzmi znajomo?

Wracajac do tematu: Po co to szacowania?
Odpowiedz zalezy w duzej mierze od punktu widzenia. Inaczej odpowie na nie malo doswiadczony pracownik, inaczej stary wyjadacz, ignorant, pracus, a jeszcze inaczej ten, ktory pilnuje aby zadania zostaly zrobione dobrze, w budzecie i na czas np. team leader.
No wiec zapytalem kilka osob i takie oto otrzymalem odpowiedzi.

• Malo doswiadczony pracownik: Ktos potrzebuje cos zaplanowac i kaze mi to robic wiec to robie.
• Stary wyjadacz: kierownictwo wciaz liczy, ze cos na tym projekcie zarobi. Podaje im co jakis czas nowe szacunki, a oni obliczaja to swoje cos.
• Ignorant: kaza mi to robie ale i tak zawsze wychodzi inaczej.
• Pracus optymista: naanalizowalem sie, naliczylem i na koncu przestraszylem, obetne troche zeby szef sie nie wkurzal.
• Team leader: zeby moc cokolwiek zaplanowac. Praca Henia zalezy od pracy Piotrka, praca testerow zalezy od pracy programistow, programistow od analitykow itd. no i jeszcze ludzie chce miec jakies wakacje (sic!), a klient pyta wciaz kiedy bedzie mogl uzyc zamowiony produkt.
  

Pytanie "Po co to szacowanie?" nurtowalo mnie czesto w momentach kiedy wiedzialem, ze wymagania lub specyfikacja sa dziurawe. No po co kaza mi to szacowac terazprzeciez za 2,3 dni dojdzie nowe wymaganie, cos sie zmieni w specyfikacji i trzeba bedzie robic to na nowo. To szacowanie to marnowanie czasu. Trzeba jakis czas poczekac, az temat dojrzeje i wtedy.... No wlasnie wtedy, "wtedy" jest tu kluczowym slowem. Zamiast zastanawiac sie kiedy bedzie to odpowiednie "wtedy" przyjmijmy, ze "wtedy" oznacza teraz. I zabierzymy sie do pracy.

Estymacja to zawsze duze wyzwanie, zwlaszcza kiedy dodamy do niej takie czynniki jak:

• nieznajomosc lub slaba znajomosc technik stosowanych do estymacji
• nieznajomosc lub slaba znajomosc domeny problemu
• niedokladnie zdefiniowane wymagania
• zaleznosc pomiedzy czesciami wykonywanymi przez rózne osoby. grupy, programy
  

Zbyt szczególowa analiza wymagan, zaleznosci i ciegle zmiany moge sparalizowac estymacje i moze ona niezostac ostatecznie zrobiona. Z drugiej strony moze sie okazac, ze estymacja byla zbyt pobiezna, optymistyczna co sprawilo, ze pewne sprawy zostaly pominiete.

Jak sobie z tym poradzic? Jak wkoncu szacowac zeby to mialo sens.

Po pierwsze trzeba to ciagle robic i uczyc sie na popelnionych bledach.
Mozna tez pomoc sobie okreslajac jakie szacowanie w danym momencie ma sens.

1. Szacowanie rzedu wielkosci (porównywanie z czyms podobnym) - odchylenie 2 lub 3 krotnosc rzeczywistej wielkosci. Mozna powiedziec, ze szacowanie rzedu wielkosci to zadne szacowanie. W tym przypadku jest to jedyne oszacowanie na którym mozemy sie jakkolwiek opierac. Ma ono znaczaca wartosc dla organizacji oraz zespolu projektowego poniewaz daje pewne wytyczne dla projektu jesli chodzi o czas, ludzi i pieniadze. Lepiej wiedziec, ze cos zajmie 4-6 miesiecy niz nie miec bladego pojecie ile to zajmie.
   
2. Zgrubna estymacja - odchylenie 50-100% rzeczywistej wielkosci Pracujesz z dobrze zrozumianymi wymaganiami, oraz jest ktos dobrze obeznany z domena problemu i problemami technicznymi, które moga sie pojawic.
   
3. Estymacja dokladna: odchylenie 25-50% rzeczywistej wielkosci. Jestes bardzo obeznany z tym co ma byc zrobione i robiles to juz wiele razy wczesniej. Takie podejscie nadaje sie do czynnosci wiele razy powtazanych (np. w utrzymaniu aplikacji) gdzie rozwiazania sa znane lub przy dodawaniu dobrze znanej i rozumianej funkcjonalnosci, która juz wczesniej byla dodawana.
   

W efekcie otrzymamy oszacowanie, ktore obarczone jest jak zawsze bledem. Patrzac bardzo ogolnie blad ten moze nazywac sie:

• przeszacowanie - wtedy moze sie okazac, ze do realizacji zostanie wziety ktos inny (inna firma lub inny pracownik) lub, ze w rezultacie pewne wygania nie zostana spelnione z braku czasu, zasobow. Redukcja wymagan moze wystapic juz na wstepie.
• niedoszacowanie - wymagania zostana zaakceptowane jednak niedostateczna ilosc czy czasu lub zasobów spowoduje brak ich realizacji. Redukcja wymagan nastpuje w pozniejszej fazie projektu, potrzeba przeplanowac prace ludzi, zespolow, termin dostarczenia produktu do klienta jest niedotrzymany.
  

Podsumowujac.
Warto pamietac, ze cale to szacowanie nie sluzy do przewidywania przysylosci ale pomaga dowiedziec sie jakie decyzje nalezy podjac obecnie. Np. obecnie nie trzeba zmieniac planu i podzialu zadan poniewaz ty wciaz twierdzisz, ze sie wyrobisz, a przynajmniej nie sygnalizujesz, ze cos idzie nie tak ;)

Pani Linda Rising powiedziala bardzo ladne zdanie, ktore pasuje do tematu szacowania:

Podejmuj zdecydowane decyzje ale nie trzymaj sie ich kurczowo, dopuszczaj zmiany.

O tym napisze nastepnym razem.

Szacowanie - od czego zaczac?

Szacowanie to moj temat nr 1 na rok 2011. Naczytalem sie sporo, naszacowalem i w pracy i poza, napopelnialem bledow, nawalilem wiele razy. Dyskutowalem z kilkoma osobami live, na forach, grupach i chcialbym to podsumowac. Najbardziej interesuje mnie poznanie mechnizmow psychiki czlowieka, ktore maja zasadniczy wplyw na szacowanie. Kolejny aspekt to sprawa swiadomosci jak moje szacowanie wplywa na to co robia inni czyli poszerzenie horyzontu i uswiadomienie sobie pewnych waznych zaleznosci. Na koniec wspomne ogolnie o pewnych metodach pomagajacych w szacowaniu.

Zacznijmy od tego oto meterialu. Linda Rising bardzo ciekawie tlumaczy skad biora sie niektore bledy oszacowan i jak sobie pomoc:
Linda Rising: Deception and Estimation: How We Fool Ourselves. cz1 cz2

Testy Alibi

Spotkalem sie dzisiaj z nowym rodzajem testow. Tak mi sie on spodobal, ze zechcialem wspomniec o nim na blogu. Chodzi o Testy Alibi. Moja definicja tego pojecia jest nastepujaca:

Testy Alibi - to takie testy, ktorych glownym celem jest istnienie samo w sobie.

Jesli ktos pyta czy do danego kodu napisane sa testy to w przypadku testow alibi mozna odpowiedziec, ze oczywiscie tak. Najlepiej odpowiedziec na tyle stanowczo zeby nie otrzymac kolejnego pytania na ich temat.

S.O.L.I.D i refaktoring

Wszystkim zainteresowanym tematem polecam mocno wg mnie dobre darmowe e-booki traktujace temat SOLIDnego projektowania i refaktoryzacji.

Po co nam te javadocki, komantarze, etc...

Grzebiac w kodzie znalazlem kilka metod opatrzonych takim oto komentarzem:

"Life is too short..."

Autor mial zapewne wazniejsze rzeczy do robienia podczas pisania kodu i niepisania javadoca. Ocenil sytuacje i stwierdzil, ze szkoda jego cennego czasu, jego zycia na takie pierdoly. Po jakims czasie ja trafiam na to miejsce starajac sie zrozumiec jak cos dziala. Co z moim czasem, z moim zyciem? Patrzac z szerszej perspektywy, ktos bedzie musial za to zaplacic i z pewnoscia nie autor, ktory zaoszczedzil swoj czas.
Podumowujac:
Kod wiecej razy czytamy niz piszemy. Dlatego tak wazne jest zeby juz napisany byl czytelny i zrozumialy. Wszystkim piszacym kod polecam ksiazke "Clean Code" by Robert C. Martin (Uncle Bob).

Czy znasz wystarczajaco dobrze narzedzia, ktorych uzywasz?

Jaka jest twoja odpowiedz na to pytanie? Nie badz taki surowy ;) przeciez jestes wazna, nieprzecietna osoba! Jak trzeba bedzie to nauczysz sie wszystkiego w 2 dni.

Zaczne moze od tego, ze glownym powodem mojej sympatii do szeroko pojetego tematu komputerow i nauki o nich jest to, ze komputery moga wykonac szybko pewne zadane przez ludzi zadania. W ten sposob moga nam ulatwic zycie. Ulatwic zycie znaczy w pewnych sytuacjach oszczedzic nasz cenny czas.

Spojrzmy teraz na pewien zespol programistow. Jest ich 6. Codziennie spedzaja w pracy 8-9 godzin. Z tego efektywnie pracuja 4-6. Tu wtrace, ze blokowanie dostepu do pewnych zasobow internetu wcale nie poprawia, a czesto pogarsza ten wynik. Dla uproszczenia przyjme ze kazda osoba pracuje 5 = (6+4)/2 godzin dziennie. Do pracy uzywaja pewnego zbioru narzedzi. Nie znaja jednak wielu zastosowan tych narzedzi. Znaja pewne ich zastosowania i do tego maje wlasne przyzwyczajenia. Co sie stanie jesli pokazesz im jak uzywac narzedzi tak aby zaoszczedzili 10 minut dziennie?

10 min * 6 osob *20 dni pracy na miesiac * 12 miesiecy = 14400 minut
14400 minut / 60 minut / 8 godzin deklarowanej pracy na dzien = 30 dni
14400 minut / 60 minut / 5 efektywnej pracy = 48 dni!

Tak. Kazdy latwo sobie dalej przemnozy ile to pieniedzy (programisci pomnoza przez p, managerowie przez p*m, gdzie m>8). Jaki z tego wniosek?

Doskonalenie rzemiosla do pewnego poziomu oplaca sie.

W kolejnych postach opisze historie programisty Henia, ktoremu udalo sie wprowadzic pewne usprawnienia w projekcie, w ktorym pracuje. Zastanowimy sie tez ile oszczednosci moglo to wprowadzic.

A ile oszczednosci moze to wprowadzic w twojej pracy, niekoniecznie zawodowej?

Monitorowanie hibernate

Uzywasz hibernate i chcialbys dowiedziec sie:

• jakie zapytania sa wykonywane przez hibernate
  
• ile razy zapytania sa wywolywane
  
• ile trwaja konkretne zapytania
• ...
  

Polecam to oto narzedzie: http://hibernate-jcons.sourceforge.net/. Dla mnie bomba !

Popatrzec na program okiem uzytkownika

Niessamowite doswiadczenie mialem w piatek. W ramach wdrozenia wyslany zostalem wraz z kolega z projektu na szkolenie dla uzytkownikow systemu, ktory programujemy. Grupa szkoleniowa to osoby z dzialow zakupow +my.
Spotkanie z uzytkownikami softu, ktory klepie to moje zawodowe marzenie. Sugerowalem przelozonemu cos takiego jednak okazalo sie, ze jest inna grupa za to odpowiedzialna i w sumie nikt nigdy czegos takiego nie robil.... musze bardziej nad nim popracowac :)
..wiec stalo sie, jestem na szkoleniu.
Postanowilem nie proznowac i notowalem wszystkie obserwacje uzytkownikow. Pytalem jak klikaja, czego uzywaja, czego nie uzywaja (wow tu bylem mocno zaskoczony), co jest dla nich trudne. Notowalem wszystkie uwagi, na temat kolorow, ukladu, niejasnosci, gdzie sie gubili. Mam materialy na 2-3 misiace pracy. To byl czad! Kiedy pokazywalem niektorym osobom jak cos mozna lepiej zrobic, byli zachwyceni. Co za soft! Dla nich to cenne informacje pozwalajace oszczedzic czas i usprawnic prace. Dodatkowo poznalem lepiej proces zakupow. Uslyszalem wiele przykladow z zycia codziennego co dalo mi nowe spojrzenie nie tylko na sam system ale ogolnie na prace, ktora wykonuje. Jak wazne jest dobre zrozumienie tematu, przygotowanie uzytecznego rozwiazania i komunikacja.
Takie spotkanie polecam kazdemu kto pisze soft dla ludzi.

Prawie jak SVN :)

Jesli pracujesz z CVS to masz szanse natknac sie na taki oto problem:
Programista Henio przychodzi do pracy i synchronizuje sie z repozytorium cvs. Wszystko mu sie pieknie zbudowalo. W trakcie testowania czegos zauwaza, ze cos jednak w programie dziala nie tak jak wczoraj. Hmmm, pewnie ktos cos pozmienial. Zaraz sprawdzimy. I tu Henio sie orientuje, ze standardowy plugin w jego eclipsie nie pozwala pokazac jakie pliki zostaly zmienione w konkretnym commicie. Ojjojjoj jak dobrze bylo uzywac svn. I jak sie teraz dowiedziec kto, co i kiedy zacommitowal.

Heniowi pyta wujka Googlek o rade, a on wskazuje na ten oto adres:
Eclipse CVS ChangeLog Plugin. Henio instaluje plugin w swoim eclipse, wszystko ladnie dziala. Teraz juz wiadomo kto co ostatnio commitowal, latwiej znalez co zostalo popsute. CVS stal sie prawie jak SVN tak na 5 minut.

Czytanie między wierszami ma swoje minusy

Dużo dobrego słyszałem o polskich programistach, którzy z byle jakie specyfikacji potrafią zmajstrować solidny program. Jak oni to robią? Z tego co udało mi się zaobserwować stosuję metodologię CzytajMiędzyWierszami. A kim są ci, którzy bardzo lubią tą metodologię? Są to ludzie, którzy z różnych powodów opracowują niestarannie wymagania klienta, piszą nieprzemyślaną specyfikację, później to zatwierdzają i przekazują dalej (cokolwiek to znaczy).

Oto programista Henio dostaje do wyklepania CRa. Widzi jego opis zarejestrowany w BTS, widzi komentarze, jakieś dodatkowe wyjaśnienia, linki do UseCase'ów, widzi maile z kolejnymi potwierdzeniami od specyfikatorów i testerów, wszystko jest ok. Henio jest pilnym programistą i już niejedno na swojej programistycznej ścieżce widział. Po pierwszym czytaniu Henio widzi, że to co jest w BTS i to co jest w UseCase'ach to nie to samo. Henio zna metodologię CzytajMiędzyWierszami wie kiedy jest deadline i wie jeszcze, że żeby odkręcić te kilka szczegółów trzeba porozmawiać (Henio wie, że maila wysyła się, kiedy nie trzeba czegoś szybko załatwić) z 3 osobami, wyjaśnić im co jest nie tak, poprosić o komentarz, posłuchać ich wyjaśnień i dostać od nich poprawione wersje. Do tego wszystkiego dochodzi jeszcze pośrednio kierownik projektu, który zablokował pliki, ponieważ dostał informację, że wszystko jest zapięte. Tak się składa, że do pokoju Henia przyszedł Zenek. Henio przedstawił sprawę Zenkowi i zapytał co by Zenek zrobił. Zenek też zna metodę CzytajMiędzyWierszami do tego zna jeszcze NieCzytajMiędzWierszami. Zenek pyta Henia co się stanie jeśli CR zostanie wyklepany i pójdzie do testów. No jak to co? Testerzy przeczytają specyfikację i go przetestują, tzn przetestuję część. To co stoi między wierszami pominą. W końcu po to mamy specyfikację i wymagania, żeby na nich polegać. CR trafi na produkcję. Przyjdzie kilka bugów, się poprawi i jakoś będzie - pochodna code and fix. Ktoś nie dostanie na czas swojego samochodu, ktoś dostanie paczkę z tygodniowym opóźnieniem, innych 1000 osób będzie musiało dalej drukować i pewne dokumenty zamiast móc je przekazywać drogą elektroniczną. No chyba, że Heniu poświęci swój cenny czas, jaki spędza w pracy na zrobienie czegoś naprawdę dobrze i na poziomie. Co zrobi Heniu? A co zrobisz ty w takiej sytuacji?

Mylyn i code review

Generalnie jestem zwolennikiem tekiego code review gdzie nie ma wyznaczonego jednego guru, ktory to robi. Ludzie w projekcie sprawdzaja nawzajem swoj kod. Guru patrzy na wazniejsze kawalki. Zalozmy jednak, ze ty - guru yoda - jestes namaszcony zeby robic co jakis czas review swiezego kodu. Pisze go 10 koderow. Jak w prosty sposob przekazac tym koderom swoje uwagi i nie namacic w kodzie? Jak wskazac im te miejsca, ktore trzeba przepisac. Moze Excel ;P moze wstaei komentarze do kodu..
Tu z pomoca przchodzi znowu Mylyn! Oto super prosty i skuteczny, sprawadzony przez wielu przepis, a juz jak grupa jest rozproszona to nie ma lepszego...
Otoz kazde review traktujesz jako odrebne zadanie mylyna. Aktywujesz zadanie, przegladasz kod napisany przez Martina, a mylyn tworzy kontekst. Zeby nie smiecic w kodzie zbedynmi komentarzamie dodajesz bookmarki. Na koncu zapisujesz nowe zadanie jak np. bug przydzielasz Martinowi i dodajesz do niego utworzony przez mylyna kontekst. Martin przychodzi do pracy odpala swojego sexclipsa i widzi na swojej liscie nowe zadanie. Aktywuje je, otwiera mu sie kontekst i juz wie na co ma zwrocic uwage. Czyz to nie super narzedzie ten mylyn !!?

W mylynowym kontescie nie widac wszystkich plikow

Po co widziec te wszystkie pliki? Po to sa rozne kontesty zeby latwiej bylo sie w nich poruszac (moje proste wyjasnienie). To kwestia przestawienia sie na Task Focused Programming. Jednak moj kontekst sie szybko "brudzil".
Byly ku temu dwa powody:

1. A to w trakcie pracy nad problemem A zapragnalem na chwile wskoczyc w problem B
2. A to ktos przyszedl do mnie, zeby sie o cos spytac w kodzie

Wylaczenie aktywnego zadania powodowalo, ze wszystkie edytory byly tez zamykane. Wtedy ja szukalem tego co mi bylo potrzebne. Ewentualnie nie deaktywowalem zadania nad ktorym pracowalem i wtedy kontekst "wybogacal sie" o rzeczy z nim niezwiazane. Znalazlem na to 2 rozwiaznia. Oto one:
Rozwiazanie 1. Utworzylem sobie nowe lokalne zadanie o nazwie WTF (wiadomo). Mozna tez AnyOtherBusiness lub DevNull jak kto woli. Ilekroc ktos ma do mnie jaki biznes przelaczam sie na moje specjalne smietnikowe zadanie i szafa gra.
Rozwiazanie 2. Zauwazylem ze w widoku "Projec Explorer" kiedy zatrzymam myszke na ikonce projektu lub pakietu pojawia sie obok niej taki maly "+". Po nacisnieciu dostaje sie pelny widok jednak nie jest on dodawany do kontekstu dopukni nie otworze pliku.
Rozwiazaniem podzielilem sie z kolega obok i bardzo mu sie spodobalo.Tteraz obaj mamy zadanie WTF na naszych listach :)

Przestaje narzekac na waterfall - serio !

People matter! No ale jak people decyduja zeby olowek ostrzyc widelcem to.... to stwierdzenie "People matter!" dopiero nabiera mocy, znaczenia i .... kto wie czego jeszcze. A teraz do rzeczy.

Dla wszystkich narzekajacych na waterfall:
http://www.scrumology.net/2011/07/19/stop-blaming-waterfall/
Nastepnie obowiazkowo!:
http://www.thoughtworks.com/the-new-methodology
A potem dyskusja z kolegami i kolezankami przy herbacie. People matter!

Testy automatyczne - oszczedzaj cenny czas nie tylko programistow

Jak najszybciej sie przekonac, ze automatyzacja testow sie jednak oplaca (oplaca=generuje mniejsze koszty)? Trzeba policzyc ile czasu istoty ludzkie spedzily recznie testujac. Nastepnie przemnozyc to przez sume planowanych releasow w roku oraz srednia ilosc hotfix-releasow (na bazie wczesniejszych doswiadczen) w roku. W ten sposob uzyskana wartosc nalezy przyrownac do budzetu jaki jest planowany na wprowadzenie testow automatycznych (tu sa wszelkie licencje na software, koncepcje, programowanie, wdrozenie i utrzymanie testow). Na koniec nalezy wyciagnac wnioski.
To oczywiscie duze uproszczenie jenak tak to mniej wiecej wyglada.
Warto przy okazji wziac pod uwage bardzo kosztowna operacje zmiany planow w razie kiedy produkt nie nadaje sie do testow a jednak na testy idzie. Dzieje sie tak zazwyczaj z powodu niewykrycia, ze cos co powinno dzaialc nie dziala. Zespol programisto oddaje funkcjonalnosc do testowanie zespolowi testerow. Cale przekazanie zostalo miesiac wczesniej zaplanowane i ustalono kto co kiedy robi. Nagle okazuje sie, ze testerzy nie moga testowac bo pewien element funkcjonalnosci nie dziala. STOP!
Wyobraz siebie co dzieje sie dalej - to zalezy od tego co juz wczesniej widziales.

Automatyzacja nie dotyczy tylko testowania. Automatczny proces budowania, deployment, weryfikacja.. Jest wiele miejsc gdzie mozna oszczedzic ludzki czas.
Z drugiej strony nie wszystko da sie zautomatyzowac, co wiecej nie wszysto nalezy automatyzowac.

Byc testerem, pierwsze wrazenia...

Od kilku dni wspieram zespol testerow. Ktos pomyslal, ze bedzie to dla mnie dobra okazja do zapoznania sie z funkcjonalnoscia systemu. No wiec testuje i wspolczuje wszystkim testerom klikajacym codziennie po raz setny ten to smo GUI. Robie przy tym notatki z uwagami co do procesu. Nie moge powiedziec, ze sie niczego ciekawego nie ucze. Jednak taka praca powinna byc w jak najwiekszym stopniu zautomatyzowana tak zeby ludzie, majacy mozg, wyobraznie i inne niessamowite atrybuty mogli zajmowac sie wlasciwymi dla nich rzeczami. W ksiazce Pragmatic Project Automation mozna znalezc akapit pod tytulem:
Why should automate something? - Bardzo jasno wyjasnine.