Sprawna Inżynieria Oprogramowania

Konferencje

noreply@blogger.com (Paweł Lipiński) — Mon, 08 Mar 2010 21:12:00 +0000

To kolejny małotechniczny wpis, ale może być dla kogoś ważny. W najbliższym czasie będzie w Polsce przynajmniej parę ciekawych wydarzeń agile'owych, więc chciałem je tu wylistować.

Najbliżej jest Zimowy AgileTuning bo już 20 marca. Nie byłem na poprzednim (i żałuję) - tym razem nie odpuszczę :-) Spotkań zwinnego światka jest w Polsce mało, więc trzeba delektować się tym co jest. Z resztą program przekonuje, że warto się wybrać.

Następnie są spotkania z Mary Poppendieck (kiedyś sprawdzałem co oznacza po niemiecku 'poppen' i odwróciłem oczy; a ten dieck do tego to już w ogóle...) - jedno we Wrocławiu (23 marca) a następne w Krakowie (24 marca). Ciekawe czy się będą od siebie czymś różnić...

Później (8-9 kwietnia) jest AgileCE. Do tego zachęcam szczególnie - nie tylko będzie masa zagranicznych prelegentów, ale również trochę naszych. Ja opowiem coś o naszych doświadczeniach bycia nearshore'owym zespołem naszego klienta.

No a potem (19-21 kwietnia) jest nasze szkolenie TDD, do zgłaszania się na które serdecznie zachęcam. Kwestie ceny i miejsca są aktualnie ustalane, do końca tygodnia powinny być już ogłoszone.

Szkolenie TDD

noreply@blogger.com (Paweł Lipiński) — Fri, 05 Mar 2010 22:27:00 +0000

Tak, wiem - dość długo nic się tu nie działo. Postaram się niedługo wrócić do częstrzego pisania.
Tymczasem ten wpis też nie ma za wiele treści, ale przynajmniej kieruje do takiego, który ma :-)

Po sukcesie szkolenia dotyczącego zwinnych metodyk planowaliśmy przeprowadzenie szkolenia z TDD. Niestety (albo stety) ostatnie miesiące były pełne pracy przeplatanej z urlopami, więc nie bardzo było kiedy. Ale nadszedł czas, żeby wreszcie to zrobić.

Tak więc niniejszym zapowiadam szkolenie z TDD - 3 dni pełne kodowania w parach, emergent design'u, dobrych praktyk, JUnit'a i Mockito, tricków klawiszowych w Eclipse i wiele wiele innych... A przede wszystkim doświadczeni prowadzący: Krzysiek Jelski (aka Uncle Cris) oraz Michał Margiel (aka Ciacho, a konkretnie Pączek*). Ja będę doglądał szkolenie głównie pod kątem donoszenia ciastek i kawy, i może czasem coś wtrącę ;-)

Szczegóły na naszym blogu firmowym (http://blog.pragmatists.pl)

*Nieaktualne gdzieś od września. Teraz to bardziej Faworek...

Po Zwinnym Szkoleniu

noreply@blogger.com (Paweł Lipiński) — Wed, 09 Dec 2009 18:14:00 +0000

Reklamowane przeze mnie jakiś czas temu szkolenie Zwinne Rozwijanie Oprogramowania odbyło się w ostatni piątek / sobotę. Zainteresowanych co dokładnie się działo i jak poszło odsyłam do naszego firmowego bloga - Studio Pragmatists.

Rekrutacja

noreply@blogger.com (Paweł Lipiński) — Mon, 16 Nov 2009 14:30:00 +0000

Rozpoczynamy w Pragmatists oficjalną rekrutację. Szczegóły tu:
http://blog.pragmatists.pl/2009/11/rekrutacja.html

TDD a czysty kod

noreply@blogger.com (Paweł Lipiński) — Sat, 14 Nov 2009 00:34:00 +0000

W miarę ostatnio na blogu Holistycznie o inżynierii oprogramowania pojawił się post o TDD i czystym kodzie. Podstawowym założeniem było, że TDD nie ma wiele wspólnego z czystym kodem, że łączenie tych dwóch rzeczy przez Roberta C. Martina zwanego czasem Wujem Bobem jest manipulacją i próbą wylansowania się. I choć Wuj faktycznie jest medialny i ma parcie na LCD, to myślę, że autor jednak trochę się tu zagalopował. Pod koniec autor zamieścił co prawda wytłumaczenie o co mu chodziło w poście, ale cyniczne żarty w jego treści spowodowały, że czyta się go jak tyradę przeciw testom jednostkowym. Co więcej wskazującą na brak praktycznego doświadczenia w takim tworzeniu oprogramowania przez jej autora, więc niestety dla praktyki tej krzywdzącą.

A że internet to wolne medium, zdecydowałem się zamieścić własny pogląd na TDD i jego rolę w zapewnianiu czystości kodu, tyle, że bazującą na paroletnim doświadczeniu tworzenia w ten sposób oprogramowania.

Czysty kod to kod czytelny. Wprowadzony przez Donalda Knuth'a termin/idea/paradygmat Literate Programming oznacza prawie to samo. Kod powinien dać się czytać jak literaturę (na tyle na ile to możliwe), powinien być jak najbardziej przejrzysty dla programisty pracującego z nim. Tylko wtedy będzie można zapewnić niski poziom błędów (wiemy co robi i rozumiemy jak to robi) i wysoką utrzymywalność (kod zrozumiały dla każdego kto go czyta). To oczywiście platoński ideał kodu, ale właśnie czysty kod, tak jak opisuje go Uncle Bob w książce Clean Code zdaje się być temu ideałowi najbliższy (przynajmniej w javie). To kod, który mówi dokładnie co robi. W metodach wyższego poziomu (zwykle o szerszym dostępie) jest kod bardziej odpowiadający na pytanie "co?" a czym niżej, tym bardziej idzie w kierunku "jak?".

Czytelny kod rzadko powstaje przy pierwszym podejściu. To naturalne, że mamy jakiś pomysł - nasze przemyślenia i doświadczenie podpowiadają nam rozwiązanie i jest ono zwykle w mało czytelnej formie. Czasem jest to paręnaście/parędziesiąt linii odzwierciedlających nasz pomysł na rozwiązanie w formie jakiegoś algorytmu. I to jest nasze pole prób i błędów. Niestety bardzo często kod pozostaje na tym etapie. Tzn. działa, realizuje to o czym akurat myślał jego autor, ale nie komunikuje jasno do czego służy. Potem dodajemy kolejne metody i klasy współpracujące z tą pierwszą i tak powstaje nieczytelna aplikacja o rozmytych odpowiedzialnościach klas i metod.

Gdyby jednak nie pozostać na poziomie poligonu, tylko spojrzeć na działający kod pod kątem jego czytelności i nadać mu zrozumiałą formę, byłby on nie tylko poprawny, ale też utrzymywalny. Gdy metody mają 2-3 linijki (czasem może 5-7) dużo łatwiej o lepsze ich rozmieszczenie, o przydzielenie odpowiednim klasom, o naturalne wyłanianie się wzorców projektowych (np. strategia, dekorator czy mediator to wzorce, które same wyłaniają się przy poprawnym rozłożeniu odpowiedzialności). Nie mówię, że pojawią się nawet jak ich nie znamy (w końcu to nie czary), ale dostrzeżenie miejsca dla nich jest dużo prostsze. Stąd też refaktoryzacja jest zupełnie nieodzowną praktyką programistyczną. Uważam, że niemożliwe jest napisanie kodu (o realnej złożoności, nie akademickie przykłady) od razu"na czysto". Najpierw realizujemy więc wymaganie, a potem za pomocą refaktoryzacji (i niskopoziomowej i do wzorców projektowych) dochodzimy do czystego kodu.

Ale zaraz, kod który piszemy realizując jakąś funkcjonalność rzadko żyje sam sobie. Prawie zawsze wchodzi w interakcję z innymi komponentami. Metody nowych klas będą wołane z zewnątrz, same obiekty tworzone w różnych miejscach i na różne potrzeby. Jak więc stworzyć strukturę klasy tak, by była łatwa w użyciu? Jak osiągnąć jednoznaczność wywołań? Jak zapewnić, że nasz kod będzie wygodny w wykorzystaniu z zewnątrz? Hm. Najprościej zasymulować wykorzystanie. Wiemy czego chcemy od obiektów jakiejś klasy, więc to po prostu napiszmy. W ten sposób powstają przykłady.
Piszemy więc np.

email
.withTitle(someTitle)
.withBody(someTextInTheBody)
.shouldBeSentTo(recipient)
.withReplyToAddress(replyTo);
email.send();

Jakie są szanse utworzenia takiego API za pierwszym razem, bez tworzenia takiego przykładu? Oczywiście można pozostać przy setterach i getterach, ale o ile łatwiej taki kod czytać i zrozumieć o co autorowi chodziło!
A skoro już piszemy takie przykłady, to dlaczego nie napisać tego najpierw. Najlepiej rozpocząć myślenie o klasie właśnie przez pryzmat jej wykorzystania. Każde środowisko programistyczne pozwala automatycznie wygenerować puste definicje metod, więc kod kompiluje się od razu. A jak będziemy mieli gotowy szkielet klasy, wypełniamy ją kodem. W ten właśnie sposób prowadzimy projektowanie przykładami. Dzięki temu nasze klasy mają większe szanse na właściwe rozmieszczenie odpowiedzialności między nimi (bo przykłady definiują właśnie odpowiedzialności) a do tego metody publiczne od razu mają zrozumiałe nazwy. A po zakodowaniu ich "wnętrzności" jeszcze trochę refaktorowania i również wewnętrzna struktura klas będzie przejrzysta.

Teraz mamy już kod, który powstał dzięki przykładom. No to przykłady można wywalić i pisać nowe... Zaraz! A może za miesiąc będzie trzeba trochę to przerobić... Może będzie trzeba do emaila dodać pole BCC albo formatowanie HTML. To lepiej te przykłady zostawmy - przydadzą się za miesiąc. Dodamy nowe wywołania, zmienimy nazwy tych, które zmienią znaczenie (tak, to też refaktoryzacja). Takie przykłady będące na bieżąco są do tego dość dobrą dokumentacją tego co kod potrafi i jak to osiągnąć. Może za miesiąc do zespołu dojdzie nowy programista i z satysfakcją powiemy mu RTFE ;)

To jak już mamy te przykłady i utrzymujemy je na bieżąco, jak już definiują nam one wywołania, to dlaczego nie sprawdzać przy okazji czy te wywołania poprawnie działają? Wtedy gdy tylko ktoś zmieni implementację bez modyfikacji przykładu, ten przestanie odzwierciedlać rzeczywistość i automatycznie zgłosi to programiście. Co więcej pozwolą nam one weryfikować świadome zmiany w kodzie w przyszłości. W końcu gdy tylko będzie trzeba zmienić istniejącą funkcjonalność - powiedzmy wszystkich odbiorców maila z tej samej domeny umieścić w CC a z poza w BCC - przykłady nie spełniające tego wymagania zgłoszą nam błędy. Wystarczy je wtedy zaktualizować i kod dalej jest spójny. Albo lepiej - najpierw napisać przykład, który weźmie pod uwagę nowe zmiany, zweryfikuje poprawność ich implementacji, a potem już pewni poprawności uaktualnimy niedziałające przykłady.

I tak nasze przykłady stają się automatycznymi testami. W większości jednostkowymi, częściowo akceptacyjnymi, gdzieniegdzie integracyjnymi. W połączeniu ze środowiskiem ciągłej integracji dają z niczym nie porównaną pewność poprawności oprogramowania. Przez cały czas.

W ten sposób od kodu spisanego jak notatka, draft zawierający co prawda meritum, ale w niezrozumiałej dla nikogo oprócz autora formie, dochodzimy do programistycznego dzieła literackiego. Od cowboy-coding do metodycznego rozwijania oprogramowania. Od amatorskiego "żeby działało" do profesjonalnej pewności poprawności. To jest właśnie clean code.

Mówiąc krótko: czysty kod jest wynikiem poprawnego stosowania TDD - definicji przykładu, potem implementacji a na koniec refaktoryzacji. TDD pewnie nie jest jedynym sposobem uzyskania tego efektu, ale nie spotkałem się przykładami dużych projektów o czystym kodzie tworzonych bez TDD.

Studio Pragmatists

noreply@blogger.com (Paweł Lipiński) — Fri, 13 Nov 2009 21:46:00 +0000

Ostatnio dość mało tu treści, a dużo reklam :) Postaram się, żeby był to ostatni raz.

Jako Pragmatists postanowiliśmy (wzorem najlepszych) zrobić firmowy blog, na którym będziemy umieszczać aktualności dotyczące naszej działalności, ale co ważniejsze również techniczne artykuły i refleksje dotyczące naszej pracy. Blog nazywa się Studio Pragmatists (http://blog.pragmatists.pl).

Pierwszy wpis dotyczy organizowanego przez nas szkolenia, a dokładniej tego, że przed nami ostatni tydzień rejestracji.

Zwinne szkolenie taniej :)

noreply@blogger.com (Paweł Lipiński) — Thu, 05 Nov 2009 14:37:00 +0000

Właśnie się zorientowaliśmy, że szkolenia nie podlegają opodatkowaniu VAT, więc szkolenie nagle stało się tańsze i kosztuje okrągłe 2^10zł :)

Mamy już zarezerwowaną prawie połowę miejsc, więc wszystkim chętnym polecam się pospieszyć!

Ci, którzy odeszli

noreply@blogger.com (Paweł Lipiński) — Sun, 01 Nov 2009 12:19:00 +0000

Te święta to dobra okazja nie tylko na refleksję nad sobą, swoim życiem i jego celowością, nad własną rodziną i innym, którym zawdzięczamy to kim jesteśmy, gdzie żyjemy, czy jakie mamy warunki życia. Dla nas - ludzi zajmujących się oprogramowaniem - to może też być czas na refleksję nad tymi, dzięki którym jesteśmy tu gdzie jesteśmy - czas na chwilę wspomnienia wielkich matematyków i informatyków, którzy swoje zawodowe życie (a często i prywatne) oddali temu, co dziś jest naszym zawodem i naszymi narzędziami. By to co kiedyś nieosiągalne i skrajnie trudne mogło dla nas być codziennością.

Kiedyś już polecałem poniższy film, tym razem polecam przerzucić dokładnie do 74 minuty i oddać dziś tym właśnie ludziom chwilę.

Zwinne szkolenie

noreply@blogger.com (Paweł Lipiński) — Sat, 31 Oct 2009 22:03:00 +0000

Zeszłoweekendowa warsjava była chyba pierwszym większym Warszawskim spotkaniem ludzi zainteresowanych zwinnymi metodykami. Jej sukces (ponad 100 osób z tego co wiem i z tego co widziałem) pokazuje, że zwinne tematy są nie tylko ciekawe, ale przede wszystkim ważne. Idąc za ciosem zdecydowaliśmy się jako Pragmatists podzielić się naszą wiedzą i doświadczeniami dojścia do tego co osiągnęliśmy w większych szczegółach. A osiągnęliśmy myślę, że dość niezwykłą rzecz. Jesteśmy zespołem, który realizuje to o czym mówi: krótkie iteracje, TDD, programowanie w parach, prawdziwy shippable product na koniec każdej iteracji, i wiele innych zwinnych praktyk wcielonych w życie. Ale przede wszystkim jesteśmy ukierunkowani na przynoszenie wartości, na pokonywanie barier i problemów, na dawanie swojego czasu, wiedzy, doświadczenia i zaangażowania naszym klientom. Staramy się skupiać na poprawianiu swojej efektywności i jakości.
Zdecydowaliśmy się więc zorganizować otwarte dwudniowe szkolenie ze Zwinnego Rozwijania Oprogramowania. Szkolenie planowane jest dla 15~20 osób zainteresowanych pogłębieniem swojej wiedzy w tym zakresie i zdobyciem nowych doświadczeń. Szkolenie prowadzić będę ja wraz z Krzyśkiem Jelskim, który na warsjavie i ostatniej javarsovii zajmował się tematem TDD oraz ma za sobą dobre parę lat doświadczenia pracy w zwinnych zespołach. Obiecujemy nie tylko masę wartościowej, konkretnej wiedzy, ale również dobrą zabawę pomagającą utrwalić i zweryfikować nowe umiejętności.

Szczegóły dotyczące szkolenia są tu: http://pragmatists.pl/szkolenie. W razie wątpliwości / pytań piszcie.
Zapraszam!

Po WarsJawie

noreply@blogger.com (Paweł Lipiński) — Mon, 26 Oct 2009 08:17:00 +0000

W ten weekend była warsjawa. Kto nie był niech (raczej) żałuje. To chyba było pierwsze większe spotkanie w Warszawie dotyczące zwinnych metodyk. I na pierwszy rzut oka widać było, że brakuje takich spotkań. Po pierwsze - było chyba ponad 100 osób, co od razu wskazuje na to, że temat jest ciekawy. Po drugie - to, że trzeba takie spotkania organizowa widać po pytaniach. Masa dotyczących estymacji (o co w ogóle chodzi), długości i zawartości spotkań, itp. Czyli dość podstawowe.
Oczywiście świetnie, że ludzie chcą się uczyć i poznawać, z drugiej szkoda, że jest jeszcze tak mało doświadczeń.
Tak czy siak, Łukasz (wraz z resztą organizatorów): wielkie dzięki za zorganizowanie tego spotkania!

Jeśli ktoś chce przejrzeć moją prezentację (zanim organizatorzy wrzucą ją na parleys'a), to jest ona tu:
I Twój zespół może być zwinny.

I jeszcze jedno. Strasznie mnie wkurza zwrot "w agile'u" (wielokrotnie słyszałem go na warsjawie). Po angielsku słowo agile jest przymiotnikiem. To tak jakby powiedzieć "w zwinny'u używamy iteracji" :-P
Zresztą większość zdań tego typu jest i tak nieprawdziwych - manifest zwinnego rozwijania oprogramowania bardzo mało mówi o konkretnych praktykach. Zamiast tego lepiej powiedzieć "w scrum'ie" albo "w XP" gdy odnosimy się do praktyk konkretnej metodyki.
Z drugiej strony, utożsamianie zwinnego myślenia (jako podejścia, filozofii) z konkretną metodyką jest również błędem (szczególnie częste jest to w przypadku scrum'a, i szczególnie nieprawdziwe) - metodyki definiują procesy i praktyki, nie skupiają się raczej na wartościach (no, poza XP oczywiście).

Wprowadzenie do zwinnego rozwijania oprogramowania

noreply@blogger.com (Paweł Lipiński) — Wed, 21 Oct 2009 00:04:00 +0000

W związku ze zbliżającą się konferencją warsjawa (na której będę opowiadał o transformacji zespołów na zwinne metodyki), oraz brakiem czegoś podobnego w języku polskim, poświęciłem parę wieczorów i napisałem wprowadzenie do zwinnego rozwijania oprogramowania (zwykle nazywane jest to agile introduction).

W czasie warsjawy nie będzie żadnej prezentacji wprowadzającej do zwinnego myślenia i zwinnych metodyk, więc jeśli ktoś nie miał z nimi dotychczas praktycznego kontaktu, nieskromnie polecam!

http://pragmatists.pawellipinski.com/Downloads/Pragmatists%20-%20Zwinne%20Rozwijanie%20Oprogramowania.pdf

Przedwczesna optymizacja

noreply@blogger.com (Paweł Lipiński) — Wed, 14 Oct 2009 08:26:00 +0000

Przeglądając stronę wikipedii dotyczącą eXtreme Programming znalazłem wśród praktyk programistycznych następujące zalecenie: 'leave optimization till last'. No i faktycznie zdaje się, że jest to dość uznana zasada. Przywołuje na myśl znane zdanie Donalda Knutha

Premature optimization is the root of all evil.

Z drugiej strony zwinne metodyki zalecają utrzymywanie projektu przez cały czas jego rozwoju w stanie gotowości do wdrożenia. Scrum nazywa to potentially shippable product - na koniec każdej iteracji przygotowujemy więc wszystko co niezbędne, żeby produkt tej iteracji można było wdrożyć (nie dlatego, żeby to faktycznie co iterację robić, tylko dlatego, by utrzymywać taką możliwość i dać klientowi prawo do decyzji co do tego kiedy chce aplikację wdrożyć, zaprezentować użytkownikom itp. Poza tym robiąc to jesteśmy pewni, że projekt jest cały czas zintegrowany, i że nasz system CI i proces tworzenia oprogramowania są dobre. No i jeszcze kwestia morale zespołu, gdy wie, że projekt jest non-stop w stanie jakościowo gotowym na produkcję).

Wracając do zostawiania optymizacji na koniec, zupełnie nie zgadzam się z tym. To klasyczny przypadek zostawiania gdzieś praktyk fazowych (waterfall'owych). Jak można nazwać aplikację potencjalnie gotową do wdrożenia, jeśli nie jest wystarczająca wydajnościowo?
Tak więc optymizujmy kod w czasie jego rozwijania. Może nawet warto dodać do Definition of Done zadań zespołu warunek akceptowalności pod względem wydajnościowym.

Oczywiście we wszystkim należy zachować umiar. Ważne jest, by wydajność była akceptowalna / zadowalająca. To może oczywiście oznaczać bardzo rygorystyczne warunki np. dla systemów RT. Szczegółowy fine-tuning wydajności jakichś elementów aplikacji można jednak faktycznie zostawić na później. To znaczy jak się już okaże, że faktycznie jest problem wydajnościowy i będzie wiadomo dokładnie gdzie. Oczywiście nie sądzę, żeby było dobrym pomysłem czekanie aż okaże się to w środowisku produkcyjnym - dla aplikacji dla których wysoka wydajność jest ważna można ją kontrolować stale w czasie rozwoju aplikacji w przeznaczonym do tego środowisku CI z automatycznymi testami wydajnościowymi. Natomiast powinniśmy dbać o nieograniczanie (głównie architektonicznie) naszych możliwości optymizacji.

Z resztą powyższy cytat z Knuth'a nie jest kompletny (a większość programistów zna tylko ten jego fragment). Kompletny brzmi tak:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Agileee retrospective

noreply@blogger.com (Paweł Lipiński) — Mon, 21 Sep 2009 20:42:00 +0000

This post is in english, since the conference was mainly in english (and maybe some agileeestas would like to read it.)

So, the conference was simply great. Maybe not perfect, but great.
I even had a little influence on its shape by having a talk there (the slides are here...)

So let me summarise it:

WHAT WAS GOOD:

venue
lunch
keynotes (Jutta Eckstein with her 'distributed agile' talk - have heard her already twice with a similar subject before, but there's always something new; David Hussman with a really touching closing talk underlining how important it is to follow what you believe in)
many talks
speaker's night out (and I thought that Poles drink a lot...)
lots of nice, clever and experienced people
ratio: cost / value

WHAT COULD BE BETTER:

coffee and water not always available
some talks really for agile-beginners (maybe there should be some 'experience level' mark by each talk, so that you go to the level you're at)
stage in Russian (I mean I could be better and speak Russian, there must have been a lot of valueable stuff, otherwise unavailable for a non-ex-soviet-country guy)

PLANS TO HAVE A BETTER AGILEEE IN FUTURE:

learn Russian
don't loose the conference schedule and read in advance where you plan to go to
meet even more people on corridors

So in total I'd say 8/10 (just to leave the organisers some place for kaizen...)
I really hope to be there next year, and wish it to you all!

Pierwszy release

noreply@blogger.com (Paweł Lipiński) — Mon, 07 Sep 2009 19:54:00 +0000

Dziś w Pragmatists mieliśmy pierwsze wdrożenie pierwszego projektu. To taki miły moment, kiedy jest wreszcie chwila na zastanowienie się jak poszło. Na przemyślenie co można następnym razem lepiej. Jak nie popełniać pewnych błędów, jak pomagać klientom nie wpadać w pułapki.

Projekt był hybrydowy - z naszej strony staraliśmy się robić wszystko zwinnie - zaczęliśmy klasycznie od ustalenia z klientem o co mu chodzi, utworzyliśmy masę User Stories, zrobiliśmy estymacje, backlogi, pracowaliśmy w parach, TDD, itp. itd. Z drugiej strony nasz klient, choć z grubsza chętny do zwinnego podejścia, jednak z własną historią i przyzwyczajeniami (bardzo niezwinnymi). I do tego z projektem, który miał już wyznaczony termin wdrożenia, choć jeszcze nie wiadomo było dokładnie co ma być zrobione. I to jest pierwsza pułapka i chyba bardzo częsta. Terminy rzadko ustala zespół. To często element negocjacji, jakby niemerytoryczny - ustalany między managerami i salesami. W naszym przypadku nasz klient naprawdę nie wiedział czego chce ich klient (który jest użytkownikiem aplikacji) poza ogólnikami i własnymi domysłami (z resztą błędnymi, więc po pierwszych 2 miesiącach pracy zakomunikowano nam, że trzeba zacząć od nowa i zrobić coś zupełnie innego :)). Myśmy na to przystali (no cóż, nie zdobywa się klientów od stawiania im warunków...) i skutek był taki, że ostatnie 4 tygodnie były zmaganiem z czasem, wymaganiami (prośba o ostatnią zmianę w aplikacji pojawiła się wczoraj, w niedzielę, o 22:30...) i stresem własnym i klienta.
To podstawowa różnica między projektem zwinnym a klasycznym - w zwinnym termin jest funkcją zakresu wymagań i prędkości zespołu. Dlatego staramy się dostarczać aplikacje przyrostowo, wtedy terminy przestają być kluczowe, bo klient zaczyna dostawać aplikację wcześniej i ma realny wpływ na jej zawartość, a więc również na termin kiedy zacznie ją wykorzystywać. A więc:

Action Point 1: zachęcić klienta do spróbowania teraz (po tych średnio miłych doświadczeniach ostatniego miesiąca) "naszego" sposobu - nie tylko pokazywać, ale dostarczać kolejne wersje aplikacji na produkcję co 2 tygodnie. Dzięki temu nie będzie gorączki przedwdrożeniowej, ale stały jasny dla wszystkich proces regularnego dostarczania już-nie-tylko-potentially shippable product'u (mamy zadbane środowisko CI, więc jakby się uprzeć, to z technicznego punktu widzenia moglibyśmy dostarczać nawet codziennie).

Kolejne doświadczenie to komunikacja. Tutaj mamy wciąż dużo do poprawy. To, że nie mamy bezpośredniego kontaktu z użytkownikiem wpływa na naszą niepewność co do tego, czego on może tak naprawdę potrzebować. Jak chciałby pracować z aplikacją. Np. dwa tygodnie przed wdrożeniem dowiedzieliśmy się, że użytkownik lubi na raz pracować z excel'ami o setkach wierszy, bo wtedy "wszystko widzi" - a nasz a'la-excel'owy mechanizm wspiera raczej nie więcej niż 50 wierszy.
Nasz klient jest 1300km od nas i sprawność komunikacji jest kluczowa. Maile nie zawsze starczają a cotygodniowe spotkania iteration review/planning nie dają nam odpowiedzi na kluczowe pytania: czy aplikacja się podoba, czy są zadowoleni (z aplikacji, postępu,itp.)

Action Point 2: Bardziej cisnąć o informacje w czasie planowania - w czasie trwania iteracji MUSIMY wiedzieć dokładnie co mamy robić i czemu to ma służyć.

Zespół = Ludzie + Interakcje. Widzę to codziennie. Są dni, kiedy widać jak na dłoni, że pracując razem stanowimy dużo więcej niż gdyby każdy pracował oddzielnie. Wpadamy na lepsze pomysły (bo dużo dyskutujemy, a więc projektujemy), tworzymy lepszy kod (bo wiele osób go czyta i pisze, a więc musi być zrozumiały), nakręcamy się do pracy (bo to nie tylko nasz chleb, ale głównie nasza pasja), zachęcamy się do nauki i ciągłego ulepszania samych siebie ("kuuuurde, chłopaki, ale książkę znalazłem...", "ej, Kamil, jest tam coś ciekawego w tym artykule?", "Paweł, w mordę, nie pisz takiego szitu, przecież to można ładniej zrobić!") Są dni, kiedy wychodząc z pracy dobrze rozumiem dlaczego moje dzieci płaczą, że nie chcą jeszcze wracać gdy ich odbieram z przedszkola.

Action Point 3: jeszcze więcej pracy w parach, jeszcze więcej dyskusji przy tablicy, jeszcze więcej chłonięcia wiedzy od siebie i wspólnego tworzenia nowej.

Testy, testy i jeszcze raz testy (automatyczne). To jedyny sposób robienia oprogramowania wysokiej jakości. To jedyny sposób żeby być pewnym, że możesz dostarczyć aplikację KIEDY TYLKO KLIENT ZECHCE. To jedyny sposób na uniknięcie długich niezrozumiałych metod i niejasnych rozwiązań. To jedyny sposób na weryfikowanie poprawności twoich pomysłów gdy aplikacja już się rozrosła (inaczej marnujesz długie godziny na klikanie i debugowanie). To w końcu jedyny sposób by móc sobie powiedzieć: zrobiłem (done) i jestem tego pewien. A to jedno z milszych uczuć jakie mamy w naszej pracy. Nie wierzę, że może twierdzić inaczej ktoś kto choć raz brał udział w tak rozwijanym projekcie (jest to zdecydowanie najwyższej jakości projekt w jakim brałem udział w życiu, a mam za sobą ponad 10 lat pracy w developmencie i pewnie ponad 20 projektów różnego rozmiaru za sobą).
Testy dają nam poczucie pewności a naszemu klientowi możliwość prawie dowolnego kształtowania i modyfikowania wymagań - a to przekłada się w prostej linii na jego przewagę nad konkurencją.

Action Point 4: weryfikacja (ciągła) pokrycia funkcjonalności testami (nie pokrycia linii kodu, ale pokrycia funkcjonalności) i dorabianie ich tam, gdzie ich brakuje.

Action Point 5: definiowanie zakresu iteracji za pomocą testów akceptacyjnych (A-TDD) - to dotyczy zarówno kwestii elastyczności wymagań, jakości produktu, jak i (a może przede wszystkim) komunikacji z klientem.

To tak z grubsza większość moich przemyśleń co do tego projektu. Widziałem w tym czasie zaangażowanie, kreatywność i pasję. Obserwowałem (a trochę może też wpływałem na) tworzenie się z grupy ludzi zespołu. Rodzenia się odpowiedzialności i poczucia wspólnego celu. Wiele jeszcze oczywiście przed nami. Ale przecież to zaledwie początek.

EA - niepewność? zweryfikuj to w kodzie

noreply@blogger.com (Paweł Lipiński) — Thu, 27 Aug 2009 20:44:00 +0000

Architekci bardzo często podejmują decyzje bazując na swoim doświadczeniu. Często jest ono szerokie i faktycznie wystarczające do podjęcia decyzji. Ale wielokrotnie pewne decyzje podejmowane są w pośpiechu i tak naprawdę na zasadzie "tak powinno być dobrze" albo "to raczej wystarczy". Architekci zdecydowanie zbyt rzadko weryfikują swoje pomysły w kodzie. Nie jest tak, że nigdy - tam gdzie pracowałem jako architekt miałem szczęście, że zawsze była możliwość spędzenia trochę czasu na poszukiwaniach dobrego rozwiązania. Ale często podjąć decyzję w oparciu o "duże szanse, że tak jest ok" jest dużo łatwiej niż zweryfikować ją. Tak z ręką na sercu - często się po prostu nie chce. Gdy plany architektoniczne powstają niezależnie od właściwej aplikacji (przed) zweryfikowanie czegokolwiek w kodzie wymaga napisania często naprawdę dużych ilości kodu.

Przy ewolucyjnym podejściu do architektury, nie dość, że decyzje są raczej mniejsze, bazujące na ciągle rosnącej wiedzy o systemie, ale również są one łatwiej weryfikowalne. Często jakiś pomysł architektoniczny można zweryfikować w oparciu o istniejącą aplikację - mniej kodu do pisania, a i bardziej pewny będzie wynik. Z resztą programujący architekt ma dużą wprawę w pisaniu kodu (nie zapomina jak to jest, a to akurat się dość łatwo zapomina) więc i napisanie odpowiedniego POC'a nie jest dużym problemem.

Bardzo często decyzje wpływające na wydajność aplikacji podejmuje się w oparciu o założenia: że maszyna wirtualna zoptymalizuje kod, że sprzęt jest wystarczający, że to zadanie przecież wcale nie jest takie kosztowne czasowo, itp. Czasem wystarczy też dosłownie pół dnia pracy na zweryfikowanie takich założeń jakimś kawałkiem kodu. Biorąc pod uwagę koszty ewentualnych późniejszych zmian (choćby tylko czasowe, związane z przepisywaniem) raczej warto posiedzieć i sprawdzić czy nasze pomysły naprawdę są aż tak dobre :)

Self Organizing Teams

noreply@blogger.com (Paweł Lipiński) — Fri, 31 Jul 2009 20:40:00 +0000

W świecie agile'owym promuje się samoorganizację zespołów. Gdy zespół sam potrafi prowadzić swoją pracę, gdy bierze odpowiedzialność za swoje zobowiązania, ma wszelkie uprawnienia by je realizować i to robi można go nazwać samoorganizującym się. Takie zespoły działają dużo efektywniej niż prowadzone klasycznie metodą poleceń i kontroli ich wykonania. Po pierwsze bardziej im się chce, bo czują się odpowiedzialni za swoją pracę. Po drugie mają większą satysfakcję, ponieważ mają dużo większą wolność. Po trzecie nie czują się traktowani jak dzieci (na temat związku idei agile'owych z wychowaniem dzieci też mam swoją teorię, ale nie o tym ten post :-))

Od samego początku firmy Pragmatists chciałem stworzyć takie środowisko, w którym branie odpowiedzialności, zaangażowanie i samoorganizacja będą czymś normalnym. Środowisko, w którym o wszystkim decyduje zespół mając na względzie dobro swoje (wzajemnie poszczególnych osób w zespole), firmy i klientów. Gdzie zespół uzgadnia swój sposób pracy, co może zrobić i na kiedy, gdzie stoją biurka i jaką chcą pić kawę. Ale również chciałem by było miejsce na zrozumienie i szacunek dla potrzeb innych, dla decyzji klientów, dla możliwości firmy.

I to się udalo - mimo projektu w toku (a jego pierwszej fazy to właściwie pod koniec) wyjechałem na 3-tygodniowe wakacje zostawiając zespół na pastwę projektu i klienta :-). Przez ten czas funkcjonalności były dodawane wcale nie wolniej niż ze mną (niektórzy sądzą, że nawet szybciej...), odbywały się regularnie standupy i retrospekcje, zakupione zostały lepsze klawiatury i mleko do kawy, odbywał się ciągły kontakt z klientem i w końcu nawet potrzeba drobnej regulacji kontaktów z klientem z moim drobnym udziałem.
Był to w jakiejś mierze test realizacji moich oczekiwań (niniejszym patentuję termin Test-Driven Company Development). Teraz oczywiście pora na małą refaktoryzację, by jeszcze poprawić już dobrze działający mechanizm :)

Mój Drogi Zespole, bardzo Wam dziękuję!

EA - KISS

noreply@blogger.com (Paweł Lipiński) — Fri, 31 Jul 2009 19:17:00 +0000

Keep It Simple, Stupid! mówi starobrytyjskie porzekadło. Jak jest ono prawdziwe wie każdy, kto choć raz przedzierał się przez gąszcz klas, chaszcze metod i bagna logiki przesadnie zaprojektowanych aplikacji. Chęć przewidzenia przyszłych wymagań pcha nas często w pułapkę używania skomplikowanych konstrukcji tam gdzie dużo prostsze były by wystarczające. A skomplikowane struktury, gdy kod nie komunikuje jasno ich celu, rozwijają się szybko w totalnie niezrozumiałe monstra. Wystarczy dorzucić do nich jednego if-a tu, i jeszcze dwa tam, i początkowo śliczna implementacja wzorca przeradza się we włoskie danie z sosem bolognese.
W zwinnych projektach staramy się bronić przed takimi sytuacjami przez ciągłe projektowanie i refaktoryzację aplikacji (TDD). Praca w parach pozwala nam na ciągłe weryfikowanie wprowadzanego kodu niejako z zewnątrz - przez kolegę, który być może trzeźwiejszym okiem oceni nasze zapędy.
Ale to techniki które można stosować na poziomie kodu. A co z architekturą? Przecież cała idea definiowania architektury to przewidywanie przyszłości. Przecież to właśnie dzięki dobrym wstępnym decyzjom aplikację będzie można np. prawie liniowo skalować, czy umożliwić jej łatwą integrację z korporacyjnym ESB.

Żeby nie wpaść w pułapki podjęcia błędnych decyzji, lub roztrząsania zupełnie nieistotnych kwestii posługujemy się terminem last responsible moment. Jest to ten moment przed którym podjęcie decyzji może być przedwczesne (niewystarczające/niepełne informacje mogą spowodować podjęcie błędnej decyzji), a po którym jej niepodjęcie może powodować jakieś straty (np. zbyt wczesne podjęcie decyzji o wyborze Oracla a nie MySQL może narazić nas na ogromne koszty, zbyt późne podjęcie decyzji może oznaczać konieczność przepisania fragmentów aplikacji). Staramy się więc powstrzymywać od podejmowania decyzji w kwestiach które nas aktualnie nie dotyczą, ale bardzo pilnie obserwować i dyskutować te które mają wpływ na naszą aktualną pracę.

Aby móc pracować w taki sposób utrzymujemy naszą architekturę maksymalnie prostą, ale zawsze w takim stanie, by umożliwić jej modyfikację. Bo gdy założymy, że architektura ewoluuje wraz z rozwojem systemu, możemy też założyć, że ma ona wspierać wyłącznie te własności które są niezbędne TERAZ i których wymagalności jesteśmy absolutnie pewni (YAGNI). Z resztą czym prostsza architektura tym łatwiej ją komunikować w ramach zespołu i tym łatwiej zapanować nad nią zespołowi. A czym większy zespół tym bardziej jest to prawdziwe.

Podobnie jak w przypadku projektowania na niższym poziomie, staramy się cały czas patrzeć kiedy prostota techniczna rozwiązanie zaczyna przeszkadzać w utrzymaniu prostoty wyrazu. Taką sytuację można zwykle poznać po liczbie bezpośrednich zależności - jeśli jest ich za dużo, prostota techniczna naszego rozwiązania przestaje być wartością - trzeba więc poszukać rozwiązania bogatszego technicznie i poprawiającego komunikatywność, zrozumiałość naszego pomysłu. Powinniśmy cały czas utrzymywać balans między prostotą techniczną i prostotą wyrazu.

Dbamy więc symetrię, modularność (high cohesion, low coupling), rozdzielenie warstw, oddzielenie dziedziny od elementów infrastrukturalnych, uniezależnienie od zewnętrznych bibliotek / frameworków, itp. Jeśli pomyślimy o tych cechach w kontekście prostoty, to to jest to, co one faktycznie promują. Kod podzielony na małe moduliki jest prostszy od monolitycznej masy. Każdy z modułów z dobrze wydzieloną pojedynczą odpowiedzialnością jest prostszy niż masa if-ów i switch'y weryfikujących poszczególne przypadki.

Pilnowanie i dbanie o prostotę rozwiązań oraz zachowywanie zasady wysokiej wewnętrznej spójności i małego poziomu uzależnienia od zewnętrznych elementów (na każdym poziomie), ułatwia tworzenie zwinnych architektur pozwalających na reagowanie na zmiany wymagań.

EA - zespół który koduje system musi go projektować

noreply@blogger.com (Paweł Lipiński) — Tue, 21 Jul 2009 19:37:00 +0000

Poprzednim razem pisałem ogólnie o architekturze w projektach zwinnych. Generalna zasada jest taka, że nad architekturą staramy się zastanawiać nie (wyłącznie) na początku, ale w każdej iteracji. Ale żeby móc coś takiego osiągnąć zespół który koduje system musi go projektować. By decyzje architektoniczne były świadome a nie tylko pobożnymi życzeniami muszą być podejmowane na podstawie danych - faktów. A te ujawniają się w dużej mierze w czasie developmentu. Również informację o kosztach (w sensie czasowym) decyzji i zmian architektonicznych zna tylko zespół. Tak więc to zespół jest najbliżej wszystkich danych niezbędnych do podejmowania decyzji.

Podejmowanie decyzji architektonicznych przez zespół ma poza tym wpływ na jego zaangażowanie w projekt i wzmaga odpowiedzialność za projekt. Przekazywanie władzy "w dół" (team empowerment) to dobry sposób budowania zespołu. Kto nie chciałby pracować przy projekcie ze zmotywowanymi i zaangażowanymi współpracownikami? Jak poza tym pomagać mniej doświadczonym członkom zespołu zwiększać swoją wiedzę jak nie przez angażowanie ich w takie dyskusje?

Architektura projektu w przypadku większych rozwiązań czy firm o zdefiniowanej polityce w tym zakresie może wymagać uczestnictwa architekta. To on dba o zachowanie zgodności z polityką architektoniczną firmy, ale również może służyć zespołowi swoim doświadczeniem - ale do tego celu musi on być obecny w zespole przez cały czas developmentu. Czasem wymaga to zmiany funkcjonowania organizacji - gdy w firmie jest dział architektury, który zajmuje się tworzeniem dokumentacji architektonicznej przed rozpoczęciem developmentu, może być ciężko zaangażować architekta w działania zespołu - najpewniej ma on już kolejne systemy do projektowania.

Oczywiście w przypadku dużych projektów nie ma możliwości by cały zespół projektowy (np. parędziesiąt osób) podejmowało wszystkie decyzje. Wtedy możliwe są rozwiązania takie jak zespół architektoniczny złożony z programistów z poszczególnych podzespołów. Pozwala to na zachowanie spójnej architektury całego systemu przy zachowaniu decyzji co do jego kształtu na właściwym poziomie (dalej robią to programiści aktywnie zaangażowani w development). Rotowanie osób w tym zespole pomaga dodatkowo rozprzestrzeniać wiedzę o produkowanym systemie oraz zwiększać ogólną wiedzę i doświadczenie w zespole.

W niektórych projektach widziałem spotkania w rodzaju "architecture review" podczas których architekt który zaprojektował system siedział z zespołem i przeglądał system pod kątem realizacji jego założeń. Takie spotkania oczywiście zwiększają szansę na to, że system będzie zgodny z założoną architekturą, ale nie koniecznie wpływają na to, że będzie ona zgodna z wymaganiami co do systemu. Poza tym takie przeglądy są zwykle dość powierzchowne. To coś a'la code review - dobrze je robić jeśli się nie korzysta z programowania w parach i TDD. Jeśli jednak uda nam się wprowadzić te techniki, code review jest w większości przypadków zbędne. Co więcej przeglądy architektury (podobnie jak przeglądy kodu) mają formę hierarchiczną: o to architekt sprawdza czy programistyczna masa nie zniszczyła jego dzieła - architektury (no, może trochę przerysowałem...) Praca architektów w zespole ręka w rękę z mniej doświadczonymi programistami dużo lepiej wpływa na pozyskiwanie wiedzy tych drugich i całościową pracę zespołu umożliwiając dużo efektywniejszą jego pracę.
Ciągłe dbanie o utrzymywanie, weryfikowanie i modyfikowanie architektury umożliwia jej lepszą jakość i odpowiedniość wymaganiom, do tego zmiejszając szanse na to, że będzie niezbędna jej gruntowna (kosztowna) zmiana.

Ewolucja Architektury - intro

noreply@blogger.com (Paweł Lipiński) — Tue, 21 Jul 2009 18:26:00 +0000

JAVArsovia minęła (prawie 3 tyg temu...) więc zdecydowałem się zamieścić tu główne idee tematu który prezentowałem, czyli zagadnienie Ewoluującej Architektury, czy szerzej: architektury w zwinnych projektach. Część tych zagadnień bazuje na książce Dean'a Leffingwell'a Scaling Software Agility. Wszystkie zaś związane są z moim doświadczeniem i obserwacjami co do funkcjonowania działów architektury, developmentu i ich wzajemnych relacji.

Achitektura definiowana jest jako te elementy systemu, które powinny pozostać niezmienne. Te które decydują o kształcie i paramaterach niefunkcjonalnych systemu. Z tego względu chcemy zapewnić je jak najwcześniej. Architektura to zwykle również drogowskaz który mówi programistom tworzącym system jak rozwiązać krytyczne jego elementy. Z tego względu tworzona jest ona przez najbardziej doświadczone osoby, które już na początku potrafią przewidzieć okoliczności wykorzystania aplikacji, znają wymagania i mają niezbędne kompetencje techniczne by architekturę zdefiniować.

"Architektura" to termin, który wiele osób stara się zdefiniować, ale trudno wypracować jedną definicję. Są dwa wspólne elementy: pierwszym jest wysokopoziomowy podział systemu na części; drugi - decyzje, które ciężko zmienić.

Martin Fowler, PoEAA

W projektach programistycznych przywykliśmy jednak do tego, że projekty, których wymagania się nie zmieniają w czasie ich rozwoju prawie się nie zdarzają. Że znaczna część wymagań ujawnia się dopiero w czasie tworzenia systemu. Że systemy jednak czasem muszą ewoluować - obsługiwać większe obciążenie, pozwolić na integrację z jakimś systemem zewnętrznym, itp. itd. Stąd u podstaw zwinnych projektów leży:

Welcome changing requirements, even late in  development. Agile processes harness change for  the customer's competitive advantage.

The best architectures, requirements, and designs  emerge from self-organizing teams.

Agile Manifesto, principles #2 & #11

Gdzie więc w zwinnych projektach miejsce na architekturę, na niezmienniki, na stanowisko architekta? Otóż staramy się stosować coś co nazywam ewoluującą architekturą. Jest to takie podejście do architektury, które zakłada, że nawet decyzje na najwyższym poziomie mogą się zmieniać. Np. że względem aplikacji w tej chwili monolitycznej mogą z czasem pojawić się wymagania modularności. Że aplikacja bazująca na współdzielonym stanie może z czasem wymagać modyfikacji na bezstanową. Zakładamy również, że część wymagań co do struktury aplikacji może ujawnić się dopiero na jakimś etapie jej rozwoju - np. nie mogły być przewidziane wcześniej, lub po prostu nie były wzięte pod uwagę (np. na jakimś etapie okazuje się, że aplikacja nie spełni zakładanych wymagań wydajnościowych ze względu na swoją architekturę).

Takie podejście do architektury zakłada, że podobnie jak inne elementy zwinnego projektu (kod, testy, dokumentacja), architektura rozwija się przez cały czas jego trwania - przez cały okres developmentu. Przecież na końcu architektura to nie to co było wstępnie pobożnie zakładane, ale struktura aplikacji - a więc kod. W najbliższych paru postach postaram się przedyskutować podstawowe elementy, które uważam za niezbędne do wprowadzenia i utrzymywania ewoluującej architektury (albo po prostu zwinnej architektury) i rolę architekta w zwinnych projektach.

Z perspektywy zmiany, rola architektury w zwinnym rozwoju oprogramowania staje się zupełnie jasna: dobra architektura jest responsywna i wspiera zwinność; kiepska będzie się opierać i ją ograniczać.

Kevlin Henney

Ewolucja Architektury

noreply@blogger.com (Paweł Lipiński) — Fri, 03 Jul 2009 21:18:00 +0000

Zapraszam jutro na mój wykład o ewolucji architektury w zwinnych projektach na javarsovię. Ekipa konferencji nie zamieściła szczegółów które im przesłałem :) więc wrzucam tutaj:

Opis prelekcji:
Ewolucja Architektury
Architektura oprogramowania to ten jego składnik, co do którego
decyzje podejmowane są zwykle na samym początku projektu. Na czym
bardziej zaawansowanym etapie jest projekt, tym bardziej ryzykowne i
kosztowne są jej zmiany. Czasem jednak takie zmiany są niezbędne.
Czasem architektura ma oczywiste błędy. Czasem wymagania co do
funkcjonowania systemu zmieniają się do tego stopnia, że oryginalna
jego architektura nie może im sprostać. Paweł omówi sposoby radzenia
sobie w takich sytuacjach. Opisze jak kwestie ewolucji architektury
podejmowane są w projektach prowadzonych przy pomocy zwinnych
metodyk. Wskaże sposoby tworzenia aplikacji w taki sposób by jak
najmniej wiązać logikę aplikacji z jej architekturą, tak by umożliwić,
a czasem nawet promować jej ewolucję.

O mnie:
Paweł Lipiński jest programistą, architektem, trenerem zespołów. Przez
ostatnie parę lat pracował jako architekt aplikacji i systemowy,
głównie przy projektach klasy enterprise. Aktualnie pracuje w firmie
Pragmatists (będąc przy okazji jej właścicielem) zajmującej się
usługami dla zespołów programistycznych (coaching, szkolenie,
prowadzenie zespołów), pomocą zespołom i organizacjom w transformacji
na Scrum/XP, wyprowadzaniem projektów na prostą oraz tworzeniem
oprogramowania przy użyciu zwinnych metodyk. Posiada certyfikat
Certified Scrum Practitioner oraz niezliczone certyfikaty techniczne
związane z platformą Java/JEE.

Praktyki Zwinnego Programisty

noreply@blogger.com (Paweł Lipiński) — Fri, 05 Jun 2009 07:17:00 +0000

Jeśli ktoś nie śledzi Warszawskiego JUGa, to pewnie nie wie, że w najbliższy wtorek będzie (wszystkich zainteresowanych oczywiście zapraszam):

from Jacek Laskowski
reply-to warszawa-jug@googlegroups.com
to Warszawa-JUG
date Thu, Jun 4, 2009 at 11:44 PM
subject [warszawa-jug] 49. spotkanie Warszawa JUG - IncuBIT
rozpoczyna, a po kwadransie "Praktyki Zwinnego Programisty"
Pawła Lipińskiego
mailing list Filter messages from this mailing list
mailed-by googlegroups.com
signed-by googlegroups.com

Cześć!

Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) [1]
zaprasza na 49. spotkanie, które odbędzie się 09.06.2009 (wtorek) o
godzinie 18:00 w sali 5440 Wydziału MIMUW przy ul. Banacha 2 w
Warszawie.

Temat prezentacji: Praktyki Zwinnego Programisty
Prelegent: Paweł Lipiński

Przed wystąpieniem Pawła o praktykach gościem specjalnym będzie
przedstawiciel firmy IncuBIT.pl - inkubatora innowacyjnych technologii
z zakresu Internet/Mobile współfinansowanym z PO IG 3.1. Jest to
organizacja non-profit, której celem jest wspieranie pomysłowych i
energicznych ludzi w realizacji ich pomysłów. Wystąpienie zajmie 15
minut i jej celem jest przedstawienie możliwości skorzystania z
funduszy Unii Europejskiej do finansowania własnych przedsięwzięć.

Dalsza część spotkania to występ Pawła Lipińskiego z jego tematem
agile'owym. Paweł opowie o wszystkich głównych zagadnieniach
związanych z pracą w zwinnym/agile'owym zespole. Pokaże jak wygląda
zwinny projekt zarówno od strony zarządzania (organizacja zespołu,
pracy, komunikacji z klientem, planowanie i estymacja wymagań) jak i
praktyk programistycznych (TDD, programowanie w parach, ciągła
integracja, itp.) Opowie o różnicach w pracy między klasycznym
projektem i zespołem programistycznym i pracy w środowisku agile'owym.

Paweł Lipiński [2] jest programistą, architektem, trenerem zespołów
programistycznych. Przez ostatnie lata pracował jako agile coach oraz
architekt aplikacji i systemowy, głównie przy systemach klasy
enterprise. Aktualnie pracuje w firmie Pragmatists (będąc przy okazji
jej właścicielem), która zajmuje się usługami dla zespołów
programistycznych (coaching, szkolenia, prowadzenie zespołów), pomocą
przy projektach typu 'death march', oraz tworzeniem oprogramowania z
wykorzystaniem zwinnych metodyk i praktyk. Posiada certyfikat
Certified Scrum Practitioner i niezliczone techniczne certyfikaty
głównie ze świata Java/JEE.

Planowany czas prezentacji to 1,5 godziny, po której planuje się
15-30-minutową dyskusję.

Wstęp wolny!

Zapraszam w imieniu prelegenta i grupy Warszawa JUG!

[1] http://www.warszawa.jug.pl
[2] http://www.pawellipinski.com/

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

--~--~---------~--~----~------------~-------~--~----~
Otrzymałeś/-aś tę wiadomość, ponieważ jesteś zapisany/-a do grupy "Warszawa Java User Group (Warszawa JUG)" w serwisie Grupy dyskusyjne.
Aby publikować na tej grupie, wyślij wiadomość e-mail na adres warszawa-jug@googlegroups.com
By wypisać się z grupy, wyślij e-mail do warszawa-jug+unsubscribe@googlegroups.com
Więcej opcji na stronie grupy http://groups.google.com/group/warszawa-jug?hl=pl
-~----------~----~----~----~------~----~------~--~---

Pragmatyczna Prywata

noreply@blogger.com (Paweł Lipiński) — Tue, 19 May 2009 21:37:00 +0000

Nie pisałem nic od półtora miesiąca. Powodów było parę, ale główny oczywiście odwieczny brak czasu. Tym razem jednak nie był to brak czasu w rodzaju 'wdrożenie miałem' ani nawet 'projekt nam się wali'. W sumie wręcz odwrotnie.

Dnia dwudziestego kwietnia rozpoczęła działalność moja firma Pragmatists. Cały wolny czas poświęcałem więc ostatnio lataniu po urzędach, zmaganiem się z biurokracją, itp. Na szczęście udało się to wszystko załatwić i wreszcie mogę skupić się na meritum.

Ta firma to trochę eksperyment mojego "poszukiwania białych nosorożców" dość widocznego we wpisach w tym blogu. Eksperyment stawiania na jakość. Eksperyment szacunku, szczerości względem nas samych i naszych klientów, oraz całkowitej przezroczystości działań. Partnerskiego modelu tworzenia oprogramowania, gdzie dostawca i zamawiający mają wspólny cel.
Stosujemy zwinne metodyki tak na poziomie prowadzenia projektu jak i praktyk programistycznych (wraz z TDD i programowaniem w parach) i na pierwszym miejscu stawiamy jakość.

Tak więc przy okazji pozwolę sobie na mały anons:

public class Pragmatists {
 public String miasto = "Warszawa";
 public String rejon = "Metro Wilanowska";
 public String kontakt = "contact@pragmatists.pl";

 private Session chetniDoPracy;

 List znajdzProgramiste() {
     Programista takiJakMy = new Programista();

     takiJakMy
         .lubiSwojZawod(true)
         .uwielbiaSieUczyc(true)
         .dbaOJakosc(true)
         .wieCzymJestAgile(true)
         .znaJezyki(Jezyk.JAVA, Jezyk.Angielski)
         .znaFrameworki(Framework.HIBERNATE, Framework.SPRING, Framework.JEE)
         .maDoswiadczenie(Calendar.YEAR, Criteria.MIN, 3);

     return chetniDoPracy
               .createCriteria(Programista.class)
               .add(Example.create(takiJakMy))
               .list();
 }
}

Sapienti sat! :)

Nadszedł czas... jakości

noreply@blogger.com (Paweł Lipiński) — Wed, 01 Apr 2009 19:57:00 +0000

Na jednym z blogów (dokładnie to tu) znalazłem taki wpis:

The biggest challenge for me personally was essentially mourning for the death of “Programmer Man”. Programmer Man is how I think of myself when I’ve got my headphones in, speed metal blaring in my ears, and I’m coding like a motherfucker. My fingers can’t keep up with my brain. I’m In The Zone. For most of my career, this image is what I’ve considered to be the zenith. When I come home and was in Programmer Man Mode most of the day, I feel like I’ve had a good day.
Pair Programming undeniably killed Programmer Man. This was a tough adjustment, since I’ve considered that mode to be my favorite for so long. I now see, however, that Programmer Man was, without me knowing it, Technical Debt Man.

'Coding like a motherfucker' od razu przypomniało mi nasze polskie 'Nadszedł czas napi**lania':

Nie wiem kto kiedy dlaczego i jak na to wpadł (to z tym czasem) ale naprawdę dobrze odzwierciedla to częste podejście do realizowania projektów informatycznych. Jakość nie gra roli - ważne jest dotrzymanie terminu. Co będzie po 'przebiciu piłki przez siatkę' nie interesuje dostawcy - niech się z tym buja klient.

Ciekawa jest analogia między tymi dwoma tekstami. Jak czytam tego gościa, to przypominają mi się moje postawy w projektach parę lat temu. Takie napi**lanie kodu. Samotność w sieci.

Ale tak fajnie jest tylko na początku. Po paru miesiącach takiego developmentu wracamy do domu zmęczeni i sfrustrowani. To jest nasza normalność. Nasza szara rzeczywistość. I niczym matka-polka szorująca gary i piorąca brudne skarpety swojego popijającego piwo przed TV męża (ekscytującego się, że 40 milionowy kraj może wygrać w piłkę z San Marino...) godzimy się na takie życie. Na początku przynosi nam to zadowolenie, że dopisaliśmy kolejne stosy kodu. Potem jest już tylko frustracja i niecierpliwe czekanie na coś nowego. Na wyjście z mroku.

Programowanie to sport grupowy. Dlatego właśnie nazwa Scrum odwołuje się do sportu. Bo projekty wymagają współpracy. Ciągłej. We wszystkim. Praca w grupie powoduje podnoszenie jakości. I Twojej i Twojego kodu. Ciągłe. Wspólne.

Ale żeby móc osiągnąć takie środowisko - środowisko ciągłego uczenia się, wzajemnego poprawiania, ekscytacji pracą - niezbędna jest praca zespołowa. Stąd w Scrumie tyle spotkań. Stąd coraz częściej czerpane z XP praktyki z TDD i programowaniem w parach na czele. Bo to nic innego jak ciągłe poznawanie innych i siebie, w tym co robimy. To przeglądanie się jako programiści w kodzie swoim i innych jak w lustrze. To nabywanie doświadczeń przez nieustanną obserwację innych przy pracy. I ciągłe, nieustanne czytanie kodu. Bo Twoim klientem jako programisty nie jest jakiś bank, czy portal, nie ubezpieczyciel czy operator komórkowy, tylko drugi developer. Ten który będzie czytał twój kod i próbował go zrozumieć. To do niego kierujesz kod.

Panie i Panowie - nadszedł czas jakości!

PS. Nie wiem jak tam mecz. Ja jestem po whisky, ciesząc się świeżym certyfikatem CSP właśnie czytam hipershitowy kod. I żałuję, że jego autor nie czytał zanim go napisał tego co tu właśnie spłodziłem :)

To zależy...

noreply@blogger.com (Paweł Lipiński) — Tue, 31 Mar 2009 07:20:00 +0000

Rozwijanie oprogramowania to zajęcie inheretnie intelektualne. Taki truizm mi się nasunął :)

Ale zdaje mi się, że wielu programistów o tym zapomina. Myślę, że są ku temu dwa powody - przyzwyczajenia i błędne założenia.

Klasyczny wodospadowy model produkcji oprogramowania zakłada, że najpierw tworzona jest architektura i projekt oprogramowania (i tu jest myślenie - od tego jest Architekt i Projektant, którzy za pomocą Drogiego Narzędzia CASE/UML tworzą Architekturę) a potem trzeba to po prostu zakodować. Tak jak z budynkiem, tylko cegły się ciężej układa, więc przydadzą się studia. I programiści w jakimś stopniu to kupują i programują tak jak im się akurat przydarzy.

Ale w wielu firmach, szczególnie mniejszych software house'ach nie ma działu architektury. Tam ludzie przyzwyczajeni są - jeszcze może z czasów studiów - że myśli to się o algorytmach, o drzewach czerwono-czarnych, o ray-tracingu, może nawet o szeregowaniu zadań w systemie operacyjnym, ale przecież nie w aplikacji webowej. Tę każdy wie jak napisać - tu nie ma o czym myśleć.

Programiści oczekują gotowych rozwiązań. Że książka, blog, prezentacja dadzą im konkretne odpowiedzi. Że zasugerowane w czasie wykładu, rozmowy wzorce będą dobre na każdą sytuację.

Ale oprogramowanie to nie budynki (choć nic nie wiem o tym, może tam też trzeba myśleć...) Tu odpowiedzi są ogólne i niepewne. Bez drobiazgowej znajomości wymagań i reszty aplikacji nie sposób dać stu procentowej odpowiedzi. Nad każdym szczegółem, najdrobniejszym detalem powinno się posiedzieć. Przemyśleć. Zbadać siły działające w tej sytuacji. Przemyśleć jak dany kod będzie wykorzystywany. Ani reguły SOLID ani wzorce GoF ani jakieś cechy języka nie zastąpią myślenia.

Czasem trzeba brać pod uwagę kwestie merytoryczne - wydajność jakiegoś rozwiązania, bezpieczeństwo, itp. Czasem percepcyjne - jak zorganizowany kod jest czytelniejszy, co łatwiej jest zrozumieć. Czasem w końcu organizacyjno-psychologiczne - że baza danych zależna jest od kogo innego i często się zmienia, że większość zespołu woli jakiś inny sposób formatowania, itp.

Dlatego właśnie Big Design Up Front nie może dać dobrej aplikacji (tzn. może się komuś uda, ale generalnie...) Bo nie da się bez kodu i zespołu przemyśleć tego wszystkiego odpowiednio dokładnie.

Zapytał mnie niedawno kolega z pracy jakie rozwiązanie jest lepsze (zainspirowany moim ostatnim wpisem) - mieć oddzielne DAO czy metody operacji na danych bezpośrednio w encjach (Active Record). I nie ma tu dobrej odpowiedzi. W jakimś stopniu jest to kwestia estetyki, w jakimś designu reszty aplikacji. Może tez wchodzić w grę doświadczenie programistów, wybór technologii do przechowywania danych itp. itd.

Czasem używanie tych samych obiektów jako dziedziny (wraz z zachowaniami) i reprezentantów bazy danych (ORM, DTO) jest ok, a czasem (no dobra, częściej) warto trzymać swoje obiekty oddzielnie i nie wystawiać wszystkich ich pól do publicznego dostępu (w ten sposób wiążąc implementacje innych elementów kodu z wyłącznie naszą implementacją dziedziny) a dla Hibernate'a wystawiać DTO (inna reprezentacja danych w bazie a inna w dziedzinie, zmieniająca się struktura bazy, itp.)

Na wiele pytań nie ma jednoznacznych odpowiedzi na samym początku. Na wiele nie ma ich też później, dlatego robimy oprogramowanie tak, by na bieżąco dostosowywać je (refaktoryzować) do zmieniających się warunków (a przecież warunki się ciągle zmieniają w czasie developmentu, bo dodawane są kolejne funkcjonalności). Oprogramowanie nie jest z kamienia ani żelbetu, tylko jest realizacją naszych (elastycznych) myśli.

Tylko od Ciebie zależy jak je budujesz.

Repozytoria w DDD

noreply@blogger.com (Paweł Lipiński) — Thu, 19 Mar 2009 09:05:00 +0000

W czasie prezentacji o DDD (albo zaraz potem) zadał mi ktoś pytanie o realizację Repozytoriów w javie. Jeśli traktować Repozytoria jako klasyczny wzorzec DAO, to realizacja jest prosta. Robimy generyczne DAO, który obsługuje wszystkie zwyczajne przypadki (CRUD) a tam, gdzie potrzebujemy jakichś szczególnych (bardziej biznesowych) metod, doimplementowujemy to w klasie dziedziczącej po tymże DAO. DAO można zrobić np. tak jak w przykładzie na stronach Hibernate. To rozwiązanie niestety wymaga podawania explicite tego DAO, wszczepiania go tam gdzie chcemy go użyć itp. Oddzielność tej warstwy jest ewidentna (można dyskutować czy to dobrze czy to źle, ale to głównie estetyka). Niektórzy wolą więc zarządzanie obiektami dziedziny w sposób a'la Grails/GORM:

public class RepositoryInsideDomain {
 
 @Test
 public void checkSaveFindDelete () {
  Author author = new Author();
  author.setName("Pawel");
  
  author.save();  
  assertTrue(Author.isStored(author));
  
  assertNotNull(Author.findById("Pawel"));
  assertEquals(author, Author.findById("Pawel"));

  author.delete();  
  assertFalse(Author.isStored(author));   
 }
}

Co niestety wymaga albo pobrudzenia obiektów dziedziny dodaniem odpowiednich metod z DAO i delegacji do nich (trywialne, nieutrzymywalne i nieładne, więc nawet nie będę pokazywał, bo ktoś powie że to promuję :)), albo pobawieniem się aspektami. I to rozwiązanie może być ciekawe, więc je tu pokażę (zrealizowane za pomocą aspectj'a). Do tego potrzebujemy zrobić Repozytorium (tu strywializowane, ale oczywiście może być dowolnie bardziej złożone):

public class Repository {
 static Map storage = new HashMap();

 public Repository() {
 }

 public static Object findById (Object id) {
  return storage.get(id);
 }

 public void save () {
  storage.put(this.toString(), this);
 }
 
 public void delete () {
  storage.remove(this.toString());
 }
 
 public static boolean isStored (Object o) {
  return storage.containsKey(o.toString());
 }
}

i jeszcze aspekt który pomiksuje to wszystko razem:

public aspect RepositoryInjector {
 declare parents: com.lipinski.domaininjection.domain.* extends Repository; 
}

Tak niewiele trzeba, by odpowiednie metody repozytorium były dostępne bezpośrednio z klas dziedziny. Dzięki temu nie musimy wszczepiać nigdzie repozytoriów, operujemy wyłącznie na klasach domenowych. Z drugiej strony na poziomie kodu mamy ładną separację dziedziny od infrastruktury. jedyna wada tego rozwiązania, to że nie jest to pure java, i póki się nie zajrzy do tego aspektu to nijak nie wiadomo skąd te metody się znalazły. Ale jeśli to podejście stosujemy konsekwentnie w całej aplikacji, to nie powinien być problem.