Piotr Gabryanczyk
To ambitny plan przedsiewziales Piotrze. Mysle jednak ze tutaj nie
ksiazka, ale przykladem trzeba uczyc innych.
Co do ksiazek, to moze nie do samego TDD, ale bardziej ogolna: Practices
of an agile developer.
Cheers,
Krzysztof
http://kozmic.pl
Gabryanczyk Piotr pisze:
zgadza sie, ale mimo wszystko polecam kenta becka 'tdd by example' :)
pzdr
--
Paweł Rozynek
Nie wiem, czy słyszeliście o człowieku, który się nazywa Clarke Ching.
Jest on trenerem i consultantem w Agile (bardzo ogolnie
powiedziawszy).
Pisze on ksiazke, ktora podejrzewam bedzie bardzo ciekawa, pisze tez
bloga - z reguly w stylu:
"...dziś widziałem dwa gołębie, ciekawe jakich metodologii gołębie
używają w swoim życiu..." czy też "kupiłem IPhone'a, ale klawiatura
zasysa na maksa, więc wymieniam na Black Berry Bold".
Ma jednak kilka bardzo dobrych postów, wygłasza też na różnych
konferencjach. Był nawet dwa razy u nas w klubie... Jednego razu
zaprezentował bardzo świetne i przekonywujące wprowadzenie do TDD.
Żeby zaprezentowac innym, ja polecałbym najpierw próbe z kilkoma
znajomymi, którzy nie bardzo wiedzą o so hozi. Ważne jest aby się
trzymac reguł, nie starac sie filozofowac i wykonywac więcej niż jeden
krok w danym czasie. My po jego prezentacji spróbowaliśmy zrobic takie
samo cwiczenie w pracy, ale nie wyszło zbyt dobrze, bo ludzie zamiast
trzymac się zasad, starali się rozwiącac problem holistycznie, co nie
bardzo działa w TDD, gdzie wszystko się robi małymi krokami. Do
całkowitego cwiczenia potrzeba 1h do 1h 30m, ale zapewniam że
przeprowadzone dobrze nie zostawia suchej nitki na managierstwie i na
pytanie czy TDD ma wartośc, wszyscy chórem odpowiedzą, że ma.
Najfajniejsze jest to, że do cwiczenia potrzeba wyłącznie Excela (nie
wiem czy OO Calc by się nadał), bo pisze się prostą procedurę do
zamiany numerów arabskich na rzymskie. W Excelu robi się to w Visual
Basic'u. OO też ma jakieś skryptowanie i z tego co wiem, też jest to
jakaś odmiana Basica, więc powinno byc OK. Najważniejsze jest to, aby
atmosfera była bardzo luźna i zrelaksowana. Rzucac dużo żartów, samemu
udawac nie najlepszego programiste, celowo wprowadzac bledy w kodzie
itp. Jest to kodowanie na żywca i publika od razu wyłapie pomyłki,
które od razu należy poprawiac. W ten sposob demonstrując również moc
programowania w parach czy też paradygnmat: czym więcej oczu widzi kod
na świeżo, tym lepiej. Demonstrator po pewnym czasie powinien oddac
klawiaturę komuś z widowni, tak jak w programowaniu w parach.
Wszystko powinno byc wesołe i z przysłowiowym jajem.
Po dobrze przeprowadzonym cwiczeniu, widownia powinna osiagnac stan
kodu, ktory jest calkowicie przetestowany, ktory zostal stworzony
wylacznie na podstawie testow, no i oczywiscie dzialajacy program,
ktory zamienia liczby arabskie na rzymskie, co (jesli ktos nigdy nie
robil) nie jest cwiczeniem trywialnym, zwlaszcza dla ludzi ze strony
biznesu (a taka widownie takze zakladamy). Co wiecej w cwiczeniu robi
sie tez ciagly re-factoring codu i zaufanie do poprawnosci wynosi sie
z testow, ktore pokrywaja nasz kod. Koncowe rozwiazanie jest bardzo
zwiezle, efektowne i sliczniutkie, nie najlatwiejsze w czytaniu.
Wszystkim, ktorzy chca przekonac ludzi do XP (TDD, pair programming,
refactoring) goraco polecam.
http://www.clarkeching.com/files/tdd_for_managers_and_nonprogrammers_using_excell_and_vba_final.pdf
Daniel
2008/9/20 Krzysztof Koźmic <krzyszto...@gmail.com>:
--
Daniel Drozdzewski