Touching the Void

Bounded Context

2011-11-29T00:16:00.001+01:00

Jasne, że nie będę od teraz pisał o DDD, bo już inni o tym ciekawie piszą. Chciałbym się tylko trochę uzewnętrznić w temacie, który szczególnie mnie poruszył, gdyż rozwiązuje dość poważny problem z architekturą. Jeśli nie nie zetknąłeś się z filozofią (w moim rozumieniu to bardziej sposób myślenia niż toolbox; taka obiektowość podniesiona level wyżej - na poziom architektury) DDD to na wstępie proponuję:

Pierwszą część książki: Domain Driven Design
albo po polsku

O jakim problemie mowa?

Powiedzmy, że rozpoznajemy, co też dzieje się domenie sklepu internetowego (nie wiem dlaczego to sklep zazwyczaj przychodzi na myśl:)). Powiedzmy, że dzieje się jak poniżej:

Jest to jakaś interakcja pomiędzy obiektami w dziedzinie.

Gdy zaczynamy modelować, naturalnie pojawiają się klasy takie jak: Zamówienie, Koszyk, itd. Powstaje model złożony z powiedzmy 30-50 klas. Wszystko wygląda super świetnie, ale zbiegiem czasu coś zaczyna nie grać. Pojawiają się następujące symptomy:

W związku z kolejnymi wymaganiami, do obiektów dochodzi coraz więcej atrybutów i metod
Programista implementujący przypadek użycia związany ze złożeniem zamówienia z trudem odnajduje się w gąszczu atrybutów i metod dodanych przez kogoś, kto implementował realizację Zamówienia
Niektóre obiekty są używane w tak wielu miejscach systemu, że jakakolwiek w nich zmiana ma spore skutki w innych odległych miejscach

Co więcej: jeśli z wymagań wynika jakaś konkretna zmiana w jednym miejscu systemu, to obija się ona głośną czkawką w zupełnie innym właśnie z powodu "reużywania" obiektów modelu.

Niby wszystko zostało przygotowane zgodnie z regułami sztuki, ale jednak wszyscy czują, że coś śmierdzi...tylko nie wiadomo z jakiej przyczyny.

Powód jest taki, że ten sam obiekt modelu używany jest wielu różnych kontekstach. Zamówienie wynikające z interakcji użytkownika z Koszykiem jest nieco inną sprawą niż Zamówienie realizowane przez magazyn.

"Bounded context should have a name so that you can talk about them"

Rację mieli starzy Indianie, gdy twierdzili, że jeśli poznasz czyjeś imię, zyskujesz nad tym kimś władzę. Nie inaczej jest z bounded contexts. Jeśli nie zauważymy i nie nazwiemy kontekstów użycia modelu, to mogą nam zrobić krzywdę. Nienazwane lubią się mieszać i dokładać do obiektów modelu rożnego rodzaju dodatki właściwe dla swej specyfiki. W skutek czego powstaje model-potworek, który w założeniu miał być super, a w wykonaniu i tak jest kolejną wersją big ball of mud.

Jeden model w jednym kontekście

W związku z dokonanymi odkryciami warto zalecać:

Nazwij kontekst, w którym może być wykorzystywany model. Już sama próba nazwania sprawi, że kontekstów pojawi się kilka (o ile tam są).
Jeden model może być wykorzystywany tylko w jednym kontekście (bounded context). Zamówienie w kontekście Koszyka to nie dokładnie to samo, co zamówienie w kontekście Magazynu.
Odizoluj poszczególne konteksty i właściwe im modele od siebie

W powyższych zasadach można dopatrzyć się echa Single Resposibility Principle. Z odpowiedzialności modelu powinien wynikać jednoznaczny kontekst jego użycia. Tyle, że Bounded Context definiuje to wprost i wyraźnie, a z zasady odpowiedzialności trzeba sobie wywnioskować.

Jeżeli w konsekwencji mamy zdefiniowanych kilka zwartych modeli o jednoznacznie określonych kontekstach użycia, to musi istnieć coś, co będzie potrafiło skonwertować obiekty z jednego kontekstu w drugi (jeśli jest taka potrzeba). W DDD ta potrzeba jest zaspokajana poprzez zdefiniowanie Context map w postaci zestawu usług-translatorów (w apachowych commonsach nazywanych transformerami). Ich odpowiedzialność to właśnie konwersja.

Podsumowując zyski z wprowadzenia konceptu Bounded Context:

Redukcja echa w systemie - zmiana w modelu w jednym miejscu nie skutkuje oddźwiękiem w innym
Zmiany wynikające z biznesu mają na poziomie architektury ograniczony do kontekstu zasięg
Można lepiej zorganizować prace nad projektem (tutaj DDD proponuje kilka pomysłów w zależności od tego jakie relacje występują pomiędzy kontekstami).

Przeglądy kodu

2011-11-22T00:07:00.001+01:00

Kilka słów o przeprowadzaniu code review. A zatem po co? Czy nie wystarczy podłączyć Sonara czy coś w tym stylu. Z pomocą przyszedł mi cytat zamieszczony na strone 33rd Degree Conference: A single conversation with a wise man is better than ten years of study. I właśnie dlatego warto przeprowadzać code review :) Prowadząc taką rozmowę z f2f robimy użytek efektu human infection, czyli przekazujemy sobie wiedzę i ideę w bardziej naturalny sposób niż na papierku, albo ciągiem bitów.

Informacje początkowe

Dalej streszczam mój sposób na przeprowadzanie przeglądu kodu, ale najpierw parę tematów wprowadzających.

Jak często przeprowadzać przeglądy?
Tu nic odkrywczego nie wymyślę, jeśli napiszę, że: raz na wydanie albo raz na iterację albo w regularnych odstępach czasu albo po zamknięciu zadania albo na żądanie :)

Kto przeprowadza przegląd?
Jestem fanem ról, a sceptykiem stanowisk więc sądzę, że przegląd powinien przeprowadzać lider. W żadnym razie lidero-kierownik mający pod sobą kilkanaście osób. Mówię o liderach np. konkretnych komponentów systemu, którzy przewodzą maksymalnie pięciu osobom. Jeśli brak takiego liderowato-centrycznego uporządkowania, to przegląd robią ludzie, którzy mają mandat od zespołu wskazujący, że "ten zna się na rzeczy". Rzecz jasna poszczególni programiści z biegiem czasu nabywają kompetencji do przeprowadzania przeglądów. Zespół żyje.

Jak szczegółowy ma być przegląd?
Ufam, że ludzie są mądrzy. Wystarczy pokazać im co i dlaczego robią źle, aby potem zgeneralizowali ideę i wprowadzali poprawki w reszcie kodu. Nie ma potrzeby pokazywania palcem absolutnie wszystkiego. Wiem, wiem pewnie, że są wyjątki. Ale co do zasady, wspomniane założenie ufności jest dość użyteczne.

Ile czasu zajmie przegląd?
Jeśli znasz i rozumiesz kod to w okolicach 30 min plus drugie tyle na rozmowę. Jeśli nie znasz kodu (bo na przykład analizujesz kod klienta) to już jest zupełnie inna bajka. Megaistotne jest zebranie informacji co z czym się je, żeby nie wydzwaniać do ludzi co parę minut. Sam późniejszy przegląd to 8h wzwyż.

Przegląd krok po kroku

1: Zdefiniuj w IDE tasktagi //SMELL i //REFACTOR
Będą potrzebne do oznaczania w kodzie różnych ciekawostek.

2: Ogranicz się do kodu: jednego user story | jednego zadania | jednej funkcjonalności
Generalnie mogę wpaść w cały moduł i nie wyjść z niego przez tydzień. Ale zgodnie z zasadą zaufania, chcemy wyłapać symptomatyczne niedociągnięcia delikwenta, a nie prześwietlić jego kod od A do Z. Który zatem kawałek kodu wybrać? Tu przyda się rozbudowany instynkt Dr Housa. Trzeba z premedytacją wybrać taki fragment kodu, który potencjalnie mógł programiście sprawić trudność. Przykład: ostatnim razem ustaliliście nad czym ma popracować, wiec teraz sprawdź podobne zadanie albo kątem ucha usłyszałeś jak rozmawia o jakimś trudnym zadaniu - sprawdź właśnie to. Jasne, że nie robimy tego z czystej złośliwości, lecz właśnie w tego typu zadaniach jest okazja, aby wyłapać największe niedociągnięcia i najszybciej skorygować styl pisania.

3: Wygeneruj diagram zależności między klasami/pakietami
Najczęściej korzystam z wbudowanych widoków Eclipse lub ficzerów ReSharpera, wspomagając się kartką. Teraz zaczynam zapoznawać się z CDA i jeszcze nie mam wniosków. Jeśli chodzi o C++ to Visual Assist X jest jakimś tam ułatwieniem. Ale konwencje utrzymywania projektów i plików w C++ są tak zróżnicowane, że niemal za każdym razem wymaga ode mnie kreatywnego podejścia. Zazwyczaj kończy się na Eclipse C/C++ oraz kartce i długopisie. (Nie, nie rysuję w tym przypadku diagramów w narzędziu UML, bo za długo to trwa; ewentualnie potem, gdy okazuje się na przykład, że dziesięciopoziomowa hierarchia dziedziczenia sprawia kłopoty, to coś tam przerysuję żeby efekciarsko wyglądało w raporcie).

4: Pobieżnie przyjrzyj się każdej klasie w wybranym fragmencie kodu
Przyglądamy się tu pod następującymi kątami:

ogólne wrażenie - elegancja kodu, czy woła o pomstę do nieba?
nazewnictwa - czy nazwa oddaje intencję?
wielkości klas i metod
Ilość współpracowników

5: Prześledź podstawową obsługę żądania
Chodzi o prześledzenie ścieżki od momentu, w którym ktoś zainicjował przetwarzanie

do chwili, gdy system odpowiedział na nie.

Oznacz //SMELL miejsca, w których kod wydaje Ci się niewłaściwy. Przez //REFACTOR oznacz miejsca, w których od razu wiesz, co należy zrefaktoryzować.

6: Przygotuj podsumowanie
Byle krótkie w punktach, które uwzględni relację kodu do: obowiązującego standardu kodowania, czystości kodu, przyjętych zasad architektury.

7: Przekaż informacje zwrotną
w rozmowie f2f oraz wskazuj kierunki poprawy, ewentualnie zaimprowizuj mikorszkolenie. Zanotuj sobie, aby zweryfikować, czy postanowienia z rozmowy zostały wdrożone. Jeśli ludzie będą zapominać, przeglądy nic nie wniosą i wszystkim odechce się w nie angażować.

Czy należy wnioskować, że nienawidzę narzędzi?

Absolutnie nie. Takie super gadżet jak Sonara przeanalizuje za Ciebie masę kodu i wskaże miejsca, w które warto zajrzeć osobiście. Jestem wielkim fantem użytecznych narzędzi z zastrzeżeniem, że nie wolno nam zafiksować, że narzędzia zrobią wszystko, a my będziemy mogli zwolnić się z myślenia.

Dodatkowo jestem entuzjastą minimalizowania ilości otwartych zadań (work in progress). Jeśli robię przegląd i używam fajnych okienek, wpisuję komentarze (które potem trzymane są w repo), to te komentarze tam sobie będą i będą, aż może ktoś się nimi zajmie, rośnie tendencja do odkładania. Jeśli teraz robię przegląd i mam kilka słów podsumowania na kartce, to będę dążył to tego, aby jak najszybciej złapać daną osobę, przekazać co mam do przekazania i niech ona to już zrobi. Problem zdiagnozowany, rozwiązany, można pisać dalej.

Duch i litera

2011-11-10T14:56:00.000+01:00

Trochę w nawiązaniu do posta W co gra się w projektach.

W okolicach wyborów słyszałem w radiu zażartą dyskusję nt. czy obecnemu rządowi wolno rządzić do końca roku czy nie. Premier się upierał, że chce spokojnie dokończyć prezydencję w UE i argumentował, że jest to zgodne z konstytucją, natomiast konstytucjonaliści ripostowali, że owszem jest to zgodne z konstytucją, lecz nie jest zgodne z jej duchem.

Otóż to, pomyślałem. Wdrażanie procedur/procesów/standardów w zespole kończy się niepowodzeniem, gdyż ludzie rozumieją ich literę, ale nie widzą ducha. Autorzy procedur mieli oczywiście bliski kontakt z duchem, a literę stworzyli po to, aby przekazać swoje odmienne stany świadomości. Ergo - przy okazji wdrażania czegokolwiek ludzie muszą nawiązać kontakt z duchem.

Zostawiwszy w spokoju spirytualistyczne metafory, trzeba wyraźnie powiedzieć, że ludzie muszą znać intencję wdrażania nowych standardów, czyli: po co to robimy, dlaczego to jest ważne, co z tego będziemy mieli. Dobrym pomysłem, w tym obszarze jest standaryzowanie tego co już działa. Jeśli w zespole samoczynnie wykształciła się jakaś praktyka, która przynosi dobre rezultaty, to wartą ją zinstytucjonalizować w postaci obowiązującego standardu - dwie pieczenie na jednym ogniu.

Inspiracja fantasy

2011-10-20T21:19:00.000+02:00

U jednego z lubiących mnie na facebooku znalazłem cytat z jednej z najlepszych sag fantasy jakie czytałem. Mowa rzecz jasna o Sadze o Wiedźminie. Cytat pochodzi z dzieła Jaskra, w którym wyjaśnia czytelnikowi, na czym polega prowadzenie działań wojennych.

Poznałem w życiu wielu wojskowych. Znałem marszałków, generałów, wojewodów i hetmanów, triumfatorów licznych kampanii i bitew. Przysłuchiwałem się ich opowieściom i wspomnieniom. Widywałem ich schylonych nad mapami, rysujących na nich różnokolorowe kreski, robiących plany, obmyślających strategie. W tej papierowej wojnie wszystko grało, wszystko było jasne i wszystko funkcjonowało we wzorowym porządku. Tak być musi, wyjaśniali wojskowi. Armia to przede wszystkim porządek i ład. Wojsko nie może istnieć bez porządku i ładu.
Tym dziwniejsze jest, że prawdziwa wojna - a kilka prawdziwych wojen widziałem - pod względem porządku i ładu do złudzenia przypomina ogarnięty pożarem burdel.

Pomyślałem złośliwie, że gdyby zdefiniować następujące zmienne:

marszałek, wojewoda, hetman, triumfator, wojskowy := menadżer
wojna, bitwa := projekt
wojsko, armia := zespół projektowy

to sumie też ma jakiś sens...

Nic tak nie zaciemnia sprawy jak dobry przykład

2011-10-18T13:01:00.000+02:00

jak ponoć mawiał szacowny nauczyciel.

Czasem mam wrażenie, że to powiedzenie odbija się echem w trakcie zbierania wymagań (w sumie odbija się echem w ogóle w kontaktach międzyludzkich, ale do zbierania wymagań się zawężę).

Próbujesz się dogadać, dowiedzieć co trzeba zrobić, aż tu nagle pojawia się tekst "to ja może podam Panu taki przykład....", który to przykład dokumentnie burzy moje zrozumienie problemu.

Podam taki przykład :), żeby doprecyzować o co mi chodzi. W ramach treningu poprosiłem osobę biznesową o opisanie "myszki do kompa" (rzecz jasna bez używania słów "mysz" i "komputer"). Otrzymałem odpowiedź: „To jest miłe w dotyku jak moje kapcie pluszowe. Jak to głaskam to sprawia mi to przyjemność. Służy to do wyrażania myśli. Wygląda jak zwierze ale na wyższym stopniu ewolucji. Jest większe od biedronki ale mniejsze od psa”.

Wychodzę z założenia, że za efektywność zbierania wymagań odpowiada zbierający. To jego zadaniem jest w porę zauważyć, że przykład/metafora zmierza z zaawansowane pułapy abstrakcji. Tylko co trzeba umieć, żeby na taki przykład się nie złapać?

Przypomina mi się jeden wykładowca matematyki, który słynął z pytań pomocniczych zwanych również pogrążającymi. Student męczy się przy tablicy z przebiegiem zmienności funkcji wykładniczej. Męczy się męczy. A wykładowca na to: "No, no to może ja pomogę. Niech Pan się zastanowi jak wygląda krzywa ładowania kondensatora"....

Planowanie to nie problem

2011-10-07T00:26:00.000+02:00

To miał być długi, pracowity wieczór. Nazbierało mi się sporo zadań do wykonania. Gdy tylko drzwi hotelowego pokoju za mną się zamknęły, przystąpiłem do działania według najlepszych prawideł sztuki planowania. Komputer zostawiłem w spokoju dla uniknięcia rozproszeń. Czystą kartę zapełniała powoli acz konsekwentnie rosnąca lista tudusów. Lista to została następnie starannie przepisana na nową kartkę, w już posortowanym według priorytetów porządku.

Tak uzbrojony, włączyłem notebooka i rozpocząłem działania. Pomyślałem, że zerknę co tam przed wyborami. Nic nowego. Ok, zabieram się do pracy. Ponieważ najpierw musiałem odszukać mail na podstawie, którego mam coś tam opracować - odpalam TB. Zaraz po uruchomieniu klienta poczty, automatycznie ściągają się czekające maile. No, tylko rzucę oczkiem....O, siostra przysłała mi przepis na zupę dyniową. Hmm, że niby ja mam to gotować? O, Grzesiek odpisał na facebooku. O, ktoś ma dla mnie ofertę pracy...ups nie, tam już pracowałem. Kurcze, ten mail to mnie wkurzył, muszę odpisać, bo nie zdzierżę!

Ok, jeszcze tylko załączę piosenkę na rozpęd i już się zabieram do pracy. Odnajduję na youtube stary teledysk Ronniego Dio. Naprawdę, koleś miał głos jak dzwon. Szkoda, ze zmarł. Kiedy to było? A, 16 maja..o wtedy, kiedy urodziny mojej siostry. Tak na marginesie o co chodzi z tą zupą dyniową? Jeść mi się zachciało. Jedno jabłuszko tylko, bo wieczór. Na noc jeść nie zdrowo. Nightwith - włączę cicho. O, ciekawe czy są jakieś nowe wtyczki do foobar2000. Zaraz zaraz, która godzina. Północ? A moje zadania? Szlag!

Zadania dryfują

Już nie raz łapię się na tym, że planowanie to bułka z masłem w porównaniu z konsekwentnym podążaniem za planem. Obstawiam, że gdyby nawet najmizerniejsze plany były realizowane w 100%, to osiągalibyśmy znacznie więcej niż obecnie. Kłopot w tym, że zaraz po przystąpieniu do działania, naszą uwagę przykuwa wiele rzeczy, które wywołują serię skojarzeń, które to z kolei kuszą nas do zajęcia się wszystkim tylko akurat nie tym, czym planowaliśmy się zajmować.

Ktoś mi kiedyś powiedział, że przedmioty "wysyłają" do ludzi oferty. Przedmioty starają namówić Cię, abyś z nich skorzystał, wszedł w interakcję. Ładna metafora i chyba oddaje istotę rzeczy. Największym wrogiem dotrzymywania terminów (zakładam, ze sensownych :)) nie jest wcale nieumiejętność planowania, lecz nieumiejętność realizowania planu. Cierpimy na chroniczny brak umiejętności skupienia się i utrzymywania skupienia, choć dawni belfrzy z twardą trzciną w łapie powiedzieliby, że to brak samodyscypliny.

Wielokrotne powtarzanie opisanego na wstępie schematu prowadzi do nawyku silnego jak u mitycznego psa Pawłowa. Po jakimś czasie okazuje się, że po prostu nie sposób zacząć pracy bez godzinnego onetowego rytuału.

Weź pigułkę

Przyczyna tkwi chyba w pigułkowatej mentalności otaczającego świata. Zewsząd wmawia się nam, że istnieją proste rozwiązania na wszystkie problemy. Wcale nie potrzeba pracy nad sobą, wyrzeczeń, poświęcenia. Wystarczy wziąć "pigułkę"np:. przeczytać książkę, która odkrywa sekret, pójść na szkolenie, gdzie wleją nam wszystko do głowy albo pić ziółka i chudnąć 5kg/tydzień. Ostatnio nawet widziałem w TV reklamę, której sens można oddać następująco: "żryj do woli, jak się rozchorujesz to weź pastylkę X i żryj dalej".

Nie inaczej jest z planowaniem i wykonywaniem zadań. Karykaturalnie wykrzywiając powiedzenie "chcieć to móc" wmawia się nam, że po zastosowaniu sprytnych tricków, poradzimy sobie z każą ilością zadań. Gdyby wyobrazić sobie dobę jako koło, to każde z jego wycinków oznacza część doby przeznaczoną na coś.

Przeciętny człowiek ma zajęte całe koło, bo zawsze coś tam robi mniej lub bardziej aktywnie. A tu nagle każą nam sprawić, aby kąt pełny miał więcej niż 360 stopni. Brutalna prawda jest taka, że aby zacząć coś robić, coś trzeba przestać robić albo czegoś robić mniej. To nie żadne hokus pokus, tylko zdrowy rozsądek.

Niestety zaczynamy wierzyć w taką pigułkowatą naturę rzeczywistości. Zaczynamy oczekiwać, że można coś osiągnąć bezkosztowo, że można zjeść ciastko i mieć ciastko jednocześnie. Efektem nie jest jednak natychmiastowy i oszałamiający sukces lecz frustracja, miernota i rozczarowanie.

Terapia

Leczenie z nadmiernego pobudzenia otaczającym światem, które sprzyja rozproszeniu i odciąga od tego, co rzeczywiście należy zrobić, jest możliwe.
Wydaje mi się, że warto zacząć od paru praktyk ograniczających wspomniane oferty przedmiotów:

Zadania zaczynaj od pierwszego na liście. Nie od RSS, newsów, maili itp. (wrzucanie RSSów do listy się nie liczy:))
Wyłącz komunikator, klienta poczty i włączaj je tylko w ściśle ustalonych porach (wiem, że to czelendż, ale warto spróbować)
W kliencie poczty wyłącz automatyczne odbieranie poczty przy starcie i co 10 minut
Z umiarem stosuj smartfony. Naprawdę nie musisz być on-line non stop.
Jeśli już koniecznie musisz poczytać newsy zrób to na końcu listy zadań, nie na początku
Słuchanie muzyki podczas pracy nie jest takie dobre jak się o tym mówi; Jest ok przy prostych powtarzalnych zdaniach. Jeśli zdania wymagają kreatywności, to angażują prawą półkulę mózgu, tą samą co muzyka. Zatem Twoje zadanie konkuruje o zasoby fooobarem2000
Jak najszybciej zamykaj zadania i jak ognia unikaj zostawiania ich rozgrzebanych i niedokończonych. Lepiej jest mieć 50% czegoś konkretnego niż 100% świetnych niezrealizowanych pomysłów

Dług techniczny, opcja call czy lokata długoterminowa?

2011-09-30T02:21:00.001+02:00

Standardowy kłopot z refaktoryzacją: my chcemy, a z góry leci głośnie NIE! Łaj? W moim odczuciu są dwie główne przyczyny. Pierwsza wynika z definicji. Skoro refaktoryzacja, to "ulepszenie wewnętrznej struktury oprogramowania, bez zmiany jego funkcjonalności", to skoro nie dodaje funkcjonalności, a zatem nie dodaje wartości biznesowej, a zatem nie pozwala efektywniej zarabiać, a zatem nie warto jej wykonywać. Podsumowując - kasa.
Drugi problem jest związany z przekonaniem, że jak już refaktoryzować, to rewolucyjnie i musi to zająć mnóstwo czasu. Skoro czasu to i pieniędzy. Za drogo i nie warto tego robić. Znów kasa. Nie zbłądzę zbytnio, gdy stwierdzę, że tarcia o refaktoryzację obijają się o pieniądze.

Kłopot z metaforami

Aby zdobyć choć trochę posłuchu u biznesu community wykombinowało jak na razie dwie metafory: Długu technicznego oraz (najświeższa) Niezabezpiecznonej opcji typu call.
Gdy się w nie wczytać, to każda z nich mówi mniej więcej coś takiego: Pamiętaj biznes-ludku, że jak nie będziemy refaktoryzować, to stanie się COŚ strasznego!. Obie metafory odwołują się do rzeczy, która jak nam się zdaje, najlepiej do biznesu przemówi, czyli do pieniędzy.

Dług techniczny mówi: zabraniając refaktoryzacji zaciągasz duże zobowiązanie, w kolejnym wydaniu rollujesz ten dług kolejnym długiem, i kolejnym, i kolejnym. W końcu zbankrutujesz i klops.
Niezabezpieczona opcja call mówi: nie pozwoliłeś na refaktoryzację, nabyłeś najbardziej ryzykowny instrument finansowy we Wszechświecie. Jedyne co możesz robić, to się modlić.

Skoro te metafory tak dokładnie wyłuszczają konsekwencje zaniedbywania jakości kodu, to dlaczego nic się nie zmienia? Nieco światła rzuca na to psychologia społeczna, wg której bardziej preferujemy natychmiastową gratyfikację niż długoterminowe korzyści oraz bardziej obawiamy się nieprzyjemności bliższych i namacalnych niż odległych i nieco abstrakcyjnych.

Podsumowując, twierdzę, że obojętność na prorefaktoryzacyjne błagania ma następujące przyczyny

korzyść z refaktoryzacji jest zbyt odroczona w czasie
korzyść z refaktoryzacji bardzo trudno wykazać jest w pieniądzach
zaniedbanie refaktoryzacji ma negatywne skutki w bliżej nieokreślonym kiedyś; a dopóki programiści mogą ratować projekt, to go ratują; czasem bardzo długo
robienie tak, "aby działało" ma szybkie odczuwalne korzyści

Powyższe fakty sprawiają, że na refaktoryzację przychodzi zgoda, gdy już w zasadzie jest za późno. I wtedy to już na prawdę jest od cholery roboty.

Lokata długoterminowa

Dobitna metafora dla refaktoryzacji powinna charakteryzować się następującymi cechami:

korzyści można łatwo wyrazić w pieniądzach
korzyści finansowe są szybko odczuwalne, powiedzmy w perspektywie tego samego albo najbliższego wydania

Zauważmy, że jest to metafora pozytywna. Dług techniczny oraz opcja call były metaforami negatywnymi w takim sensie, że straszyły tym, co złego się wydarzy jeśli nie będziesz grzeczny. Nasza nowa metafora jest sformułowana pozytywnie, bo pokazuje korzyści jakie uzyskasz, gdy będziesz się dobrze sprawować.

Szukałem tego typu metafory również w świecie finansów (no, bo dlaczego nie?) i znalazłem ja w postaci lokaty długoterminowej. Korzystając z tej metafory można w stronę Biznesu perorować, że:

refaktoryzacja jest jak wpłata pieniędzy na lokatę, już po pierwszym okresie rozliczeniowym następuje kapitalizacja odsetek i otrzymujesz swój procent
im dłużej oszczędzasz tym więcej zyskujesz
żeby osiągnąć maksymalną korzyść musisz wpłacać regularnie
jeśli zerwiesz lokatę, właściwie tracisz większość zarobku
no i w przypadku refaktoryzacji nie ma podatku Belki:), same korzyści!

A jak pokazać korzyści finansowe?

Tu popuszczam trochę wodze fantazji. Można spokojnie założyć, że na refaktoryzacyjnej lokacie odsetki procentują razem z początkowym kapitałem. Weźmy sobie zatem wzorek:

gdzie: V - obecna wartość, V0 - początkowy kapitał, r - stopa procentowa, n - liczba okresów rozliczeniowych.

No, to teraz spróbujmy zinterpretować wzór w kontekście refaktoryzacji. Vx - liczmy dalej w pieniądzach, n - liczba iteracji, a r? Skoro finansowo odpowiada to zyskowności (potencjałowi wzrostu kapitału?), to co jest tego odpowiednikiem w projekcie? Mam feeling, że coś z jakością kodu, ale nie bardzo wiem co.

User friendly

2011-09-29T22:17:00.000+02:00

Właśnie dostałem poniższy komunikat....to się nazwa user friendly UI :)

W co się gra w projektach?

2011-09-29T01:22:00.000+02:00

Był sobie zespół programistyczny złożony z paru osób. Wszyscy z żyłką pasji zabrali się do projektu. Ponieważ wychodzili założenia, że dobrze się uczyć na własnych błędach, przeprowadzali regularne retrospekcje. W trakcie retrospekcji analizowali sprawy takie jak:

zgodność szacowania z oczekiwaniami
pokrycie testami i ich skuteczność
ilość błędów znalezionych w fazie testów
czytelność kodu

i jeszcze parę innych rzeczy. Świetnie się przy tym bawili, bo mieli poczucie, że się rozwijają w obszarze, w którym pracują. Na bazie wspomnianych retrospekcji zaczęły wyodrębniać się różne rodzaju reguły i standardy. Wszyscy w zespole zgodnie uznawali, że odkryte zasady pozwalają efektywniej pracować i chętnie się im podporządkowywali. Postawili własne wiki, na którym spisywali standardy przyjmowane w zespole, i które potem stopniowo modyfikowali, dopasowując je do aktualnych potrzeb i doświadczenia.

Ponieważ praca szła wyjątkowo sprawnie, sponsor zespołu począł rekrutować kolejnych programistów i kolejnych i kolejnych. Pierwsi członkowie zespołu zostali liderami, potem kierownikami. Wszystko szło sprawnie. Naturalnie nowe osoby w dziale (tak, tak zespół stał się Działem, a jakże!) były zapoznawane z obowiązującymi i sprawdzonymi standardami i zobligowane do ich przestrzegania.

Po jakimś czasie nasi kierownicy zauważyli, że standardy są kiepsko przestrzegane. Trudno im było zmobilizować programistów do ich stosowania. Długo zastanawiali się jak zaradzić tej sytuacji. Ponieważ byli wytrawnymi inżynierami, podeszli do sprawy stricte analitycznie. Wykombinowali wcale skomplikowany wzór, który uzależniał dodatek premiowy od stopnia przestrzegania standardów. Na przykład: za 80% pokrycia testami +2%premii, za każde 50 błędów zgłoszonych przez testerów + 1,3%premii, za utrzymanie szacowania +3,2% premii....pomysł genialny...

i wtedy zaczęła się GRA.

Zasady gry

Intencją kierowników było nagradzanie osób z zespołu za przestrzeganie standardów i zachęcanie do ich stosowania. Jednak zupełnie nieświadomie stworzyli GRĘ, o następujących zasadach:

uczestnikami gry są członkowie zespołu projektowego
wygrywasz wtedy, gdy zdobywasz jak największą ilość pieniędzy
reguły zdobywania pieniędzy określone są poprzez standardy obowiązujące w zespole

Szybko okazało się, że programiści i testerzy są bardzo wytrawnymi graczami. Często wygrywali...,ale:

pokrycie testami było idealne, lecz: testowane były gettery, settery, testy bardziej przeszkadzały niż pomagały
programiści szacowali idealnie co do dnia, lecz bardzo, ale to bardzo pesymistycznie
testerzy znajdowali tysiące błędów, lecz większość z nich dotyczyła nadmiarowych spacji w labelkach, braku kropek itp
standard kodowania był przestrzegany, lecz tam gdzie było można programiści i tak pisali po swojemu
retrospekcje upadły; standardy przestały się rozwijać, w końcu stały się nieadekwatne do obecnej sytuacji i przeszkadzały w pisaniu

Co się u licha stało? - zapytali kierownicy. Przecież chcieliśmy dobrze :(

Konflikt wartości

Znajomy metodolog zajmujący się badaniem hierarchii wartości u pracowników (bywa, że firmy chcą wiedzieć co jest dla Ciebie ważne: rozwój, profesjonalizm, bezpieczeństwo, kariera i w jakiej kolejności) wyłożył mi cierpliwie, że w żadnym poważnym teście nie zestawia się wartości istotnych w miejscu pracy z wartościami typu: rodzina, zdrowie, gdyż te pierwsze zawsze muszą przegrać. Gdy test nie szanuje tej zasady, to otrzymujemy zafałszowane dane, gdyż wyniki testu będą "skrzywione" w kierunku właśnie rodziny, zdrowia itp. W sumie logiczne, że gdy mam do wyboru karierą versus trwały uszczerbek na zdrowiu, to motywowany samozachowawczym instynktem, będę chronił swoje zdrowie, nawet kosztem kariery.

W omawianym wyżej zespole, kierownicy popełnili właśnie ten metodologiczny błąd No, bo jeśli wybieram między zmieszczeniem się w szacowaniach (nawet jeśli trzeba by ociupinkę je zawyżyć), a gwiazdkowymi prezentami dla rodziny, to szacowanie będzie idealne - choćby nie wiem co! I wcale nie w tym rzecz, że jesteśmy źli, upadli, oszuści. Nic z tych rzeczy. Tak jesteśmy skonstruowani, a granica między rzetelnym oszacowaniem a nieco zawyżonym jest tak płynna, tak rozmyta, że bardzo łatwo i bardzo szybko racjonalizujemy sobie drobne jej przekroczenia. Myślę, że większą winę ponosi ten, kto doprowadził do sytuacji sprzyjającej takiemu postępowaniu, niż ten kto rzeczywiście tak postępuje.

Opłakane skutki

Ponieważ przestrzeganie standardów było tylko środkiem do celu, standardy przestały się rozwijać, przestały żyć. W niczyim interesie nie było modyfikowanie standardów i ulepszanie ich. Po zmieniać i komplikować sposób na zarabianie, skoro już mam opracowane sposoby wygrywania?

Motywowanie pieniędzmi jest w porządku, gdy w działaniu ludzi o pieniądze przede wszystkim chodzi. Weźmy takich na przykład sprzedawców. W uproszczeniu: sprzedawca sprzedaje produkt/usługę i przynosi pracodawcy fakturę, od której otrzymuje procent. To będzie działać. Ale jeśli sprzedawca będzie dostawał premię za ilość spotkań, to znów zaczyna się GRA. Bo oto może się okazać, że spotkania są i owszem, ale z firmami, które prawdopodobnie nigdy nie zostaną naszymi klientami. Kto za to ponosi odpowiedzialność? Przede wszystkim ten, kto stworzył GRĘ.

Gdy Twoi pracownicy pracują kreatywnie (tu programiści) i zasady pracy muszą dojrzewać i ulepszać się wraz z nimi, to nigdy przenigdy nie wolno uzależniać wynagrodzenia od ich przestrzegania. Takie działanie zabije kreatywność i zasady pracy szybko się usztywnią.

Przestrzegaj standardów "bo warto"

By standardy w zespole działały i ewoluowały muszą być ważne tak po prostu. Ludzie muszą widzieć w nich wartość, muszą chcieć ich przestrzegać, muszą dostrzegać, że dzięki nim stają się lepsi. Tak właśnie działali pierwsi członkowie zespołu z naszego obrazka. Wtedy standardy będą ewoluowały, a ludzie będą chętnie je rozwijać. W przeciwnym razie ryzykujesz, że standardy będziesz wprowadzał sam, siłowo, albo za pomocą nowo zatrudnionych członków Komitetów Standaryzacyjnych i tak skomplikujesz zasady GRY, że już nikt nie połapie się o co w ogóle na samym początku chodziło.

A co z pieniędzmi?

Opisaną scenę można by streścić następująco: Motywuj ludzi pozafinansowo, ale płać im dobrze...:) W sumie nic dziwnego - jeśli podstawowe potrzeby nie są zaspokojone, to nie ma co myśleć o tych wyższych. Oczywiście, że potrzeba tu wyważenia, złotego środka, w końcu każdy budżet jest ograniczony. "Płacić dobrze" zazwyczaj nie oznacza "więcej niż konkurencja". Może być nawet mniej w zamian za inne pozafinansowe dobra. To jest sprawa bardzo indywidualna i chcę robić nieuprawnionych uogólnień.

Ludzie książki piszą

2011-09-27T09:04:00.000+02:00

Wydaliśmy naszą drugą książkę. Pierwszą próbą był ebook Jak całkowicie odmienić sposób programowania używając refaktoryzacji. Najnowsza książka nosi tytuł Eseje o efektywności programistów. Opiera się na artykułach, które opublikowaliśmy w SDJ w ciągu ostatnich dwóch lat. (tak na marginesie: książka ma 143 strony, na zdjęciu wygląda nieco grubiej:) )

Zaskakujące jest to, że redagując ponownie artykuły do książki stwierdzaliśmy, że wciąż są aktualne. O czym więc jest ta książka? O zespołach, trochę o projektach, o zarządzaniu czasem, nieco o refaktoryzacji. W tej chwili przygotowaliśmy nakład ok. tysiąca egzemplarzy, gdyż książka (podobnie jak poprzednia) wstępnie przeznaczona jest dla uczestników naszych szkoleń. Jeśli uważasz, że książka powinna być dostępna dla każdego, to daj znać pod postem:)

Dalej, w przygotowaniu (w trakcie pisania) jest kolejna książka o roboczym tytule Między Biznesem a IT, czyli sztuka zadawania pytań. Dedykowana jest wszystkim osobom (programistom, analitykom, liderom), którzy w procesie wytwarzania oprogramowania mają przyjemność bezpośredniego współpracowania z klientem/sponsorem/użytkownikiem. Książka uwypukla aspekt, który jest nagminnie marginalizowany w publikacjach nt: requirements management - mianowicie sam etap pozyskiwania wymagań. Ramowy outline tej książki wygląda następująco:

O postępach będę informował na bieżąco.

Dzień programisty

2011-09-13T06:29:00.002+02:00

Podobno dziś jest dzień programisty. Wszystkiego naj* zatem:)

Interfejs budowniczego

2011-08-09T22:52:00.023+02:00

Na przykład tutaj można dowiedzieć się o niezwykłych korzyściach stosowania wzorca Builder (na przykład do wypiekania pizzy:)). Używam zatem, ale ten budowniczy mi więcej przeszkadza niż pomaga. Można pokusić się o stwierdzenie, że to tylko dodatkowa i nad wyraz rozdmuchana warstwa pośrednia, która niczego użytecznego nie wnosi. Ot, tworzy kilka obiektów i już.

Jak wspomniałem plusy dodatnie i ujemne budowniczego były już nie raz szeroko omawiane. Mnie interesuje odpowiedź na inne pytanie: W jaki sposób zaprojektować interfejs budowniczego?. To znaczy:

Jak zdecydować jakie metody powinien mieć budowniczy?
Jak go sensownie używać (pragmatycznie, nie sztuka dla sztuki), aby pomagał, a nie przeszkadzał?

Ponieważ debugowałem blog Sławka, żeby podłączyć syntaxhighlightera, to pożyczyłem sobie Order i OrderItem do przykładu:).

Koncept jest następujący: mamy aplikację do składania zamówień na produkty. Zamówienie składa się z grup produktowych, a te składają się z produktów, jak na rysunku.

Dla uproszczenia załóżmy, że jest to aplikacja konsolowa. Właściciel oczekuje, że będzie pracował z aplikacją następująco:



Podaj identyfikator zamówienia: Paczka-E112 

Podaj priorytet zamówienia: 1

Podaj nazwy grup produktowych: spożywcze chemia zabawki

Podaj ilość porduktów dla grupy 'spożywcze': 2

Dodaj produkt dla grupy 'spożywcze': sałata 2,45zł 2

Dodaj produkt dla grupy 'spożywcze': morele 6,79zł 1

Podaj ilość porduktów dla grupy 'chemia': 3

...

Startuję z następującym zestawem klas:

public class Order {

  private String id;

  private int priority;

  private Set itemGroups = new HashSet();

}

public class ItemGroup {

  private String name;

  private Set items = new HashSet();

}

public class Item {

  private String name;

  private Money price;

  private int quantity;

}

Za wykonanie zadania Dodawanie zamówienia, odpowiedzialną uczyńmy klasę:

public class UserInterface { 

  private Set orders = new HashSet();

  public void addOrder() {

    // TOIMPL

  }	

  public static void main(String[] args) {

    new UserInterface().addOrder();

  }

}

W pierwszym podejściu kod, który działa, mógłby wyglądać na przykład tak:

public void addOrder() {

  Scanner scanner = new Scanner( System.in );

  System.out.print( "Podaj identyfikator zamówienia: " );

  String orderId = scanner.nextLine();

  System.out.print( "Podaj priorytet zamówienia: " );

  int orderPriority = Integer.parseInt( scanner.nextLine() );

  Order order = new Order( orderId, orderPriority );

  System.out.print( "Podaj nazwy grup produktowych: " );

  String[] itemGroupsNames = scanner.nextLine().split( " " );

  for ( int i = 0; i < itemGroupsNames.length; ++i ) {

    ItemGroup itemGroup = new ItemGroup( itemGroupsNames[ i ] );

    System.out.print( "Podaj ilość produktów dla grupy '" + itemGroupsNames[ i ] + "' : " );

    int itemsAmount = Integer.parseInt( scanner.nextLine() );

    for( int j = 0; j < itemsAmount; ++j ) {

      System.out.print( "Dodaj produkt dla grupy '" + itemGroupsNames[ i ] + "' : " );

      String[] itemParams = scanner.nextLine().split( " " );

      String itemName = itemParams[ 0 ];

      Money itemPrice = Money.parseMoney( itemParams[ 1 ] );

      int itemQuantity = Integer.parseInt( itemParams[ 2 ] ); 

      Item item = new Item( itemName, itemPrice, itemQuantity );		

      itemGroup.addItem( item );

    }

    order.addItemGrup( itemGroup );

  }

  orders.add( order ); 

}

Po pobieżny przyjrzeniu się temu rozwiązaniu, można zauważyć, że nastąpiło tu pewne pogmatwanie. Komunikowanie się z użytkownikiem (wyświetlanie komunikatów i odbieranie wpisanych danych) zostało zmiksowane z kodem biznesowym (budowanie zamówienia).

W pierwszym zachwycie nad wzorce Builder mam ogromną ochotę go użyć! UWAGA jeśli przychodzi ci go głowy napisać klasę OrderBuilder z jedną metodą build mającą kilkanaście parametrów, to nie tędy droga. Wyszedł by z tego nie budowniczy ale jakieś fabrykoniewiadomoco.

Wracając do tematu: wprowadźmy zatem ad hoc budowniczego (bo ponoć to dobra praktyka). Budowniczy ten mógłby wyglądać następująco:

public class OrderBuilder {

  private Order order;

  public void newOrder( String orderId, int orderPriority ) {

    order = new Order( orderId, orderPriority );

  }

  public Order getOrder() {

    return order;

  }

  public void addItemGroup( String name ) {

    order.addItemGrup( new ItemGroup( name ) );

  }

  public void addItem( String groupName, String name, Money price, int qty ) {

    ItemGroup group = order.findItemGroup( name );

    group.addItem( new Item( name, price, qty ) );

  }

}

Kluczowe pytanie: Czy ten budowniczy jest pomocny?

Już zerkając na kod budowniczego, można mieć wątpliwości. Właściwie nie robi nic ponad, enkaspulację wywołań konstruktorów oraz metod dodających. Ok, można go sobie mokować i dodawać nowe implementacje, ale zobaczmy jak wygląda kod, który użytkuje tego budowniczego:

public void addOrder() {

  Scanner scanner = new Scanner( System.in );

  System.out.print( "Podaj identyfikator zamówienia: " );

  String orderId = scanner.nextLine();

  System.out.print( "Podaj priorytet zamówienia: " );

  int orderPriority = Integer.parseInt( scanner.nextLine() );

  OrderBuilder builder = new OrderBuilder();

  builder.newOrder( orderId, orderPriority );

  System.out.print( "Podaj nazwy grup produktowych: " );

  String[] itemGroupsNames = scanner.nextLine().split( " " );

  for ( int i = 0; i < itemGroupsNames.length; ++i ) {

    builder.addItemGroup( itemGroupsNames[ i ] );

    System.out.print( "Podaj ilość produktów dla grupy '" + itemGroupsNames[ i ] + "' : " );

    int itemsAmount = Integer.parseInt( scanner.nextLine() );

    for( int j = 0; j < itemsAmount; ++j ) {

      System.out.print( "Dodaj produkt dla grupy '" + itemGroupsNames[ i ] + "' : " );

      String[] itemParams = scanner.nextLine().split( " " );

      String itemName = itemParams[ 0 ];

      Money itemPrice = Money.parseMoney( itemParams[ 1 ] );

      int itemQuantity = Integer.parseInt( itemParams[ 2 ] ); 

      builder.addItem( itemGroupsNames[ i ], itemName, itemPrice, itemQuantity );

    }

  }

  orders.add( builder.getOrder() );

}

Jest tak samo brzydki jak był! Budowniczy nie wniósł znaczącego wkładu do tego kodu. Moim zdaniem interfejs budowniczego należy projektować z perspektywy klienta. Pisząc klient mam na myśli usługę, która akurat budowniczego będzie wykorzystywać - w tym przypadku jest to klasa UserIterface. Interfejs budowniczego powinien być wygodny dla klienta.

Krok 1: Dlaczego ItemGroup i Item trzeba dodawać pojedynczo?

Wcale nie trzeba...Przecież budowniczy może mieć metody, które przyjmą input, który przyszedł od użytkownika i samodzielnie go zinterpretuje. Pytanie: Czy czasem znów nie dojdzie do pomieszania warstw? Nie nie dojdzie. Przeanalizujmy odpowiedzialności poszczególnych klas:

Order, ItemGroup, Item - to model dziedziny, reprezentuje rzeczywistość
UserInterface - komunikuje się z użytkownikiem; odbiera od niego żądania (wpisy z konsoli) i przekazuje je do odpowiednich elementów niżej; prezentuje użytkownikowi wynik działania systemu
OrderBuilder - służy do złożenia zamówienia z mniejszych elementów

Zatem jeśli budowniczy może spokojnie przyjąć stringi podane przez użytkownika, a potem je zinterpretować. Dopóki budowniczy nie zacznie pisać na konsolę, to odpowiedzialność klas zostanie zachowana. Zobaczmy jak to mogłoby wyglądać:

public class OrderBuilder {

  private Order order;

  public void newOrder( String orderId, int orderPriority ) {

    order = new Order( orderId, orderPriority );

  }

  public void addItemGroups( String itemsGroupsInput ) {

    String[] itemGroupsNames = itemsGroupsInput.split( " " );	

    for ( int i = 0; i < itemGroupsNames.length; ++i ) {			

      order.addItemGrup( new ItemGroup( itemGroupsNames[ i ] ) );

    }

  }

  public void addItem( String itemParamsInput ) {

    String[] itemParams = itemParamsInput.split( " " );

    String groupName = itemParams[ 0 ];

    ItemGroup group = order.findItemGroup( groupName );

    Money price = Money.parseMoney( itemParams[ 1 ] );

    int qty = Integer.parseInt( itemParams[ 2 ] ); 	 

    group.addItem( new Item( groupName, price, qty ) );

  }

  public Order getOrder() {

    return order;

  }

}

Jak widać budowniczy zmądrzał nieco, potrafi zrobić coś więcej niż proste dodawanie. A jak wygląda korzystanie z niego?

public void addOrder() {

  Scanner scanner = new Scanner( System.in );	

  System.out.print( "Podaj identyfikator zamówienia: " );

  String orderId = scanner.nextLine();

  System.out.print( "Podaj priorytet zamówienia: " );

  int orderPriority = Integer.parseInt( scanner.nextLine() );

  OrderBuilder builder = new OrderBuilder();

  builder.newOrder( orderId, orderPriority );

  System.out.print( "Podaj nazwy grup produktowych: " );

  String itemsGroupsInput = scanner.nextLine();

  builder.addItemGroups( itemsGroupsInput );

  String[] itemGroupsNames = itemsGroupsInput.split( " " );

  for ( int i = 0; i < itemGroupsNames.length; ++i ) {

    System.out.print( "Podaj ilość produktów dla grupy '" + itemGroupsNames[ i ] + "' : " );

    int itemsAmount = Integer.parseInt( scanner.nextLine() );

    for( int j = 0; j < itemsAmount; ++j ) {

      System.out.print( "Dodaj produkt dla grupy '" + itemGroupsNames[ i ] + "' : " );

      String itemParamsInput = scanner.nextLine();

      builder.addItem( itemParamsInput );

    }

  }

  orders.add( builder.getOrder() );

}

Choć nie idealnie to jednak jest nieco lepiej - metoda mieści się na jednym ekranie:)

Krok 2: Chodzenie po strukturze zamówienia

To, co nam bruździ to fakt, trze trzeba dodać Items do każdej z ItemGroup. Więc najpierw za pomocą OrderBuilder.addItemGroups tworzone są wszystkie grupy, ale jeszcze dodatkowo UserInterface przetrzymuje sobie jeszcze tablicę nazw grup produktowych, że by po nich przeiterować i dodać pozycje zamówienia. Wydaje się to trochę nienaturalne, ponieważ ta sama informacja jest przechowywana w dwóch różnych formach (String[] i Set) w dwóch różnych miejscach (UserInterface i OrderBuilder).

Skoro chcemy tylko chodzić po wewnętrznej strukturze zamówienia (przesuwać się do kolejnych grup i dodawać produkty), to dlaczego nie wyposażyć budowniczego w tę możliwość. Niech budowniczy udostępni zestaw metod do chodzenia po grupach produktowych. Zobaczmy:

public class OrderBuilder {

  private Order order;

  private Iterator groupIterator;	

  private ItemGroup currentGroup;

  public void newOrder( String orderId, int orderPriority ) {

    order = new Order( orderId, orderPriority );

  }

  public void addItemGroups( String itemsGroupsInput ) {

    String[] itemGroupsNames = itemsGroupsInput.split( " " );		

    for ( int i = 0; i < itemGroupsNames.length; ++i ) {			

      order.addItemGrup( new ItemGroup( itemGroupsNames[ i ] ) );

    }

    groupIterator = order.getItemGroups();

  }

  public void addItem( String itemParamsInput ) {

    String[] itemParams = itemParamsInput.split( " " );

    String groupName = itemParams[ 0 ];

    Money price = Money.parseMoney( itemParams[ 1 ] );

    int qty = Integer.parseInt( itemParams[ 2 ] ); 	 

    currentGroup.addItem( new Item( groupName, price, qty ) );

  }

  public Order getOrder() {

    return order;

  }	

  public boolean hasNextItemGroup() {

    if ( groupIterator == null ) {

      return false;

    }		

    return groupIterator.hasNext();

  }

  public void moveNextItemGroup() {

    currentGroup = groupIterator.next();

  }	

  public String getCurrentItemGroupName() {

    return currentGroup.getName();

  }	

}

Natomiast korzystanie z budowniczego wygląda następująco:

public void addOrder() {

  Scanner scanner = new Scanner( System.in );	

  System.out.print( "Podaj identyfikator zamówienia: " );

  String orderId = scanner.nextLine();

  System.out.print( "Podaj priorytet zamówienia: " );

  int orderPriority = Integer.parseInt( scanner.nextLine() );

  OrderBuilder builder = new OrderBuilder();

  builder.newOrder( orderId, orderPriority );

  System.out.print( "Podaj nazwy grup produktowych: " );

  builder.addItemGroups( scanner.nextLine() );

  while ( builder.hasNextItemGroup() ) {

    builder.moveNextItemGroup();

    System.out.print( "Podaj ilość produktów dla grupy '" +       builder.getCurrentItemGroupName() + "' : ");

    int itemsAmount = Integer.parseInt( scanner.nextLine() );

    for( int j = 0; j < itemsAmount; ++j ) {

      System.out.print( "Dodaj produkt dla grupy '" + builder.getCurrentItemGroupName() + "' : " );

      builder.addItem( scanner.nextLine() );

    }

  }

  orders.add( builder.getOrder() );

}

Teraz już klasa UserInterface zajmuje się wyłącznie komunikacją z użytkownikiem, natomiast budowniczy zajmuje się składaniem zamówienia do kupy. Każda z klas zachowała swoją odpowiedzialność, a z używanie budowniczego rzeczywiście przynosi korzyści klientowi większe niż tylko enkapsulacja konstruktorów i dodawania do list. Dzięki wykorzystaniu budowniczego kod kliencki staje się prostszy i bardziej przejrzysty.

Dla porządku trzeba dodać, że odpowiedzialność budowniczego została zwiększona. Potrafi on teraz również chodzić po strukturze zamówienia. Jest więc jednocześnie Iteratorem. Dalej warto metody iterator wydzielić do osobnego interfejsu, ale to już nieco inna historia.

Ogłoszenie: Będę w Gdańsku :)

2011-07-11T09:23:00.004+02:00

Nawiązując do posta , na temat współpracy z BNS IT w charakterze Trenera/Konsultanta:

Będę w Gdańsku w dniach 12-13 lipca br. Jeśli mieszkasz w tamtych okolicach i masz ochotę porozmawiać o potencjalnej współpracy daj mi znać pod nr (wycięte,bo nieaktualne:)) lub moje_imię kropka moje_nazwisko na serwerze bnsit kropka pl.

Poza wzorcami projektowymi

2011-07-06T22:43:00.011+02:00

To jest odległa kontynuacja artykułu Język wzorców.

Nie pamiętam już u kogo, ale wyczytałem, że jedną z przyczyn powstania wzorców projektowych, było rozwiązanie różnego rodzaju bolączek technologicznych albo bolączek konkretnych języków programowania. Zacząłem się nad tym zastanawiać. I tak:

Null Object - bo w C++ referencja musi być zainicjowana; wyeliminowane przez Java, C# (nieścisłość, @see Komentarz pod postem Chrisphera Daniela)
State - bo implementacja maszyny stanów oparta o tablicę wskaźników do funkcji oraz serię switch/case
Interpreter - jaki tam wzorzec;)? sposób na parsowanie ustrukturyzowanych gramatyk i tyle; wyeliminowane przez tony bibliotek narzędziowych
Flyweigh - bo nie ma kasy na więcej pamięci
Command - w C# wykoszony przez delegaty (mam na myśli ten kontekst użycia, w którym robimy execute(), a nie przechowujemy komendę, aby ją potem handle() )
Właściwie wszystkie wzorce opisane w Core J2EE Patterns i PoEAA - zastąpione przez biblioteki, frameworki i technologie

Czym zatem są wzorce projektowe? Mówi się, że rozwiązaniami typowych problemów. Rozwiązaniami, które wg Alexandra, można stosować za każdym razem nieco inaczej (nieco inna implementacja), ale otrzyma się poprawne rozwiązanie konkretnego problemu. W porządku - może postęp technologiczny modyfikuje tylko implementacje wzorców, lecz idea zostaje podobna. Może jednak nie - czy w wzorzec zamknięty w wszytywne API biblioteki wciąż jest wzorcem, czy tylko zwyczajnym narzędziem pomocniczym?

Jak powstają?
Skąd się biorą i jak powstają? Istnieją trzy elementarne zasady postępowania, które prędzej czy później doprowadzą do dobrego rozwiązania obiektowego:

Przestrzegaj opodwiedzialności: Jeśli nie potrafimy czegoś nazwać, to prawdopodobnie nie rozumiemy jak to działa. Nie znamy odpowiedzialności tego czegoś. W swoim kodzie dbaj o to, aby każda: zmienna, metoda, klasa, interfejs, pakiet, moduł miały określoną tylko jedną opodwiedzialność, która będzie wyrażona nazwą
Enkapsuluj: To, co podlega zmianom, powinno zostać opakowane (w metodę lub w klasę - w zależności od potrzeby). Enkapsulacja pozwala na łatwiejsze zarządzanie zmianą w kodzie. Nie mówiac już o testowaniu.
Preferuj kompozycję ponad dziedziczenie: Związki używania czynią kod bardziej elastycznym, czytelnym i testowalnym. Dodatkowo pozwalają na rozszerzanie funkcjonalności kodu run-time, a nie tylko poprzez przekompilowanie.

Jeśli przestrzegamy tych zasad, prawie na pewno powstanie dobry kod. Jest jeden warunek: trzeba stosować je bardzo skrupulatnie. Żadnego wkuwania nazw wzorców, diagramów, definicji, itd. Zamiast tego: żelazna dyscyplina w stosowaniu w/w zasad.

Wymienione reguły są dość niskopoziomowe, w całościowy proces ujmuje koncept, który nazwaliśmy roboczo Nautralnym porządkiem refaktoryzacji.

Koncept Nautralnego porządku refaktoryzacji

Pisał już o tym sporo Mariusz w artykułach: NPR - Idea rysunkowa, NPR - pod lupą, NPR: Compose Method, NPR: Extract Method, NPR: Refaktoryzacja do wzorców, NPR: Ewolucja architektury, więc nie będę się powtarzał.

Powtarzając konsekwentnie ten proces i stosując wspomniane już trzy metody, otrzymujemy naprawdę porządny kod. Zaczynają pojawiać się dobre rozwiązania. Dość często są to znane wzorce projektowe.

Morfizmy w kodzie
Zauważmy, że w charakterystyka wzorca projektowego zawiera między innymi Motywację/Intencję, Kontekst, Problem. Według definicji wzorzec to rozwiązanie problemu w danym kontekście. Ale przecież nieustanie zmienia się zarówno kontekst, jak i nasze zrozumienie problemu. Wszystko się zmienia!

Aktualne dobre rozwiązanie, które przywykliśmy nazywać wzorcem projektowym, jest tak naprawdę lokalnym optimum, jakieś funkcji (powiedzmy, że Funkcji kodu) w której zmiennymi są przynajmniej: Kontekst oraz Problem.

Tak zwany wzorzec rozwiązuje problem tylko na chwilę, dopóki Funkcja kodu nie ulegnie zmianie, a optimum nie wystrzeli w inną stronę. Mamy wiec do czynienia nie tyle z wzorcami, co z optymalnymi morfizmami w kodzie (niech, Ockham mi wybaczy). Zmiana Funkcji kodu, po której programując się ślizgamy powoduje, że dany morfizm przestaje być optymalny i musimy poszukać nowego optimum właśnie poprzez refaktoryzację.

Optymalne morfizmy

Wnioski
Czy poza gimnastyką umysłu wypływają stąd jakieś wnioski? Owszem, kilka.

Istnieje nieskończenie wiele optymalnych morfizmów w kodzie - ponieważ zakres zmienności Problemów oraz Kontekstów jest również nieskończony; w związku z tym publikacje i dywagacje na temat nowych wzorców projektowych nigdy się nie skończą
Refaktoryzacja musi trwać - ponieważ Funkcja kodu wciąż się przekształca, wciąż musimy poszukiwać optymalnych morfizmów; zaprzestanie tych działań spowoduje takie zniekształcenie tej funkcji, że znalezienie optymalnych morfizmów będzie niemożliwe i trzeba będzie ją wyrysować na nowo - czytaj napisać system raz jeszcze
Ważniejsze jest zdyscyplinowane posługiwanie się wspomnianymi wyżej zasadami i procesem refaktoryzacji niż szastanie kolekcjami nazw wzorców
Nie jest możliwe stworzenie czegoś takiego jak patterns language (por: On Patterns and Pattern Languages), bo optymalne morfizmy wciąż się przekształcają podążając za zmianami Funkcji Kodu

PEA(3): Wyodrębnianie user stories

2011-06-27T22:30:00.012+02:00

To jest artykuł z serii Proces ewolucji architektury.

Po dość zgrubnym rozeznaniu się w środowiskowym kontekście systemu, jest czas na nieco więcej konkretów na temat funkcjonalności.

Część I - Przygotowanie

Dobór grupy
Do wyodrębnienia user stories świetnie nadają się spotkania focusowe. I ty pytanie z kim?
Najlepiej, aby grupa była różnorodna. Jednorodne grupy mają tendencję do "krzywienia" user stories. Na przykład programiści formułują je bardzo crudowo.

Aktorzy
Jeśli to możliwe, już na samym początku zidentyfikuj aktorów. Zadaj sobie pytanie Kto będzie wołał ten system?. W tym momencie masz już wstępnie rozpoznanych na następujących aktorów:

inne systemy - ponieważ poznałeś kontekst pracy systemu
użytkownik - na razie to dość ogólne sformułowanie, taki metaaktor, którego pojęcie będzie dokonkretyzowywać się w trakcie dalszych rozmów
dla porządku warto dorzucić jeszcze jednego: Time ; bojownicy o czystość UMLa mnie przeklną, ale wygodnie mieć tych aktorów dla spraw wyzwalanych czasem; jest to wygodne tylko i wyłącznie z tego powodu, aby nie bawić się w dodatkowe tabelki, gdy zajdzie potrzeba wysmarowania pięknego diagramu

Rysunek 1: Wstępny szkic aktorów w systemie

Wstępne nazwanie aktorów pomaga konkretnej zadawać pytania. Głównie o to tu chodzi.

Konwencja nazewnicza
Ustal ramową konwencję nazewniczą, zazwyczaj są dwie konkurencyjne alternatywy:

anglojęzyczna - działa proporcjonalnie do swobody językowej
polskojęzyczna - często jeden do jednego przekłada słownictwo binzesowe, ale w kodzie będą wychodzić zabawane pongliszowe kwiatki

Najkorzystniej jest promować taką konwencję nazewniczą, która zmienia jak najmniej przyzwyczajeń.

Najczęściej słownictwo biznesowe jest zlepkiem z polskiego, angielskiego, a czasem i z innych języków i trudno je uspójniać. Zmiana organizacyjnej nowomowy trochę boli, ale przynosi niepomierne korzyści w postaci wzajemnego zrozumienia. Wypraktykowałem, że zamiast próbować udowadniać ludziom, że mają złe przyzwyczajenia, o wiele lepiej działa zadawanie pytań uwypuklające niejednoznaczność słownictwa. Na przykład:
Co ma Pan na myśli mówiąc <<szkolenie>>. To <<program>> szkolenia, czy <<czynność>> prowadzenia szkolenia? Acha, rozumiem, czyli możemy mówić o szkoleniu <<możliwym do zorganizowania>> oraz <<zorganizowanym>> szkoleniu?

Pułapką uspójniania słownictwa jest synonimia nomenklaturze organizacji. Śmiało można zaryzykować stwierdzenie, że każdy dział ma nieco inne nazwy na te same rzeczy i procesy.

Rysunek 2: różne nazwy na te same rzeczy, to jedna z większych trudności

Tego typu różnice dość szybko wychodzą, jeśli zadbasz o wspomnianą wcześniej różnorodność grupy.

Kto nazywa ten rządzi
Jak najszybciej ustalcie nazwę dla systemu. W przeciwnym razie, będziesz rozmawiać o oderwanych funkcjonalnościach, co sprawi, że zakres systemu będzie stale i nieograniczenie się powiększał.

Najlepiej, aby nazwa wzięła się z rzeczywistości np.: kalendarz elektroniczny, aby występowała w informatyzowanym procesie. Łatwo wtedy eliminować wodotryski, zadając proste pytanie Czy dotychczas w kalendarzu również miał Pan możliwość dodawania awatarów?

Nic nie mówiące i zbyt ogólne nazwy z kategorii Zintegrowany System Informatyczny, to otwarta furtka do wylądowania poza budżetem lub terminem lub oboma jednocześnie.

Część I - Prowadzenie sesji wyodrębniania user stories

Zasady ogólne
Przed przystąpieniem do sesji wygodnie jest mieć jakiś szkic interfejsu użytkownika, żeby skupić uwagę osób. Jeśli ich nie ma to je rysuj. Rysowanie dobrze ogniskuje uwagę i często lepiej pozwala wyrazić myśli.

Historycznie user storier spisywane są na małych kartkach. Powiedzmy sobie jednak szczerze, że arkuszem Excela o wiele lepiej się zarządza.
Jak to zatem jest z tymi karteczkami? Z całego serca polecam karteczki (żółte, samoprzylepne :) ). Mają one tę wielką zaletę, że budują zaangażowanie interesariuszy. Osoby na spotkaniu są często przytłoczeni dużą liczbą obowiązków, nieco zmęczeni i teraz jeszcze muszą odbębnić z nami spotkanie. Mimo, że rzeczywiście chcą tego systemu, to nie chcą na niego poświęcać czasu - nielogiczne, ale prawdziwe.

Jeśli będziesz zachęcać ludzi, aby sami pisali user stories na karteczkach i dodatkowo przyklejali je na fipcharcie, to "wciągną się" w spotkanie, będą bardziej kreatywni. Budując zaangażowanie, zwiększasz swoje szanse na wyodrębnienie rzeczywistych oczekiwań co do systemu zamiast ogólników, które czasem ktoś może chcieć Ci wcisnąć, żebyś tylko dał mu spokój. Zaangażowanie - to jest rzeczywisty cel karteczek.

Rzecz jasna, że po spotkaniu możesz przepisać je do Excela, skoro w ten sposób łatwiej nimi zarządzać. Nie jestem fanem zbyt szybkiego wprowadzania narzędzi. Narzędzia (zwłaszcza takie, które narzucają swój proces pracy) częściej przeszkadzają niż pomagają. Fanom narzędzi chętnie polecam Scrum Do. Jest bardzo grywalne, zawiera wszystko co potrzeba, a jednocześnie jest kompletnie nieinwazyjne. Minusem jest to, że działa on-line.

Formułowanie historyki

Ogólny algorytm prowadzenia sesji wygląda tak:

Ustal uwagę na pierwszym ekranie
Zadaj pytanie: Co można zrobić na tym ekranie?
Skłoń ludzi, aby sformułowali swoje oczekiwania w następujący sposób: Jako <<kto?>>mogę <<funkcjonalność>>, aby <<po co?>>

Struktura zdania, za pomocą którego formułujemy historyjki, jest bardzo chytra. Każda z części tego zdania ma swój ściśle określony cel. Przyjrzyjmy się jej bliżej.

Jako <<kto?>> - tu konkretyzujemy aktorów (role); funkcjonalności nie są zawieszone w powietrzu; dzięki przyporządkowaniu historyjek do ról, łatwiej na późniejszym etapie ogarnąć zasady bezpieczeństwa dostępu do systemu
mogę <<funkcjonalność>> - tu precyzujemy konkretną funkcjonalność, do której dany użytkownik ma mieć dostęp
aby <<po co?>> - ta bardzo ważna część, pomaga użytkownikom uświadomić sobie potrzeby oraz problemy, które zamierzają zaspokoić i rozwiązać za pomocą tej funkcjonalności; dodanie tej części eliminuje sporo niepotrzebnych funkcjonalności, bo gdy ludzie zaczynają zastanawiać się po co coś będzie potrzebne, to czasem dochodzą do wniosku, że po nic

Ogólniki i szczególiki
Podczas spisywania historyjek, możemy otrzymać efekt dwojakiego rodzaju:

konkretne user stories: np.: Jako U mogę zobaczyć listę swoich zamówień, aby wiedzieć co już otrzymałem, a czego jeszcze nie; do takich sformułowań zmierzamy podczas pracy z interesariuszami
niekonkretne user stories: np. Jako P mogę zarządzać dokumentami?; słowo "zarządzać" niewiele mówi o tym co właściwie należy zrobić, być może kryje się za tym jakiś ogromniasty epic;

Prawdopodobnie będziesz mieć chęć, aby drążyć niekonkretne historyki, gdy tylko użytkownicy je sformułują. Kłopot w tym, że prawdopodobnie oni sami jeszcze nie przemyśleli co to konkretnie ma być. Proponuję, by chwilowo zostawić je w spokoju. Zapisz je i wróć do nich później, już po sformułowaniu wszystkich user stories.

Dodatkowe porady
Podczas sesji ludzie spierają się o to, co właściwie ma robić dana rola i dość szybko zaczynają roztrząsać kwestie techniczne. Nie daj się wciągnąć w tę dyskusję, ucinaj ją natychmiast i prowadź spotkanie dalej. Na tym etapie eksploracja "w szerz" zamiast w "głąb" zagadnienia, pozwoli Ci szybciej przyswoić sobie wiedzę domenową.

Tego typu spotkania wygodnie jest prowadzić w dwie osoby. Jedna aktywnie moderuje rozmowę, druga nieco mniej zaangażowana zachowuje big picture i wkracza w razie kłopotów.

Obiektowość dla embedded?

2011-06-16T23:44:00.005+02:00

Często zdarza mi się wypełzać poza Javę, z której wyrosłem i ze zdziwieniem stwierdzam, że są inne obszary, w których ludzie mają podobne do naszych problemy i z utęsknieniem spoglądają w stronę gadżetów którymi dysponujemy.

Jakiś czas temu, konstruktywnie krytykując mój wpis, Sławek powiedział mniej więcej coś takiego: "Kto w obecnych czasach podaje w książkach przykłady w C++? Od razu widać, że old school"

Rzeczywiście, większość koncepcji związanych z: refaktoryzacją, TDD, clean code itd. nabrała obecnego kształtu w okół Javy i C# i ich community (tak, tak, pamiętam: Small Talk, C++, GoF - byli pierwsi :)). Jakby te języki były jedyne, dominujące, a inne to tylko marginalne ekstrawagancje. Zerknijmy na ten ranking. Jak widać Java i C# mają towarzystwo i to całkiem spore.

RTS, Entertainment
Mówię o systemach embedded, ale nie telefonach, grach i smartach, gdyż im (wg programistów embedded) bliżej raczej do PC-tów. Mówię o: systemach czasu rzeczywistego, systemach sterowania produkcją, oprogramowaniu obsługującym stacje bazowe w sieciach komórkowych, o komputerach pokładowych w samochodach, o sofcie który jest zainstalowany na naszych kartach kredytowych. Kto by pomyślał, że na takiej karcie jest procesor, a na nim system operacyjny, a na nim dziarsko działa maszyna wirtualna Javy? (@see Java Card)

C rządzi!
We wspomnianych wyżej domenach często króluje język C. Po pierwsze z powodów historycznych - ktoś zaczął pisać w C i tak już zostało.

W miarę rozrostu tego typu systemów, pojawiają poważne problemy z ich utrzymaniem. Miliony wierszy kodu, gęsto pociętych przez dyrektywy kompilatora, kompilacje warunkowe, ifdefy, makra tam, gdzie to tylko możliwe oraz specyficzny sposób oszczędnego nazywania zmiennych zdecydowanie utrudniają rozwijanie tego kodu. Te problemy powodują, że środowisko embedded coraz częściej rozgląda się za podejściem obiektowym, które pomoże tworzyć łatwiejszy w utrzymaniu kod. Napotykają jednak na pewne przeszkody, które budują przekonanie, że obiektowość nie jest dla embedded. Zebrałem nieco informacji nt. tych przeszkód. Niektóre z nich są rzeczywiscie zaskakujące, inne to raczej przekonania.

Brak kompilatorów
Do pewnego momentu nie było zwyczajnie technicznej możliwości skomplikowania kodu. Jeśli już jakieś istniały, to były tak zabugowane, że dyskwalifikowały się same przez się. Sytuację poprawił gcc, który popchnął sprawę nieco do przodu.

Koszt wejścia
O ile maszyna wirtualna Javy jest dla PC-tów darmowa, to za wersję na embedded trzeba płacić grube pieniądze. Doświadczenia zaprzyjaźnionych firm pokazują, że ta implementacja JVM jest koszmarnie wolna. Istnieją sprzętowe implementacje (tak! sprzętowe) maszyny wirtualnej, ale niewiele o nich wiem.

Niedoskonałość sprzętu
W porównaniu do procesorów z kategorii ix86, procesory dla systemów wbudowanych są dość proste (tylko w porównaniu :)). Pisząc usługę EJB nie zastanawiamy się, czy aby procesor działa poprawnie, czy nie będzie błędu w działaniu urządzenia. W aplikacjach embedded niedoskonałość sprzętu jest częstym kłopotem.

Trudności w poszukiwaniu błędów
Tak powszechne zadanie jak poszukiwanie błędów również może nastręczać trudności, gdyż odbywa się to poprzez debugowanie oraz analizę kodu asemblera. Taka analiza jest zdecydowanie łatwiejsza dla kodu napisanego w C niż w C++.

Koronny argument - wydajność
Hmmm, trochę prawda, trochę mit. Tak myślę. Przeanalizujmy.

Po pierwsze:
Jak wspomniałem JVM jest rzeczywiście wolna. Z drugiej strony istnieje przekonanie, że kod napisany w C++ będzie działa duuuuużo wolniej. Tylko czy ktoś to rzeczywiście zmierzył? Czy ktoś napisał dwie tożsame implementacje, jedną w C, drugą w C++ i stwierdził to jednoznacznie?

Po drugie:
Przyczyną mogą być ograniczenia programowe i sprzętowe. Sporo zależy od tego jak jest napisany sam kompilator, czy potrafi wykorzystywać automagiczne sztuczki optymalizacyjne. Innym i często skutecznym sposobem zwiększania wydajności jest zmiana sprzętu. Ten jednak przenika do branży dosyć wolno. Powód jest trywialny - koszty. Nowy sprzęt - większe pieniądze, kolejny kompilator, kolejne bugi itd.

Po trzecie:
W rozwiązaniach embedded rzadko kiedy brakuje np. 5%, 10%, 20% wydajności. Jeśli już trzeba zwiększyć wydajność, bo powiedzmy, nie nadążamy z pomiarem temperatury pieca i grozi wybuchem, to trzeba ją zwiększyć kilkukrotnie. W takim przypadku obniżenie wydajności o parę, paręnaście procent, w związku z konstrukcjami obiektowymi, jest do przyjęcia. Jeśli efektem tego narzutu będzie łatwość utrzymania i rozbudowywania dylemat jest wart uwagi. Tak doszliśmy to wysłużonego już hasła: czytelność ponad wydajność. Nie oznacza to bynajmniej nonszalancji w szafowaniu pamięcią, lecz to aby w pierwszej kolejności koncentrować się na tworzeniu czytelnego kodu, a dopiero w drugiej mierzyć, profajlować i optymalizować.

Co dalej?
Jakie wyzwania stoją przed technikami refaktoryzacji i wzorcami, które w swoim najbardziej światowym wydaniu, utknęły gdzieś pomiędzy Javą a C#?

Jak pracować z hybrydowym legacy code, pisanym trochę w C trochę w C++?

Jak bezpiecznie przepisywać kod proceduralny na obiektowy?

Jakie standardy kodowania przyjąć dla C++, aby uniknąć pułapek wynikających z bogactwa języka

Jak sensownie rozwinąć narzędzia wspierające refaktoryzację. Sorki, ale VC++ i wsparcie dla refaktoryzacji to porażka. Visual Assist X jest super, ale to jeszcze nie to. Eclipse C/C++ nie próbowałem, Wind River Workbench jest ponoć dobry, ale i kosztuje słono

i cała reszta bajerów, których się w okół Javy i C# dorobiliśmy

Za różnymi problemami oraz przekonaniami kryją się ludzie, którzy poszukują skutecznych rozwiązań swoich problemów. Na pewno coś da się zrobić.

Value Stream i zarządzanie wymaganiami w korporacji

2011-06-09T21:57:00.006+02:00

Małe firmy często opracowują własne efektywne procesy. Programiści i analitycy z jednej z zaprzyjaźnionych firm sami wymyślili Scruma. Serio! Wpadli na dosłownie wszystkie scrumowe praktyki i przestrzegali ich z pedantyczną dokładnością. Co ciekawe, wcale nie uważali, że zrobili coś nadzwyczajnego. Ot, zwykłe zdroworozsądkowe podejście. Kompletnie inaczej jest w korporacjach.

Podczas warsztatów z zarządzania wymaganiami największy challenge mam z pracownikami departamentów IT w korporacjach. Złożoność organizacyjna rodzi kilka dodatkowych problemów.

Hipertraceability
Pisałem na ten temat tutaj. Nie dajmy się zwieść, że pragnienie hipertraceability jest potrzebą organizacji. Nie jest to potrzeba lecz rozwiązanie problemu związanego z bałaganem w wymaganiach. Rozwiązanie to daje złudzenie, że wszystko jest pod kontrolą. Zazwyczaj nie jest.

Wstrzymałbym się chwilowo ze skłanianiem się ku temu rozwiązaniu dopóki dokładnie nie zrozumiemy natury problemu. (tak tak wiem, focus on solutions, not on problems; ale czy można zaproponować rozwiązania nie rozumiejąc problemu? - moim zdaniem nie).

Niech nieco światła na problem zarządzania wymaganiami w korporacjach rzuci parę poniższych akapitów.

Time to market
To, że prace programistyczne rozpoczynają się rok po zebraniu wymagań, to norma. Niestety przez ten czas, konkurencja poszła do przodu, priorytety się zmieniły i zebrane wymagania są (delikatnie mówiąc) średnio przystające do rzeczywistość. Szkoda jednak tracić zabukowane mendejsy, więc parce wrą. Co prawda dzieje się co innego niż pierwotnie planowano, ale dzieje się!

Harmonogram wdrożeń i rezerwacja mendejsów
W organizacji systemów jest od groma i jakość trzeba nad nimi zapanować. Więc w trosce o jak najlepszą organizację prac definiuje się harmonogram wdrożeń. Harmonogram jak harmonogram musi być rygorystycznie przestrzegany, więc jeśli projekt nie wstrzeli się w swój termin, to czeka na następny termin (zatem ewentualna obsuwa nie jest ciągła lecz dość grubo skwantyfikowana).

Ponieważ projekty konkurują ze sobą o miejsce w harmonogramie wdrożeń, a Biznes ma wskaźniki do osiągnięcia, więc przezornie rezerwuje sobie miejsce dwa lata w przód na Jakiś Bardzo Ważny Projekt. Dla uzasadnienia rezerwacji, odbywa się nawet zbieranie wymagań. Jest to jednak sprytny wybieg taktyczny mający na celu zaalokowanie zasobów Departamentu IT "na wszelki wypadek".

Pigułka: Nowy System
Nowe potrzeby = nowy system. Rzesza programistów podejmuje trud stworzenia czegoś nowego, co powiela część funkcjonalności z już istniejących systemów. Jasne, że ktoś powinien pójść po rozum do głowy i wyłożyć co jest grane. Ale kto?: Główny Architekt, Enterprise Architect, Architekt Funkcjonalny, Architekt Systemowy, System Designer, Backend System Designer ???

Mimo szczegółowej procedury decyzyjnej oraz masy zebrań, komitetów, analiz i opinii, powstaje pięćset szósty system, który sprawia, że:

potrzeba kolejnego etatu do jego utrzymania,

SOA staje się naprawdę jedynym sensownym rozwiązaniem,

skomplikowanie procedur organizacyjnych dąży do nieskończoności,

końcowi użytkownicy ze starymi przyzwyczajeniami próbują korzystać ze starego systemu na nowy sposób i klną na czym świat stoi.

Paraliż decyzyjny
Wyobraźmy sobie następującą, powiedzmy, że hipotetyczną, sytuację:

Komitet sterujący projektu IT składa się z: Prezesa oraz członków Zarządu

Komitet spotyka się z Kierownikiem Projektu, aby podjąć decyzję o zmianie harmonogramu tworzenia projektu

Rozmowa przebiega następująco:

Kierownik: Czy zmieniamy harmonogram?

Prezes: Zmieniamy?

Członkowie Zarządu: hmm...

Prezes: Tak! Zmieniamy!

Kierownik: A zatem wpisuję w protokole: "Komitet sterujący podjął decyzję o zmianie harmonogramu"

Prezes: Zaraz, zaraz...Jaką decyzję? Proszę napisać: "Komitet sterujący rekomenduje zmianę harmonogramu". Niech zostanie to zatwierdzone na zebraniu Zarządu.

yyyyy????

Obosieczny miecz standardów
Buy, don't write Wiele kawałków systemu, można kupić taniej niż wykonać. Wiele kawałków do wykonania, można szybko napisać w konkretnych technologiach, bibliotekach, itp. Ale stop! W organizacji standardem jest technologia X i kropka. Z jednej strony ma to sens (na przykład finansowy), z drugiej jest pewnym marnotrawstwem zasobów.

Zmęczony Biznes znajduje drogę na skróty
Ponieważ biznes napotyka powyższe trudności w dogadaniu się z Departamentem IT, radzi sobie w sprytny sposób - zatrudnia jednego lub dwóch programistów we własnym dziale, na własny koszt.

W pewnej firmie jeden z takich "partyzanckich" programistów, w krótkiego czasu naskrobał w pehapie CRM, który zrobił sporą furorę w organizacji. Dostarczał dokładnie takich funkcjonalności jakich było potrzeba. Jak powiedział jeden z programistów z Departamentu IT: ktoś tam siedział, słuchał biznesu i zrobił. Oczywiście CRM był na bakier z: harmonoramem wdrożeń, bezpieczeństwem testami i stosem innych procedur, aczkolwiek miał podstawową zaletę: adresował wszystkie potrzeby Biznesu.

Problem z takim "kukułczym jajem" jest taki, że Departament IT nie chce go tknąć, bo: "nie mamy kontroli nad opensource'owymi bebechami i jak coś się stanie to będzie na nas". Dodatkowo między Biznesem a IT rośnie napięcie ponieważ estymacje Departamentu IT są kilkukrotnie większe niż programisty-partyzanta.

Value Stream
Ktoś kiedyś napisał bądź powiedział: "Informatyzacja efektywnego procesu zwielokrotnia jego efektywność. Optymalizacja procesu nieefektywnego zwielokrotnia jego nieefektywność".

W powyższych przykładach organizacja sterowana jest procedurami, brak jest zorientowania na wartość biznesową. Jasne, że są plany, wskaźniki itd. Ale czy opisane sytuacje nie wskazują, że wartość biznesowa zniknęła gdzieś między procedurami? Brakowało zdefiniowania strumienia wartości biznesowej, czyli zoptymalizowanego procesu zarabiania pieniędzy.

Tajemniczy Dział Optymalizacji Procesów
Organizacje mają świadomość opisanych sytuacji. Jednym ze sposobów jest powoływanie do życia Tajemniczego Działu Optymalizacji Procesów (ew. zatrudniania do tego kosztownych konsultantów). Dział ów to kilka osób, zamkniętych w malutkim pokoiku, które co jakiś czas
objawiają Organizacji nowe i ulepszone procedury. Nie tędy droga, ponieważ procedury procedurami, a ludzie ludźmi. Formalizowanie i standaryzowanie jest ok i przynosi wiele korzyści, ale zaangażowanie i orientacja na wartość biznesową przynosi ich więcej. Trudno mi w tej chwili podać konkretny przepis na to co z tym fantem zrobić. Temat w inkubacji.

Jako zajawkę w pokrewnej tematyce polecam prezentację. (nie wiem ile powisi, więc kiedyś link może się zdezaktualizować)

Jak wykorzystać swoje doświadczenie i jeszcze wiele się nauczyć?

2011-06-07T19:30:00.002+02:00

Jako że nasza działalność (BNS IT http://www.bnsit.pl) nabiera coraz większego rozmachu, pojawia się miejsce dla osób, które są chętne, aby pracować z innymi w celu dzielenia się wiedzą i doświadczeniem oraz chcą wspierać zespoły w zwiększaniu efektywności pracy.
Zatem jeśli masz doświadczenie praktyczne w pracy na projektami programistycznymi, jesteś kompetentny w PRZYNAJMNIEJ W JEDNYM z następujących obszarów:
- wzorce projektowe
- dobre praktyki pracy z kodem (refaktoryzacja, czysty kod, obiektowość (SOLID, GRASP, interfejsy))
- test-driven development
- domain-driven design
- scrum (agile)
- komunikacja w zespole (w kontekście projektów programistycznych),
- zarządzanie czasem dla programistów,
- zarządzanie projektami,
- zarządzanie wymaganiami, analiza.

Ważna jest wiedza i doświadczenie projektowe, co do warsztatu trenera, jesteśmy w stanie odpowiednio do tego przygotować.

Jesteśmy głównie zainteresowani stałą współpracą. Aczkolwiek ewentualnie opcja współpracy od czasu do czasu też wchodzi w grę.

Pisz śmiało: m [kroppka] bartyzel [mauppa] bnsit [kropkka] pl

Grunt, to prostota

2011-06-03T14:45:00.005+02:00

Dostałem ostatnio grę edukacyjną dot. szybkiego czytania. Tak się podekscytowałem nową zabawką, że aż straciłem nad nią kontrolę. Było to tak:

czwartek: Dostałem zestaw płytek. Zaraz po szkoleniu pobiegłem do hotelu i pierwsze co zrobiłem, to szybko rozpakowałem CD1 i chcę uruchamiać.
Nie idzie. Zorientowałem się, że zmieniłem notebooka na mniejszego i nie mam CD.

piątek 16.30: Ciągle myślę o nowej grze. Znam już na pamięć instrukcje i teksty z okładki. Już bym pograł, a tu jeszcze parę godzin podróży z Wrocławia. Wykombinowałem, że wezmę laptopa żony, zgram zawartość płytki, przekopiuję na swojego nooteboka i już. Zaraz potem pomyślałem, że pewnie taka gra zajmuje sporo miejsca i potrzebuje płytki do rozruchu. Wpadłem więc na pomysł, że na drugim laptopie zrobię obrazy, które potem przegram i podmontuję u siebie. Genialne!

piątek 22.00: Znalazłem darmowy program do emulowania napędu DVD. Odpalam Nero...hmm moja wersja robi tylko obrazy *nrg. Obrazów ISO nie robi. Ściągam inny program, który robi już obrazy ISO.
Już miałem kliknąć, ale program informuje mnie, że ma własny bardziej skompresowany. format zapisu obrazów i że ISO jest do bani. Googluję. Ok, więc dla testu przygotowałem dwa różne obrazy: ISO i ten drugi: różnica w rozmiarze = 2MB. Zdecydowałem się jednak na ISO.

piątek 23.50: Obrazy gotowe idę spać.

sobota 13.00: Obrazy mają ponad 4GB. Na mojego pendrive nie wejdą. Szlag! Spróbuję udostępnić pliki poprzez sieć.

sobota 13.45: Dwa Win7 za nic w świecie nie chcą się zobaczyć przez sieć. Powyłączałem wszystkie antywirusy, zapory, filtry i takie tam. Nic. Wygooglałem, że z moim routerm WiFi jest coś nie tak i nici z udostępniania. No trudno. Wystawię przez FTP.

sobota 14.15: Też lipa. Nagle mnie olśniło. Mam dysk zewnętrzny! Przekopiuję na dysk a potem do siebie.

sobota 14:17: No tak. Kiedyś chciałem się łączyć z tym dyskiem przez WiFi i producent zmusił mnie do sformatowania go jako FAT32. Przygotowane ponad czterogigowe obrazy tam nie wejdą. (Zaczynam żałować, że zająłem się informatyką. Gdybym znał tylko ofisa oraz guziki power i reset, to bym komuś za to zapłacił i miałbym z głowy, no trudno).
Podjąłem męską decyzję: przekonwertuję dysk na NTFS i po kłopocie. Google mówi, że polecenie winda ma wbudowane polecenie convert i po kłopocie.

sobota 16.00: Polecenie convert zgłasza błędne sektory dysku, co uniemożliwia konwersję. W eleganckim komunikacie zapewnia mnie, że po wykonaniu polecenia chkdsk będzie ok.

No więc wykonuję polecenie chkdsk, które raportuje błędy i pyta czy naprawić? No, pytanie! Naprawiam. Znów odpalam convert. I znów lipa. Nie można przekonwertować z powodu błędów. Partition Magic napewno sobie poradzi! (żona zaczyna domagać się zwrotu laptopa, jeszczę chwilunia)

sobota 16.30: Sciągam Partition Magic. Odpalam, wybieram partycję, konwertuj na NTFS, ok.....Partition Magic odpala program convert! Efekt do przewidzenia. Grrr!!!!!

sobota 17.00: Po chwili poszukiwania ściągam Norton Disk Doctor. Teraz już będzie ok! Zaznaczam autofix Disk Doctor leniwie rozpoczyna naprawę niemal terabajtowego dysku. Dla uspokojenia tematu poszliśmy z żoną na zakupy.

sobota 21.13: Wciaż naprawia...

sobota 23.40: Dalej naprawia...

niedziela 9.07: Naprawił. Odpalam convert. AAAaaaaaaaaaa!!! Wciąż to samo. Googluję, googluję, googluję. Mam! mój dysk ma ustawiony dirty bit i stąd te kłopoty. Znalazłem jakieś polecenie windozy, które sprawdza ten dirty bit. Odpalam - brak praw do wykonania operacji.

Olśniło mnie, wszystie poprzednie sztuczki nie działały bo programy nie wprowadzały zmian na dysku z powodu braku uprawnień. Tylko dlaczego o tym nie informowały? Tajemnica.

niedziela 11:30: Odpaliłem konsolę na prawach administratora i chkdsk a potem convert. Robi się.

niedziela 12.00: Taaak! Przekonwertowane. Przegrywam obrazy, montuję, instaluję, działa. Na wszelki wypadek sprawdzam rozmiar danych na płytce: 154 MB....!@#*&Y#*! Dlaczego nie robiłem tego na początku?

Wnioski

Chwila refleksji nad moją przygodą, która do złudzenia przypomina mi sytuację, których doświadczam podczas prac programistycznych.

Błąd 1: Brak planu
Nie przygotowałem się do akcji. Nie określiłem jakie działania podejmę - robiłem wszystko jak leci. Nie ustaliłem czasu, który mogę przeznaczyć na to zadanie. Wszystko, co robiłem było totalnie nieuporządkowane.

Błąd 2: Zosia Samosia
Plusem i minusem jednocześnie programistów jest kompetencja. Cokolwiek jest związane z IT potrafimy się w tym odnaleźć. Napisać program - ok!, Postawić sieć - no problem!, poskładać komputer - pewnie! Ponieważ, czujemy się kompetentni w niemal całej branży i mamy feeling jak się zabrać do większośći tych rzeczy, to niechętnie prosimy o pomoc. Ignorujemy zasadę buy, don't write.

Błąd 3: Brak feedbacku
Podejmowałem coraz to nowe działania, mające dość znaczny wpływ na stan mojego przedsięwzięcia, bez rozważania neatywnych konwekwencji. Działałem na chybił-trafił.

Błąd 4: Ignorowanie intuicji
Pierwsza myśl była dobra. Mogłem przynajmniej sprawdzić, czy to zadziała.

KARDYNALNY Błąd 5: Brak koncentracji na wartości biznesowej
Koncentrowałem się na rozwiązywaniu lokalnych problemów technicznych. Już na samym początku zapomniałem o gównym celu tego przedsięwzięcia, czyli: zagraniu w grę edukacyjną. Żadne z moich działań nie dodawała wartości biznesowej. To był marsz ku klęsce.

Gadżety Javy

2011-04-20T21:33:00.007+02:00

Jeszcze parę lat temu mówiło się, że Spring i EJB wcale ze sobą nie konkurują. Każde z nich miało swoje obszary zastosowań, w których się sprawdzało, a drugiemu nie wchodziło w paradę. Wyhodowany na bolączkach EJB2 Spring Framework, rozwijany przez genialnych programistów z Interface21, świadomie pozbawiony był nadmiarowych bajerów EJB, przez co wypełnił tą niszę, w której potrzeba było minimalistycznego kontenera.

Z biegiem czasu dochodziły coraz to nowe dodatki: kolejne moduły, kolejne podprojekty, własny serwer aplikacji, SpringSource ToolSuite. Czy wciąż Spring i EJB mają swoje obszary stosowalności? Czy może stały się nawzajem dla siebie alternatywami? Porównajmy:

SpringFramework	EJB3.*
bierzesz, co chcesz; w razie potrzeb dokładasz kolejne moduły	bierzesz wszystko albo nic; klejony na siłę koncept profili moim zdaniem tak bezsensowny, że nawet nie warto się rozpisywać
częste wydania	w bólach i na drodze kompromisów rodząca się specyfikacja jest sporo w tyle za nowinkami ze świata OpenSource
nastawiony na bezinwazyjne sklejanie fragmentów aplikacji oraz na integrowanie się z bibliotekami i frameworkami, które już istnieją i dobrze się sprawdzają	mityczna przenośność aplikacji pomiędzy serwerami
staje się coraz cięższy; może nie sam kontener ale włączając kolejne ficzery robi się coraz ciężej	zmierz w stronę odchudzania (JPA poza kontenerem, koncept profili)
Projekt OpenTerracotta spierający skalowanie aplikacji opartych o Springa	kontener EJB dostarcza możliwości skalowania aplikacji
można tworzyć aplikacje wielowątkowe	zakaz własnoręcznego korzystania z wątków; wątkami zarządza wyłącznie kontener
brak standardu dot. zarządzania aplikacją; istnieją projekty SpringSource dedykowane do tego celu	spójny sposób zarządzania aplikacją

Okazuje się, że Spring wsparty bibliotekami zewnętrznymi potrafi zapewnić dokładnie te same funkcjonalności, że EJB. Być może jeszcze jedną różnicą jest to, że w przypadku Spring trzeba dokładnie wiedzieć jaki efekt chce się uzyskać, gdyż oferuje on bogactwo różnych opcji na rozwiązanie tego samego problemu i trzeba wiedzieć, która jest najodpowiedniejsza dla naszego projektu. W przypadku EJB, mamy wszystko out of the box.

Kontynuując tyradę narzekania
Kontynuując tę tyradę narzekanie trzeba wspomnieć jeszcze wiele genialnych frejmłorków i bibliotek, które świetnie wyglądają w 10 minutes tutorial, rozwiązują parę problemów i wprowadzają szereg nowych.
Wymieniam parę wad:

JSF	ciężkie drzewo komponentów, pokręcony mechanizm renderowania; wersja 1.2 - toporna i wymagająca paru dodatków, aby sensownie pracować; wersja 2.0 - niby fajnie ale poużywamy-zobaczymy; RichFaces 4.0 wspierajace JSF 2.0 już jest
JPA	wolno rozwijająca się specyfikacja, plus wszystkie wady O/RMów
GWT	dostawca monopolista, ciężki klient, brak standardu, po stronie widoku obsługiwana jest tylko część maszyny wirtualnej
Struts2	"prawie" wsparcie dla Ajaxa, koszmarne adnotacji
Spring WebFlow	fajny, gdy GUI ma charakter procesowo-kreatorowy, poza tym przerost formy nad treścią
Oracle ADF	w tutorialach genialny, w użyciu prowadzi do prawie takiego samego bałaganu w kodzie jak przy bezmyślnym klikaniu w Borland Delphi Buildera

Co zamiast w/w?
Jakie mamy zatem mamy alternatywy? Co można używać zamiast powyższych rozwiązań. Spotkałem się z następującymi konfiguracjami:

Stripes + dojo + Hibernate - wychodzimy z założenia, że nie ma co liczyć na automagiczne ajaxy i jeśli chce się mieć fajne GUI to trzeba w JavaScript popracować
Freemarker + SpringMVC + myBatis - całkowita rezygnacja z JSP oraz pogodzenie się z faktem, że schemat bazy jest czasem tak prosty, że nie ma co przekombinowywać
Oracle Forms, PowerBuilder - w architekturze dwuwarstwowej
PHP - tak po prostu... to o wiele bardziej dojrzała technologia, niż jawowcom może się wydawać, mają nawet swoje automagiczne frejmłorki

Do czego właściwie nadaje się się JEE
Nie chcę za bardzo wyrokować, ale JEE rozważałbym wtedy, gdy...nie ma innego wyjścia, gdy z powodów historycznych (zastany stan systemu), ludzkich (umiejętności programistów) albo politycznych trzeba się decydować na tą konkretną technologię. Bardzo, ale to bardzo byłbym ostrożny, przy rozważaniu JEE dla aplikacji webowej. Dzisiaj jestem zdania, że do aplikacji strice webowych (i nic ponad to) JEE się nie nadaje: zbyt wolne, zbyt kosztowne (chociażby ze względu na wynagrodzenia programistów).

Do czego się nadaje. Oprócz wymienionych na wstępie powodów można jeszcze dorzuć szeroko rozumiany backend przy tworzeniu dużych i długotrwałych projektów o bogatym modelu - wtedy można doszukiwać się korzyści w inwestowaniu w JEE.

P.S. Wpis wyraża prywatne myśli autora, a autor nie zarzeka się, że myśli tych kiedyś nie zmieni:)

Po 33rd Degree

2011-04-08T22:14:00.004+02:00

Przede wszystkim wielkie ukłony dla Grześka. Konferencja tej skali to z pewnością nie lada wyczyn. Dziękuję.

Kilka słów, na temat prezentacji, które szczególnie utkwiły mi w pamięci.

Don't code - create software!. Zapamiętałem ze względu na świetny sposób prowadzenia. Bardzo energicznie i przyjemnie.

Fractal TDD: Using tests to drive system design. Ech...naprawdę fajne koncepcje, naprawdę ciekawego człowieka, podane w nieco zagmatwany sposób (dopiero na drugi dzień doszedłem do tego o, co chodzi z tym "Fractal"). Po prezentacji, gdy kilku uczestników rozmawiało z p. Freemanem, widać było wyraźnie, że prowadzący zdecydowanie lepiej odnajduje się w małych grupach. Mimo tych niedogodności podobało mi się.

Git Going with a Distributed Version Control System ,
Monitoring 10 Critical Code Quality Metrics with Sonar. Merytorycznie raczej tutoriale do narzędzi, ale sposób prezentacji absolutnie rewelacyjny. Moim zdaniem najlepszy prelegent Konferencji.

Architecture and programming model for NOSQL web. Prezentację zapamiętałem, ze względu na to, że nic nie zapamiętałem:) Prowadzący założył pewną wiedzę u uczestników, ja jej nie miałem i się nie odnalazłem. Sąsiedzi twierdzili, że była ciekawa więc wierzę im na słowo. Przyszedł mi do głowy pewien pomysł. Być może na konferencjach powinno rozróżniać się prezentacje ogólne/przeglądowe od szczegółowych, na których zakłada się jakąś określoną wiedzę od uczestników. Prezentacja o NOSQL była raczej szczegółowa i jeśli ktoś przyszedł z konkretnym problemem, to pewnie znalazł rozwiązanie. Ja chciałem się zorientować o co chodzi i niestety nie skorzystałem.

BOF: Dokąd zmierza Software Craftsmanship W zamierzeniu miała być dyskusja o profesjonalizmie w IT. Skończyło się na zabawie, że jeden uczestnik wymyślał metaforę: programista jest jak: [szewc | budowniczy | architekt | lekarz], a cała sala ripostowała przypadkami szczególnymi, dla których metafora kuleje. Było dużo śmiechu, ale moje rozumienie profesjonalizmu raczej się nie poszerzyło. Miałem wrażenie, że wylewaliśmy swoje żale, mówiliśmy o własnych nieprzyjemnych doświadczeniach, które następnie uogólnialiśmy do nowotworu trawiącego całą branżę. Pomysł na dyskusję na pewno cenny, temat warto eksplorować.

Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw. Obawiałem się konferencyjnej przeglądówki, ale było ok. Jasno konkretnie i po kolei wyłożone o co chodzi w temacie. Prezentacja a'la Matrix dodała kolorytu.

Lost Chapters of Divine Code: 7 Deadly Sins. Pierwsze wrażenie bardzo pozytywne. Świetny kontakt z publicznością, ważne rzeczy przedstawione w ciekawy i kreatywny sposób. Gdy wracałem do domu i myślałem o tej prezentacji, pojawiały mi się mieszane uczucia.

Pierwsza rzecz, to odniosłem wrażenie (z powodu komentarzy kierowanych w stronę słuchaczy), że prowadzący zaczęli prezentację z założeniem, że mają przed sobą bandę troglodytów, którzy do programowania używają dłuta i maczugi, a których oni właśnie oświecają. O czym mówili? O ile dobrze zapamiętałem to: nie używać metod prywatnych, nie używać konstrukcji statycznych, nie używać metod i klas final, preferować kompozycję ponad dziedziczenie. Nie są to więc sprawy, które nagle spłynęły z nieba, lecz tematy przewijające się w branży od czasów GoF i raczej większość programistów ma swoje zdanie na te tematy.

Z wieloma argumentami prowadzących można się zgodzić, ale podawane bez kontekstu tracą swoje znaczenia, a dogmatyczne przestrzeganie tych zaleceń zawsze i wszędzie doprowadzi bajzlu w kodzie równie szybko, co ich ignorowanie. Będzie to bajzel innej jakości, ale zawsze bajzel. Sądzę, że porady prowadzących były ciekawe, ale jak wszystko mają zakres swojej stosowalności. Myślę, że tworzenie boskiego kodu, to coś więcej niż mechaniczne przestrzeganie niskopoziomowych wytycznych.

Moje całościowe wrażenie odnośnie przesłania tej prezentacji jest bardzo pozytywne, potrzebujemy tego rodzaju ewangelistów. Jedna rzecz mnie zniesmaczyła. Prowadzący kolejno wyśmiewali: K.Becka, E.Gamma, S.Freemana, R.Martina i kogoś jeszcze, za to jakie błędy popełnili i co powiedzieli w przeszłości. Przypomniało mi to wiersz Asnyka Do młodych, którym napisał ale nie depczcie przeszłości ołtarzy, choć macie sami doskonalsze wznieść. Myślę, że gdyby nie ci wszyscy "giganci" inżynierii oprogramowania, Autorzy prezentacji z pewnością nie robiliby tego, co teraz robią, nie prezentowaliby siebie na konferencji, a i konferencji z pewnością by nie było. Autorzy prawdopodobnie rzeźbiliby paznokciami w rzadkim...kodzie i nie przychodziłoby im do głowy, że można inaczej. Myślę, że choć Autorom nie brakuje świetnych pomysłów, to jednocześnie przydałoby im się nieco pokory i szacunku do Becka, Gamma, Freemana, Martina i innych, gdyż między innymi dzięki ich błędom (i sukcesom, oczywiście), Autorzy są tam, gdzie są i robią to, co robią.

Podsumowując - niecierpliwie czekam na kolejną edycję Konferencji.

Tyle ode mnie.

"żeby tak wszystko ze wszystkiego wynikało"

2011-04-06T00:15:00.006+02:00

Problem dotyczy zarządzania zmianami w wymaganiach. Cytując rozmowę, oczekiwanie brzmi następująco Proszę Pana, chciałbym tu mieć takie narzędzie do zarządzania wymaganiami, w którym będę mógł sobie je definiować, żeby tak wszystko ze wszystkiego wynikało. Na przykład jak przyjdzie jakaś zmiana, to żebym od razu wiedział gdzie, co i jak, w której klasie należy zmienić. Rozumie Pan?

No, niby rozumiem...

Zarządzanie? Dobre sobie!
Weź pierwszą z brzegu mądrą książkę, która ma w tytule Requirements Management. 99% tekstu jest o (w kolejności ilości stron): dokumentowaniu, zbieraniu (ale raczej skąd? niż jak?) i analizie wymagań. I gdzieś tam pod koniec parę akapitów o tym, że change happens. A kluczową atrakcję wieczoru, czyli management zbywa się truizmem w stylu trzeba wdrożyć proces zarządzania zmianą.

Czyli co to jest to zarządzanie? Sądzę, że:

składowanie wymagań

dowiadywanie się jak nowe wymagania wpływają na istniejące

wykrywanie konfliktów w wymaganiach

dowiadywanie się jak zmiany (w skrócie: CR) wpływają na istniejące wymagania

Hipertraceability
Czy oczekiwanie wyrażone w początkowej historyjce ma sens. Jest w nim ukryta jakaś potrzeba, ale zastanawiam się czy ma sens. Można zaprzęgnąć EA albo coś droższego i wyklikać wszystkie możliwe powiązania tak, "żeby tak wszystko ze wszystkiego wynikało". A co w przypadku zmiany? Oprócz dowiedzenia się co z czym się wiąże, znów trzeba będzie poklikać. Sądzę, że utrzymywanie takiej macierzy powiązań to robota na kilka pełnych etatów. Wątpię, czy warta świeczki. Wątpię, czy jest nawet warta ogarka.

Gdzie leży problem z traceablility?
Duży system jest zazwyczaj podzielony na moduły, które są rozwijane przez osobne podzespoły, którym przewodzą dedykowani liderzy. Gdy przychodzi zmiana dotycząca jednego z modułów, może ona jakiś wpływ na inne. Jeśli dane lider na to wpadnie to świetnie. Jeśli nie, to sprawa wypłynie prędzej czy później.

Niszczące działanie zmiany nie jest wynikiem braku hiepertraceability, braku jedynie poprawnego narzędzia czy wynikiem braku kompetencji. To przede wszystkim problem organizacyjny i komunikacyjny. Liderzy nie wiedzą co się dzieje w inny modułach, analizują zmianę lokalnie bez odniesienia do całości (której nie znają) i nie komunikują się ze sobą wystarczająco.

Product Manager
Brakuje osoby (Product Manager), która będzie spinać system całość. Od razu pada pytania: czy od strony technicznej, czy biznesowej? Nie chodzi to, żeby przez Product Managera przechodziły wszystkie CR, a on będzie podejmował je analizował i podejmował decyzje. Nie może tak być, bo zaraz zrobi się z niego ktoś w stylu Solution Architect, w którym będzie powoli skupiała się kluczowa wiedza o systemie i który będzie wąskim gardłem procesu zarządzania zmianą. (a niech tam, to zatrudnimy mu asystentów i już, czemu nie? :) )

Product Manager jest raczej kimś kto dba o to by komunikacja pomiędzy liderami i zespołami przebiegała płynnie. Oczywiście będą trafiać do niego wszystkie CR, będzie posiadał dużą wiedzę biznesową i będzie doskonale znał produkt. Jego główny zadaniem będzie troszczenie się o produkt jako całość i pomaganie poszczególnym zespołom w komunikowaniu się z innymi i dogrywaniu wszelkich zmian.

Zauważmy, że nie jakaś konkretna osoba analizuje wymagania, wykrywa konflikty i wpływ nowych na istniejące. Rzeczy te wykrywane są w procesie komunikacji pomiędzy poszczególnymi zespołami i liderami.

Czy Product Manager będzie miał co robić? Jeżeli mówimy o produkcie, który ma wdrożenia dla poszczególnych klientów, to z pewnością tak. Odpowiedzialności Product Manager to:

dbanie o rozwój produktu jako całości

dbanie o loose coupling między produktem a wdrożeniami dla poszczególnych klientów :)

przyjmowanie CR

pomaganie liderom i zespołom w komunikowaniu się między sobą

uzgadnianie i mediowanie w przypadku wprowadzania zmian w produkcie

Strażnik architektury i ewangelista

2011-04-05T00:14:00.007+02:00

Zauważyłem pewną cechę różnicującą projekty, w których kod woła o pomstę do nieba, od tych, które są bardzo przyzwoicie napisane. Różnicą, którą mam na myśli nie jest bynajmniej skala projektu, skomplikowanie domeny, język programowania, czy nawet wiek projektu. Zauważyłem, że w zespołach, w których kod jest dobrze utrzymany objawia się osoba, która nakręca cały ten pęd ku ciągłemu doskonaleniu. Nazwałem go Strażnikiem architektury.

Nie posługuję się nomenklaturą Scotta Amblera, który mówi o Właścicielu architektury, gdyż sądzę, że chodzi o nieco inną rolę. Mimo koncepcji Właściciela architektury, jako roli, a nie stanowiska (zapewne z inspiracji Product Ownerem) trudno uciec od skojarzeń, że właściciel coś posiada. Tego typu rola, bardzo szybko przekształca się w klasyczne stanowisko architekta, który jest wyrocznią w sprawie architektury, od czego Scott Ambler chciał uciec.

Strażnik architektury jest jednym z członków zespołu, który ma "parcie" na ciągłe doskonalenie projektu oraz ewangelizuje zespół w zakresie jakości tworzonego kodu. Zaobserwowałem, że zazwyczaj Strażnik architektury jest inicjatorem i koordynatorem następujących aktywności w zespole:

wprowadzanie standardu kodowania

zmiana/wprowadzanie systemu kontroli wersji/zmian

wprowadzenie code review

wprowadzenie procesu continuous integration

wprowadzenie/zmiana podejścia tworzenia kodu np:. DDD

wprowadzenie/zmiana technologii/frameworka

tworzenie warstw abstrakcji na niektóre z używanych bibliotek, w celu uniezależnienia się od nich

zmiana architektury w celu poprawienia wydajności (i nie chodzi tylko do dopisanie paru SQLi i założenie paru indeksów)

Zazwyczaj Strażnik architektury objawia się sam. Po prostu jest ktoś taki w zespole, od kto stopniowo staje się autorytetem dla innych. Uczy ich, prowokuje do wyjścia poza utarte schematy, stymuluje do rozwoju. Zazwyczaj pomaga rozstrzygnąć sporne kwestie dotyczące technicznej strony projektu. Doradza i nieformalnie akceptuje nowe pomysły albo je odrzuca (albo jak mawiają znajomi z pewnego sympatycznego zespołu "spsikuje" pomysły ;) )

Kilka punktów nt. zaobserwowanej charakterystyki Strażnika architektury.

jest pasjonatem

poświęca wolny czas na czytanie blogów, literatury, rozpoznawanie technologii

testuje nowe rozwiązania (często projekcie, w którym uczestniczy)

często staje się liderem z nadania (poprzez stanowisko) i bywa, że to go "zabija" bo tonie w papierkach, budżetach i spotkaniach

mimo szeregowego stanowiska z jego zdaniem management się liczy i potrafi przelobbować praktycznie co tylko chce

szybko wyciąga wnioski z pomyłek, ale się nie zraża

jest motywowany głównie "na cel"

Pojawia się jednak pewne niebezpieczeństwo. Pęd Strażnika architektury do doskonalenia projektu jest niemal niepohamowany. Niepohamowany do tego stopnia, że może łatwo przekroczyć dopuszczalną tolerancję biznesu oraz wytrzymałość zespołu. Istnieje duże prawdopodobieństwo, że za przyczyną niekontrolowanego Strażnika architektury zespół będzie co miesiąc zmieniał frameworki, a co pół roku technologię.

Kontrolowanie Strażnika przez management bardzo szybko zachęci go do poszukania nowej pracy, gdzie będzie mógł realizować swoje pomysły. Rozwiązanie tej kwestii, podpowiedział mi układ personalny pojawiający się nieraz w zespołach. Otóż, w sprawnie funkcjonującym zespole, prócz Strażnika architektury pojawia się jeszcze jego przeciwwaga. Nazwijmy go Weryfikatorem. Charakterystyka Weryfikatora to:

jest równie kompetentny technicznie co Strażnik architektury

bardziej niż nowinki technologicznie ceni sobie bezpieczeństwo

jest skrupulatny, metodyczny i niesamowicie cierpliwy

potrafi długo dyskutować ze Strażnikiem architektury i obalać jego teorie jeśli uzna je za niewystarczająco dobrze uzasadnione

jest motywowany głównie "od problemu"

Strażnik architektury oraz Weryfikator stanowią główną oś zespołu dzięki, dzięki któremu projektu ewoluują w równomiernym tempie. Żaden z nich nie jest nadmiernie, czy sztucznie kontrolowany. Raczej wspólnie wypracowują rozwiązania, czerpiąc jednocześnie wiele satysfakcji z pracy.

Podsumowując: jeśli chcesz mieć dobry zespół i dobrze napisany projekt, to proponuję następujący przepis:

Zatrudnij Strażnika architektury oraz Weryfikatora o wskazanych wyżej cechach - ci muszą być rewelacyjni

Zatrudnij pozostałych członków zespołu - ci powinni być dobrzy

Pozwól im działać

Mnóstwo pytań nasuwa się w związku z tym pomysłem, chociażby: jako to zrobić?, skąd wziąć ludzi?, jak to zrobić najtaniej?. TODO.... :)

Generowanie danych dla widoku

2011-03-19T07:45:00.010+01:00

Spotkałem się niedawno z ciekawym rozwiązaniem dotyczącym sposobu generowania danych dla widoku. Warto je opisać.

O co chodzi?
W większości aplikacji musimy dostarczać do widoku różnego dane by je zaprezentować użytkownikowi. Mogą być to dane, na których użytkownik bieżąco pracuje i które widzi na stronie albo dane służące go produkowania raportów, z którymi użytkownik nie wchodzi w interakcję.

Często wystarcza nam przesyłanie do widoku obiektów detached. Przy złożonych modelach domenowych przesyłanie fragmentów modelu domenowego nie jest wygodne. Chociażby z tego względu, że widok często wymaga danych przekrojowych, pochodzących z różnych miejsc modelu. Radzimy sobie wtedy za pomocą obiektów DTO tworzonych na potrzeby konkretnych widoków (Rysunek 1).

Rysunek 1: Generowanie DTO z modelu domenowego

W zależności od skomplikowania obiektów transferowych, generowanie ich można umieścić albo w samych obiektach domenowych albo scentralizować w usłudze Transfer Object Assembler.

Gdy ilość sposobów prezentowania danych dramatycznie wzrasta (raporty, ekrany), okazuje się, że kod związany z obiektami transferowymi zaśmieca projekt i coraz trudniej go utrzymywać.

Pierwsze rozwiązanie
Pierwszy pomysł to przeniesienie odpowiedzialności generowania obiektów DTO na SQL np. z wykorzystaniem biblioteki myBatis. Pamiętajmy, że chodzi o obiekty tylko do odczytu.

Rysunek 2: ORM dla modelu domentowego myBatis dla DTO

Powoduje to dwa problemy. Po pierwsze: znów w miarę rozrastania warstwy widoku a wraz z nią rożnych sposobów (przekrojów) prezentowania danych, zarządzanie zapytaniami SQL nawet umieszczonymi w plikach XML jest uciążliwe. Po drugie pojawia się dualizm: z jednej strony ORM zarządza modelem domenowym, z drugiej wcinamy się gdzieś z boku SQLem, aby pobrać dane dla widoku.

Mapowanie widoków bazodanowych
Rozwiązanie, z którym się spotkałem, polega na zepchnięciu generowania danych przekrojowych bazę danych i reprezentowania ich w postaci widoków bazodanowych. Obiekt DTO mapujemy jako encje na w zdefiniowane w bazie widoki.
W usłudze, dzięki której pobieramy dane z bazy udostępniamy wyłącznie możliwość odczytu.

Ciekawe jakby można nazwać obiekt taką usługę. DAO, Repository? Jakoś kłóci się z tym, co zwyczajowo rozumiemy przez tego typu usługi. Wydaje mi się, że dobrą (na razie ogólną) nazwą będzie PresentationDataService.

Rysunek 3: ORM mapuje widoki bazodanowe

Urzekająca jest symetryczność tego rozwiązania: to co obiektowe jest po stronie obiektów, to co bazodanowe po stronie bazy danych, a ORM wykorzystany jako pomost pomiędzy tymi dwoma światami.

Tymczasowa niespójność danych
W opisanym rozwiązaniu kluczowym aspektem jest wydajność. Po pierwsze: umieszczamy dane dla prezentacji w widoku zmaterializowanym.
Wydajność można dramatycznie poprawić jeśli zgodzimy się na tymczasową niespójność danych. Na przykład: użytkownik dodaje nowego pracownika i otrzymuje komunikat: "Twoje zmiany pojawią się w systemie w ciągu 10 minut.". Okresowe przeliczanie widoku zmaterializowanego jest zdecydowanie wydajniejszym rozwiązaniem niż robienie tego na każde żądanie użytkownika.
Oczywiście jeśli baza danych nie wspiera widoków zmaterializowanych to używamy tabeli tymczasowej i sami klepiemy kod aktualizujący.

Przeszukiwanie dużych ilości danych
Poniższe rozwiązanie dotyczy sytuacji, gdy mamy w bazie kilka milionów np.: klientów oraz złożone kryteria wyszukiwania. Mówiąc o złożonych kryteriach mam na myśli zmienną liczbę parametrów, po których będziemy wyszukiwać (w zależności od potrzeb wynikających z sytuacji biznesowych). Przy stałej liczbie parametrów można stworzyć odpowiednią ilość zapytań QL. Przy zmiennej liczbie parametrów najwygodniej posługiwać się obiektami Cirteria udostępnianymi przez dany ORM. Znów kluczową sprawą jest wydajność przeszukiwania.

Tabela pośrednia z kryteriami wyszukiwania
Pomysł polega na utworzeniu w bazie danych pomocniczej tabeli (widoku zmaterializowanego), która z jednej strony zawiera iloczyn kartezjański wszystkich atrybutów wyszukiwanego obiektu, a z drugiej namiar na odpowiedni wiersz w tabeli związanej z właściwym obiektem, który spełnia kryteria wyszukiwania.

Rysunek 4: Pomocnicza tabela z kryteriami wyszukiwania

Pytanie otwarte: Czy pośrednia tabela kryteriów i odpowiednie jej poindeksowanie rzeczywiście przyśpieszy wyszukiwanie obiektów?

Po co O/RM?

2011-03-12T12:35:00.005+01:00

Oprócz tego, że JPA, Hibernate, TopLink i stado podobnych są fajne to jaki konkretnie jest z nich pożytek? Ale tak konkretnie: jaki?

Wydaje mi się, że zakres stosowalności O/RM jest dużo węższy niż, po wstępnym zachłyśnięciu się technologią, mogłoby się wydawać. Poniżej zebrałem parę argumentów, za O/RM, które często mi się obijały o uszy plus moje wątpliwości, czy rzeczywiście to są wystarczająco mocne argumenty.

1. Niezależność od konkretnej bazy danych
Ok, ale jak często zmieniasz bazę danych? 2 czy 3 razy w tygodniu? Może, gdy tworzy się soft, którzy będzie miał różne wdrożenia i różnych klientów, w różnych środowiskach, to mooooże to być jakiś argument. Z drugiej strony, gdy tworzymy, takie oprogramowanie, to zazwyczaj mamy bazę, którą rekomendujemy, a klient się na to godzi, bo nie ma innego wyjścia

2. Automagiczne generowanie schematu
Fajne podczas prototypowania, ale soft produkcyjny oparty o automatycznie wygenerowany schemat z encji, które miały tylko @Entity, @Id i @OneToMany, to brzydactwo. Autogenerowanie uczy złego nawyku, że baza danych to pikuś i nie trzeba się nią przejmować.

Otóż, trzeba. Jedyne słuszne spostrzeżenie entuzjastów O/RM jest takie, że baza danych i obiekty to dwie różne bajki. Model obiektowy powinien być tworzony przez ludzi, którzy się na tym znają, a model danych (schemat bazy) przez innych dedykowanych temu specjalistów. Natomiast O/RM jest po to, aby jedno z drugim ożenić.

3. Programista obiektowy powinien zapomnieć o bazie danych
Akurat baza danych da o sobie zapomnieć, dobre sobie! Kto zapomniał jak się pisze w SQL, ręka w górę...

Po pierwsze: ewoluujący w trakcie rozwoju projektu model, często wymaga modyfikacji mapowań, co siłą rzeczy nie pozwala zapomnieć o bazie danych.

Po drugie: mapowania, podobnie jak baza danych wymagają profilowania, np.: nie za dużo joinów w zapytaniach, czy występuje n+1 select problem, jakiego rodzaju zapytania są najczęstsze itd. Takie profilowanie, wymaga jednak analizy generowanych przez O/RM SQLi. I znów baza danych zagląda nam przez ramię.

Po trzecie: w 8/10 projektach, których w ten czy w inny sposób uczestniczyłem programiści wspomagali się procedurami składowymi, trigerami itp,, w poważaniu mając idealistyczny koncept zapominania o bazie danych.

4. Wygoda użytkowania
No nie wiem... O/RM jedne problemy rozwiązuje, ale za to wprowadza szereg innych. Żeby dobrze korzystać ze zmapowanego modelu, trzeba mieć dogłębną świadomość relacji, trzeba wiedzieć jak są obiekty ze sobą powiązane, gdzie jest lazy, a gdzie eager, gdzie jest kaskadowość, a gdzie jej nie ma, kto jest właścicielem relacji itp. Inny jest sposób pracy z modelem z włączony filtrem OpenSessionInView, inny bez niego.

Te ograniczenia są dla mnie sporym usztywnieniem. Staram się zapomnieć o bazie danych, ale muszę jednocześnie zawsze pamiętać o sposobie mapowania do bazy i mapowania pomiędzy obiektami.

5. JPA pozwala używać różnych dostarczycieli presystencji
Owszem pozwala, ale jaka z tego korzyść dodana? Używanie JPA w celu uniezależnienia się o konkretnego frameworka to mit. JPA, jak to standard, rozwija się dość powoli, a programiści chcąc poradzić sobie z bieżącymi problemami, używają rozwiązań (np.: adnotacji) specyficznych dla danego dostarczyciela i wspaniała idea niezależności bierze w łeb.

6. Nie ma bałaganu z DTO dzięki obiektom detached
Trochę racja trochę nie. Bardzo często na widoku potrzebujemy pokazać dane przekrojowe, pochodzące z wielu obiektów domenowych. Fragmenty modelu trzeba spłaszczyć oraz najczęściej przepakować do DTO.

Czy używanie O/RM na zatem sens?
Sądzę, że ma. Widzę tu następujące kryterium w modelu domenowym występują złożone relacje pomiędzy obiektami i chcemy z tych relacji korzystać.

To relacje między obiektami są największą wartością dodaną O/RMów. Egzekwowanie kaskadowości, leniwości może w bogatych i złożonych modelach uprościć programowanie kodu biznesowego. Jeśli zaś mam prościutki (i często anemiczny) model zawierający jedynie @Entity @Id @OneToMany i koncentrujemy się na operacjach CRUD na encjach, to O/RM jest zdecydowanie na wyrost, stanowi niepotrzebną warstwę pośrednią

Jeśli nie O/RM, to co?
Czyste JDBC (a jakże!) plus biblioteki pomocnicze. Rozwiązania takie jak mybatis (dawniej iBatis) albo klasa narzędziowa JdbcTemplate z stajni Springa oraz sensowne przemyślenie architektury z udziałem DAO w bardzo wielu przypadkach naprawdę wystarcza.

PEA(2): Kontekst środowiskowy systemu

2011-03-10T19:07:00.006+01:00

To jest artykuł z serii Proces ewolucji architektury.

9 rano, siadasz z ludźmi, którzy chcą, żeby zaprojektować architekturę systemu. Twoja wiedza domenowa = null.

Zaczynają zasypywać cię gradem szczegółów.

10.30 mózg przestaje absorbować informacje. Czujesz się jak po całym dni w obcym kraju, gdzie musiałeś wytężać 100% uwagi, żeby zrozumieć choć trochę co do ciebie mówią. Naturalna reakcja obronna organizmu jest zabawna - chce ci się spać. O, żeby zdrzemnąć się choć na minutkę... Stop!

Zbuduj sobie ogólne overview na sytuację. Określ kontekst środowiskowy systemu, z kim on współpracuje i jakie informacje wymienia z otoczeniem:

trzymaj się na dość dużym poziomie ogólności; na tym etapie szczegół to twój wróg, uśpi cię szybciej niż myślisz

definiuj: nazwy systemów, odpowiedzialności systemów (jednym zdaniem), nazwy operacji wykonywanych pomiędzy systemami (czego chce jeden od drugiego?), nazwy protokołów (tylko nazwy)

unikaj: formatów przesyłanych danych, sposobów nawiązywania połączeń itp; jeszcze nie jest na to czas

Nie wstydź się bazgrać
Celem tych działań jest zrozumienie z czym masz do czynienia, ani brylowanie znajomością UMLa. Na tym etapie diagram komponentów wcale nie jest bardziej profesjonalny niż prostokąty nabazgrane na kartce. Diagram to tylko umowa co do formatu rysunków, jeśli kredki odpowiadają ci bardziej dlaczego ich nie używać?

Lean Architecture: for Agile Software Development

2011-03-09T21:29:00.005+01:00

Nie, to nie jest recenzja książki, a raczej gorące jej polecenie. Lektura tak mnie zachwyciła, że aż musiałem wpisać to na blogu, co poskutkowało dorzuceniem nowej etykiety, a o ile pamiętam liczba etykiet na moim blogu nie zmieniła się od początku jego powstania. Słowem: WIELKIE wydarzenie.

Nie znajdziesz w tej książce supertajnych wzorców w postaci UML, nie poczytasz o wyższości jednej technologii nad drugą. Jest ona o tym, o czym być powinna: o budowaniu zrozumienia dziedziny, o tworzeniu porządnego softu i o ludziach, którzy są w to wszystko zaangażowani. Wymagająca lektura nie-na-jeden-wieczór, ale warto!

Myjcie swoje kubki!

2011-02-15T21:20:00.004+01:00

Widziałem w kuchni jednej z firm taki napis:

Umyj po sobie kubek. Tobie łatwiej umyć jeden kubek niż nam sto.

Dziękujemy,
Serwis Sprzątajacy

Niniejszym ogłaszam ludzi z Serwisu Sprzątającego mistrzami refaktoryzacji. Przecież o to właśnie tu chodzi.

Łatwiej poradzić sobie z syfiastym kodem, gdy jest go jeszcze mało. Nawet jeśli jest i 200 kubków w zlewie, to dokładanie kolejnego z nadzieją, że może jeszcze dziś się nie rozleci, jest najgorszą rzeczą jaką można zrobić. Tak wiem: a bo czas, a bo pieniądze, a bo biznes, a bo babcia...

Być może biznes nie chce dać kasy na porządny Serwis Sprzątający, ale o swój kubek można z pewnością zadbać bez większego uszczerbku na zdrowiu.

MiernotaFactory

2011-02-15T20:53:00.003+01:00

Przez jakiś czas poszukiwaliśmy praktykanta :) Pomijając marnujących mój czas luzaków, którym zdarzało się nie wiedzieć, czym zajmuje się firma albo nawet na jakie stanowisko aplikują (serio! wysyłają cv do 20 firm, a potem wędrują od rozmowy do rozmowy), większość z nich ma oczekiwania finansowe, których nie powstydziłby się developer z dwuletnim stażem w łódzkiem.

Trafiło mnie na miejscu, bo nie dość, że trzeba delikwenta wszystkiego nauczyć, to jeszcze trzeba go najpierw sporo oduczyć. Nie mówię wcale o supertajnej wiedzy merytorycznej lecz o punktualności, odpowiedzialności i doprowadzaniu spraw do końca. Merytoryka to osobna historia.

Wyprostujcie mnie proszę, ale gdy ja starałem się dostać na praktyki (a było nie dalej jak 8 lat wstecz), to mało komu przychodziło do głowy, że może chcieć wynagrodzenie. Słowo! Szczęśliwców z roku, którzy załapali się na płatne praktyki do P&G czy IBM można było policzyć na palcach jednej ręki.

No nie mogę przeżyć, że ktoś chce poprzychodzić miesiąc albo dwa, nie robi nic co można by jasno przełożyć na zysk firmy, zazwyczaj kosztuje, bo trzeba mu poświęcać czas i chce tyle kasy, co regularny programista.

Ktoś mnie jednak olśnił. Podobno za samo studiowanie kierunku technicznego można dostać stypendium z jakiegoś ministerstwa. No to sprawa jasna...

Boję się tylko jednego, że tego typu rozleniwianie narodu skończy się produkcją defaultowych miernot z wyższym wykształceniem. Miernot bez pasji, pracowitości, wytrwałości, chęci nauki. Miernot ze sprzętowo wbudowaną roszczeniową postawą wobec świata. Gdybym wierzył w państwowe ubezpieczenia społeczne, to bym się zaczął bać.

Pączkowanie kodu

2011-02-12T15:03:00.006+01:00

Znalazłem analogię do Naturalnego porządku refaktoryzacji, o którym pisze Mariusz. Otóż kod pączkuje zupełnie jak drożdże.

Zaczynamy pisać od kawałka kodu, aby zadziałało, potem wyodrębnienie zmiennych, wyodrębnienie metod, przegląd odpowiedzialności, pojawiają się nowe klasy. Naturalny porządek refaktoryacji pozwala projektowy rosnąć i rozwijać się w odpowiednim tempie, z zachowaniem sensownej struktury.

Kłopot pojawia się, gdy próbujmy przyśpieszyć wzrost drożdżowego kodu. Zostawiamy zahardkodowane rozwiązania, na w projekcie pojawiają się brzydkie rozwiązania. Tego typu rzeczy się zdarzają, kłopot w tym, że zostają na zawsze. Wtedy zamiast wypieczonego projektu, dostajemy zakalec albo spaleniznę.

Każda idea ma swój czas inkubacji. Wydaje mi się, że nie ma dróg na skróty.

Kto płaci za dobry kod?

2010-10-12T21:49:00.003+02:00

Oświeciło mnie ostatnio...przynajmniej trochę.
Gdy pracuję z innymi programistami nad tematami związanymi z jakością kodu bardzo często uderza mnie fakt, że pod względem technicznym żadnego z nich nie jestem w stanie nic, ale to nic nowego nauczyć!

Programiści zazwyczaj wiedzą:

jakie są słabe punkty ich kodu

jak powinien wyglądać ich kod

co dokładnie należy zrobić, aby ich kod wyglądał tak jak

Wiedzą to wszystko i...nic się nie dzieje! Nic się nie zmienia. Ciekawe jak to jest możliwe, że mimo tej ogromnej wiedzy, świadomości dobrych rozwiązań, znajomości wzorców projektowych, umiejętności tworzenia czytelnego kodu wciąż jest jak jest - czyli kod woła o pomstę do nieba, a my narzekamy.

Przeprowadziłem małe śledztwo, polegające głownie na zadawaniu pytań i nakłanianiu ludzi do wypełniania ankiet.

Podsumowując: nic się nie dzieje, ponieważ:

za działający kod płaci każdy, za dobry nikt

nacisk na jakość kodu powinien iść z góry, od menadżerów; programiści-idealiści w końcu zniechęcają

długotrwała praca ze kodem o złej jakości, skutkuje tendencją do dopasowywania się do otoczenia; równamy w dół i tworzymy kod, którego jakość jest nie lepsza niż jego otoczenie

obawiamy się, że radykalne decyzje projektowe okażą się niesłuszne w przyszłości

30 lat z życia programisty

2010-10-02T17:24:00.002+02:00

Miałem ostatnio przyjemność pracować z programistami, które swoje pierwsze programy tworzyli korzystając z kart perforowanych lub kodu maszynowego procesora. Tak istnieją jeszcze tacy...

Zastanawiałem się w jaki sposób Ci ludzie utrzymali się w tej branży tak długo, gdzie przecież co chwila jesteśmy świadkami skoków technologicznych, gdzie wciąż trzeba poszerzać swoje umiejętności albo przekwalifikowywać się. Pewnie pomyślicie, że Ci ludzie zachomikowali się gdzieś na wygodnych stanowiskach i dłubią swoje w COBOLu (nawiasem mówiąc stawka programisty COBOLa to $5000/m-c). Otóż nie, jest zupełnie inaczej.

Najczęściej spotykam programistów w wieku do 30 lat z doświadczeniem od 0 do 8 lat. Większość z nich jest absolutnie przekonana, że OOP rulez! Bardzo wielu nie widzi świata poza Javą, .NETem albo C/C++ - w zależności od tego co piszą. Są absolutnymi fanami tego co robią. I dobrze!
Czym zatem różnią się od programistów z 30 letnim stażem? Przede wszystkim tym, że Ci drudzy są absolutnymi fanami pragmatyzmu.Wciąż tworzą rozwiązania, które zaspokajają potrzeby klientów. Dla wielu z nich OOP albo Java to kolejna nowinka technologiczna. Z mojej perspektywy mają oni niemal ponadczasowe spojrzenie na branżę IT.

Gdy tak roztrząsaliśmy wspólnie różne rozwiązania w systemach IT i próbowałem przekonywać ich do moich ulubionych wizji i ulubionych technologii, jeden z nich uśmiechnął się i powiedział wiesz, z tego co obserwuję co 8-10 lat następuje jakiś gwałtowny zwrot w technologii, jakaś nowinka, która zupełnie odmienia sposób w jaki programiści myślą i tworzą; przeszedłem już przez kilka takich zmian, teraz kończy się mniej więcej 8 lat od dżawowego szału i jestem bardzo ciekaw co będzie dalej...

Moi rozmówcy wieszczyli, że zbliża się era języków funkcyjnych, no zobaczymy czy mają rację.

Życzę sobie, abym kiedyś również potrafił patrzyć na swoją pracę i pracę innych z takim dystansem i trzeźwością co programiści z trzydziestoletnim stażem.

Kilka spraw, o których powinien wiedzieć analityk

2010-07-28T23:26:00.006+02:00

Gdy wchodzisz do firmy jako zewnętrzny analityk, czasem dzieją się dziwne rzeczy...Zebrałem parę punktów, o których warto wiedzieć przed przystąpieniem do pracy. (to luźne, nieposegregowane notatki, więc bez pedantyzmu, pliz ;))

Rozpoznaj strukturę organizacyjną - przed spotkaniem warto wiedzieć kto jest kim i za co odpowiada; pozwoli to lepiej ułożyć grafik rozmów

Ustal wcześniej grafik spotkań - w większości firm nie można wyciągnać ludzi na rozmowę ot tak sobie, trzeba się najpierw umówić

Zawsze ustalaj, czego chcesz się dowiedzieć - bo może się zdarzyć, że po całym dniu spotkań, będziesz przeglądać notatki i zastanawiać się, czego się właściwie dowiedziałeś

Trudno wyciągnąć wymagania od osoby nastawionej na różnice - czasem zdarzy się klient, który wymagania formułuje poprzez wyjątki od reguł; baaaardzo trudno ustalić jak właściwie ma działać wspomagający go system, bo w sposobie myślenia klienta większość rzeczy, którymi zajmuje się w pracy nie ma ze sobą nic wspólnego (np.: nastawiony na różnice doradca bankowy "potrzebuje" oddzielnego systemu dla każdego klienta

System wciąga - gdy przebywasz więcej niż 1 dzień w firmie klienta, zaczynasz wciągać się w ich problemy; ludzie z którymi się spotykasz bezwiednie próbują umieścić w środowisku, w którym się znajdują, próbują cię zaklasyfikować, nadać jakąś etykietkę, jakąś rolę; np. zaczynają cię traktować jako podwładnego Dyrektora IT; jeśli dasz się wciągnąć w tę grę to po tobie, bo stracisz perspektywę "kogoś z boku"

Prowadź spotkanie - bo jeśli ty nie będziesz kierował jego przebiegiem, to na pewno zrobi to ktoś inny; nie osiągniesz wtedy swoich celów

Odróżniaj fakty od emocji - Niektórzy ludzie mówią o swoich odczuciach związanych z oprogramowaniem; pamiętaj, że opiniom nie przysługuje atrybut prawdy; jeśli będziesz wystarczająco długo zadawał pytanie po czy konkretnie poznasz, że...? (np.: po czym konkretnie poznasz, że GUI jest ładne), to dojdziesz do użytecznych faktów

Bądź wyczulony na relacje międzyludzkie - w każdej grupie ludzi, ktoś kogoś lubi albo nie, ktoś z kimś trzyma albo wojuje, ktoś rządzi, a ktoś słucha; rozpoznając relacje w firmie skuteczniej zidentyfikujesz interesariuszy (osoby, które mają odnieść korzyść z powstania systemu), mocnych interesariuszy (osoby, które mają rzeczywistą moc powiedzieć, że system ma wyglądać i działać tak, a nie inaczej) oraz oponentów (tych, którzy będą negować idę powstania systemu); czasem trafnie rozpoznając relacje międzyludzkie możesz odgadnąć, że właściwie nie masz nic do roboty w tej firmie zanim zapadnie taka decyzja

W miarę możliwości porozmawiaj z każdym - jeśli kogoś pominiesz, to mogą przychodzić mu do głowy różne myśli, np.: a może chcą mnie zwolnić?

Ludzie mają przyzwyczajenia - i prędzej wyjmą twoje serce łyżką niż z nich zrezygnują; jeśli nowy soft nie będzie podobny do czegoś, co już znają albo widzieli, to nie będą go używać

Podczas zbierania wymagań koncentruj się na...zbieraniu wymagań - choć chęć zastanawiania się nad tym jak to zrobić jest bardzo silna; to nie jest jeszcze ten moment

Wysyłaj podsumowania po spotkaniu - po pierwsze uporządkujesz wiedzę, po drugie sprawdzisz, czy dobrze zrozumiałeś, po trzecie dostaniesz dodatkowe informacje (a może ktoś coś sobie przypomni?), po czwarte podkreślisz wagę spotkania, po wtóre to jest odbierane jako oznaka profesjonalizmu

Rób notatki podsumowujące spotkanie - i to jak najszybciej po jego zakończeniu! wtedy masz spostrzeżenia na gorąco; rewelacyjnie sprawdza się w tym zakresie mind mapping

Nie daj się uwieść narzędziom - narzędzia w stylu EA i podobne są pożyteczne jak już dokładnie wiesz czego potrzebuje klient i chcesz to zgrabnie zebrać do kupy; korzystanie z nich na wczesnym etapie (choć twórcy wbudowują zachęcające funkcjonalności) ogranicza i usztywnia kreatywność; zamiast zastanawiać się nad potrzebami klienta, zaczniesz rozgryzać narzędzie (a każde z narzędzi ma inaczej zaprojektowany proces pracy, a tenże proces pracy zupełnie nie pasuje to tego w jaki sposób działają nasz mózgi)

Poznaj procesy biznesowe - przed spotkaniami bardzo korzystnie jest poznać specyfikę pracy i procesy biznesowe, które ma wspierać nowe oprogramowanie

http://www.roseindia.net

2010-03-11T00:34:00.003+01:00

Bardzo krótki post, bo mam intensywny tydzień:)
Polecam portal http://www.roseindia.net może nie wygląda najlepiej, ale dawno nie widziałem tylu przykładów w jednym miejscu!

P.S. Lektura uzupełniająca Comparing web frameworks

Dziedziczenie i kompozycja

2009-12-17T08:55:00.012+01:00

Wersja PDF

Ostatnio wygrzebałem w polskiej blogsferze namiar na Aristotle's Error or Agile Smile. Wynika z niego, że nasza wspaniała obiektowość jest dziełem przypadku (a co nie jest?), a ideologię o modelowaniu świata rzeczywistego dorobili spece od marketingu. Jak było w rzeczywistości nie dociekałem. Skoro już obiektowość, a wraz z nią sztandarowe dziedziczenie.

Dziedziczenie

Na Rysunek 1 jest fragment jakiegoś tam systemu. Pewnie każdy z nas widział podobne rzeczy choćby w Java API, które roi się od podobnych lub o wiele bardziej skomplikowanych konstrukcji.

Choć programiście całkiem nieźle używa się klas zaprojektowanych w ten sposób, to gdy programista chciałby na bazie takich konstrukcji rozwijać swoją aplikację (czytaj: dalej nieograniczenie dziedziczyć), to pojawia się kilka problemów:

Aby zrozumieć działanie metody MultiUserRemoteBookStore.findBook() zapoznać się z całą hierarchią dziedziczenia,

Faktycznie uruchamiany kod metody tej metody jest rozsiany pomiędzy wiele klas w hierarchii,
Wymusza się na nas użycie konstruktorów (parametrowych) z nadklas, których wcale nie mieliśmy zamiaru używać,

Dodatkowo nie wiadomo co robią te kostruktory; a nóż przy tworzeniu mojego obiektu coś wybuchnie…

Trudno przetestować jednostkowo nową klasę. No, bo jak tu zamokować kod wywoływany w testowanej metodzie poprzez super.findBook()?

Kompozycja

Większość problemów wynikających ze swobodnego dziedziczenia rozwiązuje kompozycja. Zamiast wyprowadzać nową klasę AcmeBookStore z MultiUserBookStore implementujemy główny interfejs BookStoreService a do potrzebnych metod odwołujemy się poprzez delegację.

I kawałek kodu:




public class AcmeBookStore implements BookStoreService {

 

 private MultiUserBookStore multiUserBookStore;

 

 public Book findBook( String title ) {

  //...

  multiUserBookStore.findBook( title );

  //...

 }

 

}

(Na marginesie warto zauważyć, że w ten sposób stworzyliśmy implementację Dekoratora.)
To rozwiązanie jest zdecydowanie bardziej czytelne i unit-testing-friendly. Kłopot pojawia się gdy nie w architekturze, z którą pracujemy nie istnieje odpowiednik interfejsu BookStoreService. Wtedy już, chcąc nie chcąc, zazwyczaj godzimy się godzimy się na dziedziczenie.

Programowanie poprzez interfejsy

Mając na uwadze w/w mogę zastanawiać się: w jaki sposób mogę projektować architekturę mojego kodu tak, aby nie generował problemów z dziedziczeniem. Pierwszą rzeczą, która przychodzi mi na myśl jest programowanie poprzez interfejsy. Nie oznacza to bynajmniej, że każda nowa klasa UserManager ma swój interfejs UserManagerService, albo (w wersji hardcore) z każdą nową klasą pojawiają się trzy nowe byty w systemie (UserManagerService, UserManagerImpl, AbstractUserManager). Zerknijmy na rysunek:

W tej architekturze centralnym punktem systemu (podsystemu, biblioteki) jest interfejs – kontrakt, który mają realizować poszczególne implementacje. Specyfika implementacji np. RemoteBookStore uzyskiwana jest nie poprzez odpowiednie klasy narzędziowe np. RemotingUtilty. Dzięki temu można tworzyć kolejne implementacje specjalizujące się w coraz to nowych rzeczach, bez konieczności dziedziczenia.

Podsumowując

Ujawniły nam się następujące rzeczy:

Preferowanie kompozycji ponad dziedziczenie,
Programowanie poprzez interfejsy.
Są to jedne z kluczowych paradygmatów programowania obiektowego. Mamy z nich następujące korzyści:
Kod jest czytelny

Kod jest otwarty na testowanie.

Ostatecznie pozostaje jedno pytanie: czy dziedziczenie jest złe? Nie, jest bardzo dobre... w pewnych kontekstach… Złe jest jego nadużywanie. Jak więc rozpoznawać, które konteksty są odpowiedni dla dziedziczenia? Pewnie można wykombinować jakieś obiektywne kryteria, ale ja proponuję znać się na intuicję: czy dziedziczenie uprościło czy zagmatwała architekturę? Czy łatwiej testować, czy trudniej? Czy przyjemniej się pisze, czy - przeciwnie - chce Ci się...

Dziedziczenie zasobnikowe i inne idiotyzmy

2009-12-16T13:40:00.002+01:00

Wrzucam przykłady fantazji w dziedziczeniu, które spotkałem (serio!) parę lat temu. Pierwsze można nazwać dziedziczeniem zasobnikowym. Od razu widać co zrobił kreatywny programista. Pisząc fragment systemu raportowego potrzebował przeczytać dane z pliku properties, a że pamiętał coś takiego ze Struts2, to beztrosko sobie odziedziczył.

Drugi kwiatek jest nieco trudniejszy. Dlaczego okrąg dziedziczy z punktu? Otóż dlatego, jak wyjaśnił autor koncepcji, że punkt jest środkiem tego okręgu…

Takie będą systemy jak ich programistów chowanie

2009-05-18T07:56:00.006+02:00

Zerknąłem na chwilę na blog Jacka. I przeczytałem następujący akapit.

Jest wiele podobnych [mb: do asm/cglib] tematów, których znajomość pomaga, ale nie będąc warunkiem koniecznym odkłada się je na półkę na bliżej nieokreśloną przyszłość. Możnaby mnożyć takich perełek bez liku, chociażby programowanie w języku funkcyjnym, albo nawet tak podstawowe jak wzorce projektowe

Zawrzałem. Jak, na wszystkie potwory Mordoru, ktoś kto pretenduje do poczytnego bloggera w obszarze Java EE, może pisać podobne rzeczy?!? (Dla sprawiedliwości dodam, że następne niecytowane zdania myśl rozwijają i nieco łagodzą). Po chwili zastanowienia zdałem sobie sprawę, że rzeczywiście nie trzeba znać wzorców, żeby programować, ale również:

nie trzeba używać sztućców, żeby się najeść

nie trzeba znać języka, żeby się komunikować za granicą

nie trzeba myć zębów

nie trzeba nosić czapki w zimę, a przy -30 kalesonów

nie trzeba czytać książek

nie trzeba się rozwijać

nie trzeba..., nie trzeba..., nie trzeba...

Żadnej z tych rzeczy nie trzeba. I z pewnością widzimy ludzi, którzy ich nie robią. Od nie robienia tych rzeczy się nie umiera. Przynajmniej nie od razu. Żadna z nich nie jest, wspomnianym przez Jacka, warunkiem koniecznym. Pytanie tylko czy chcemy tak żyć?

[mb: po dyskusji z komentatorami i przemyśleniu sprawy doszedłem do wniosku, że ten akapit to o 1 most za daleko...]Więc jeśli robisz coś, co jak mniemasz kształtuje świadomość programistów i tych, którzy dopiero zaczynają tę przygodę, to kieruj ich w jak najlepszą twoim zdaniem stronę. Nawet jeśli nie dotrą do ideałów, o których piszesz, to:

zostanie ta siła fatalna,
co tobie żywemu na nic, tylko czoło zdobi,
a będzie ich gniotła niewidzialna,
aż zjadaczy chleba w aniołów przerobi

Wpis kończę parafrazą myśli przypisywanej Zamoyskiemu, Modrzewskiemu albo Staszicowi: takie będą systemy, jak ich programistów chowanie!

Domain Specific Language - XML i Fluent Interface

2009-04-21T13:35:00.017+02:00

Wersja PDF

Zamiast rozwodzić się nad definicjami i pojęciami zacznę od pewnego problemu, z którym się spotkałem. Jakiś czas temu do generowania raportów używaliśmy biblioteki JasperReports. To naprawdę rewelacyjna biblioteka, której ideę działania przedstawia Rysunek 1:

Przy całej swej wspaniałości korzystanie z tej (i pewnie z innych) biblioteki do generowania raportów ma następujące konsekwencje:

Szybko generuje się tylko płaskie raporty czyli takie, w których wynikowy raport można „pociąć” na części generowane z jednego szablonu np. spis treści, lista płac, podsumowanie. Jeśli chcielibyśmy zagnieżdżać raport w raporcie, to oczywiście JasperReports daje taką możliwość, ale o całe przygotowanie danych, odpowiednią konfigurację definicji wyglądu i dostarczanie silnikowi danych w odpowiednich porcjach należy zadbać własnoręcznie.

Jeżeli raport musi odwzorowywać wiedzę dziedzinową, np. raportowane są wyniki testu IQ i związana jest z tym złożona merytoryka, to albo bardzo skomplikowane jest przygotowywanie danych a konfiguracja definicji wyglądu w miarę prosta albo odwrotnie. Trudno znaleźć złoty środek.

Ubogacanie raportów wykresami jest możliwe, lecz bardzo pracochłonne.

Jeśli automatyzowane są raporty, które do tej pory były tworzone ręcznie, to...czeka nas baaaardzo dużo pracy.

Framework raportowy

Powstał pomysł, aby problemom zaradzić. Stworzone rozwiązanie powinno zapewniać następujące funkcjonalności:

Definiowanie fragmentów raportu (podraportów), które można ze sobą łączyć sekwencyjnie (jeden za drugim) lub poprzez agregację (jeden w drugim)

Raport można zasilać danymi z: zapytania SQL, zapytania MDX, wyrażenia XPath lub Expression Language

Raport można wzbogacić wykresem z dostępnego zbioru wykresów.

I najważniejsze – wszystko wyżej wymienione powinno odbywać się deklaratywnie.

Została stworzona nadbudówka (warstwa abstrakcji – uwielbiam to wyrażenie!) na JasperReports, która pozwoli deklaratywnie tworzyć raporty. Jak zatem opisywać (deklarować) raporty tak, aby sprostać wymaganiom? Wybór padł na XML. Rysunek 2 prezentuje szkic rozwiązania.

Pojawiły się nowe elementy całego rozwiązania: plik XML, w którym będzie deklarowany raport (a konkretnie podraporty oraz zależności pomiędzy nimi) oraz nadbudówka, która przejmuje kontrolę nad silnikiem JasperReports. Oczywiście pojawia się dodatkowa warstwa pośrednicząca pomiędzy klientem, który chce wygenerować raport, a biblioteką. Wszystko ma swoją cenę. W tym przypadku prostota tworzenia raportów kosztuje dodatkową pracę przy implementacji warstwy pośredniczącej.

Spójrzmy na zamieszczony przykład pliku opisującego raport (na potrzeby artykułu nieco uproszczonego).


<reportConfiguration>
<datasources>
<datasource name="hsql" default="true" type="sql">
<property name="driver" value="org.hsqldb.jdbcDriver" />
<property name="url" value="jdbc:hsqldb:hsql://localhost/mydb" />
<property name="username" value="sa" />
<property name="password" value="" />
</datasource>
</datasources>

<tableOfContents enabled="true" position="begin" designFile="tableOfContents.jrxml" />

<subreports>
<subreport type="static" name="introduction" designFile="introduction.jrxml" /> 

<subreport type="sql" name="employeesList" designFilePath="employeesList.jrxml"
   query="select * name,surname from emplyees" />
</subreports>
</reportConfiguration>

Pojawiły się tu słowa (w postaci znaczników XML) jak reportConfiguration, tableOfContents, subreport, desigFilePath. Nie są to słowa związane z językiem programowania, lecz przeznaczone do opisu jednego konkretnego problemu – deklaratywnego tworzenia raportów. Przy użyciu XML zdefiniowaliśmy język opisu raportów, język opisu specyficznego problemu – Domain Specific Language (DSL).

DSL - implementacja oparta o XML

Z punktu widzenia użytkownika opisującego raport XML jest wygodnym rozwiązaniem. W tym przypadku użytkownikami byli programiści, którzy dodawali funkcjonalność generowania raportów do systemów nad którymi pracowali. Ale czy takie rozwiązanie jest najlepsze z perspektywy całego zespołu, w tym grupy odpowiedzialnej za rozwijanie Framework raportowego? Aby odpowiedzieć na to pytanie należy przyjrzeć się sposobowi zaimplementowania tego rozwiązania.

Pierwszym krokiem jest odczyt konfiguracji z pliku XML. Wygląda to na dość żmudne zadanie. Ale zauważmy, że składnia XML ma charakter obiektowy. Znacznik odpowiada obiektowi, a atrybuty znacznika, atrybutom obiektu. Powstaje pytanie: czy istnieje biblioteka pozwalająca automatycznie przekształcić plik XML do odpowiadającego mu modelu obiektowego? Istnieje – Apache Betwixt (być może są też inne). Rozwiązanie przybiera następującą postać ja na Rysunek 3.

Każdemu znacznikowi z pliku XML odpowiada klasa Java. Biblioteka Betwixt jest odpowiedzialna za przekształcenie struktury XML do analogicznej struktury klas. Aby wykonać to zadanie potrzebna jest dodatkowa konfiguracja. W przypadku tej biblioteki konfigurowanie polega na utworzeniu dla każdej klasy modelu obiektowego pliku .betwixt, w którym zawarte są informacje o mapowaniach znacznik XML – obiekt. Rozwiązanie to przedstawia Rysunek 4.

Zauważmy, że struktura obiektowa odpowiada strukturze pliku XML (Listing 1). DSL w postaci pliku XML ma następujące zalety:

Jest intuicyjny i jego utrzymywaniem mogą zajmować się nieprogramiści;

Opis raportu jest oddzielony od kodu aplikacji;

Można stworzyć elastyczne reguły walidacji składni w oparciu o plik XSD;

Oparcie na standardzie XML daje możliwość edytowania pliku w już istniejących narzędziach WYSIWYG lub stworzenia nowego narzędzia do graficznego opisywania raportu;

Konwersja do nowej wersji DSL jest łatwa do zaimplementowania, np. za pomocą transformat XSLT lub po stronie języka Java.

Jednocześnie to rozwiązanie ma następujące wady:

Występuje dodatkowa warstwa pośrednicząca w postaci biblioteki Betwixt;
Framework korzysta już z 3 rodzajów konfiguracji:
1. Pliki jrxml – wymagane przez bibliotekę JasperReports definiują wygląd graficzny podraportów;
2. Pliki betwixt – wymagane przez bibliotekę Betwixt mapują znaczniki XML na obiekty Java;
3. Plik konfiguracyjny tworzonego frameworka – opisuje zależności pomiędzy podrap ortami, jest to punkt centralny naszego rozwiązania;

Podczas dodawania nowych funkcjonalności najbardziej pracochłonne są modyfikacje związane z plikiem konfiguracyjnym: mapowania, konwersje danych, obsługa błędów;

Ze względu na narzut prac nad plikiem konfiguracyjnym czas oczekiwania na nową wersję biblioteki jest dość długi;

Refaktoryzacja kodu na styku kod Java plik XML jest żmudna i trudna do przeprowadzenia;

Testowanie konfiguracji XML jest niewygodne – bardzo szybko rozmnażają się testowe pliki konfiguracyjne zawierające różne wersje konfiguracji do przetestowania;

Refaktoryzacja testów jest bardzo pracochłonna ze względu na istnienia bardzo wielu plików konfiguracyjnych;

DSL - implementacja oparta o Fluent Interface

W poszukiwaniu alternatywy do implementacji DSL we frameworku raportowym przyjrzyjmy się koncepcji Fluent Interface. Fluent Interface to sposób projektowania API, który łatwo można zobrazować na przykładzie biblioteki JMock.


mock.expects(once()).method("method").withAnyArguments().isVoid();

Trudno o bardziej trafną nazwę niż Fluent Inteface. Wywołania metod można przeczytać jak zdanie w języku naturalnym. Sam koncept nie jest nowy, ja doszukiwałbym się korzeni w kaskadowym korzystaniu ze strumieni w C++ za pomocą operatorów << i >>.

Zaprojektujmy zatem Fluent API do konfiguracji raportu. Powinno ono spełniać następujące założenia:

Wywołania kaskady metod czyta się jak zdanie w języku naturalnym;

API powinno sugerować właściwą kolejność wywoływania metod.

Nowe API nie powinno ingerować w istniejący model obiektowy.

Na początek zajmijmy się klasą DatasourceBean. Potrzebujemy udostępnić metody o odpowiednich nazwach, które będą konfigurowały obiekty tej klasy. Jednocześnie API nie powinno ingerować w już istniejące rozwiązanie. Wymóg separacji API od modelu reprezentującego opis raportu wynika z tego, że nie ma potrzeby, aby obiekty wiedziały w jaki sposób są konfigurowane. W terminologii angielskiej używane jest przy tej okazji słowo agnostic.

Rozwiązaniem spełniającym powyższe kryteria jest wzorzec budowniczego

Odpowiedzialnością klasy DatasourceBeanBuilder jest udostępnienie Fluent API do konfigurowania obiektu klasy DatasourceBean. Praca z API mogłaby wyglądać następująco:



builder.isSqlDatasource()
.withDriver( "org.hsqldb.jdbcDriver" )
.withUrl( "jdbc:hsqldb:hsql://localhost/mydb" )
.withUsername( "sa" )
.withPassword( "" )
.isDefault();

Zapewne domyślasz się, że sztuczka pozwalająca na kaskadowe wywoływanie metod polega na zwracaniu referencji do budowniczego w każdej metodzie. Poniżej implementacja tego budowniczego.


public class DatasourceBuilder {

 private DatasourceBean bean = new DatasourceBean();
 
 
 public DatasourceBuilder withUsername(String username) {
  bean.addProperty( new PropertyBean("username", username) );
  return this;
 }
 
 public DatasourceBuilder withPassword(String password) {
  bean.addProperty( new PropertyBean("password", password) );
  return this;
 }
 
 public DatasourceBuilder withUrl(String url) {
  bean.addProperty( new PropertyBean("url", url) );
  return this;
 }
 
 public DatasourceBuilder withDriver(String driver) {
  bean.addProperty( new PropertyBean("driver", driver) );
  return this;
 }
 
 public DatasourceBuilder isSqlDatasource() {
  bean.setType( "sql" );
  return this;
 }
 
 public DatasourceBuilder isDefault() {
  bean.setDefaultDatasource( true );  
  return this;
 } 
}


Dla każdej klasy modelu obiektowego będzie istniał budowniczy odpowiedzialny za udostępnienie API do konfiguracji obiektu (Rysunek 6).

Jednym z założeń projektowanego interfejsu było, aby sugerował on programiście kolejność wywoływania metod. Osiągnęliśmy to poprzez wprowadzenie wielu budowniczych. W ten sposób użytkownik, w danym momencie pracuje tylko z jednym budowniczym i ma dostęp do metod, które mają sens w danym kontekście. 

Centralnym punktem API jest ReportConfigurationBeanBuilder, który udostępnia użytkownikowi bardziej szczegółowych budowniczych za pomocą swoich metod (Rysunek 7).

Przy obecnym rozwiązaniu użytkownik korzysta z API w następujący:

ReportBuilder report = new ReportBuilder();
 report.withMasterDesing( "master.jrxml" )

 report.newDataSource( "hsql" )
  .isSqlDatasource()
  .withDriver( "org.hsqldb.jdbcDriver" )
  .withUrl( "jdbc:hsqldb:hsql://localhost/mydb" )
  .withUsername( "sa" )
  .withPassword( "" )
  .isDefault();
  
 report.withTableOfContents()
  .designFrom( "tableOfContents.jrxml" )
  .atTheBegining();
 
 report.addStaticSubreport( "introduction" )
  .designFrom( "introduction.jrxml" )
  
 report.addSqlSubreport( "employeeList" )
  .designFrom( "employeeList.jrxml" )
  .withQuery( "select * name,surname from emplyees" )
  .getDataFrom( "hsql" );

Możemy połączyć konfigurację w jeden ciąg wywołań dodając do każdego budowniczego metodę public ReportBuilder and(). W ten sposób możliwe jest korzystanie z API w następujący sposób:

ReportBuilder report = new ReportBuilder();
report .withMasterDesing( "master.jrxml" )
.newDataSource( "hsql" )
.isSqlDatasource()
 .withDriver( "org.hsqldb.jdbcDriver" )
 .withUrl( "jdbc:hsqldb:hsql://localhost/mydb" )
 .withUsername( "sa" )
 .withPassword( "" )
 .isDefault()
 .and()
 .withTableOfContents()
 .designFrom( "tableOfContents.jrxml" )
 .atTheBegining()
 .and()
 .addStaticSubreport( "introduction" )
 .designFrom( "introduction.jrxml" )
 .and()
 .addSqlSubreport( "employeeList" )
 .designFrom( "employeeList.jrxml" )
 .withQuery( "select * name,surname from emplyees" )
 .getDataFrom( "hsql" );

Wydaje się jednak, że to rozwiązanie jest mniej czytelne niż poprzednie.

DSL oparty o Fluent Interface ma następujące zalety:

Jest bardzo czytelny i wygodny w użyciu;

Łatwość tworzenia i utrzymania testów jednostkowych – ponieważ wszystko napisane jest w Javie (innym języku);

Wsparcie dla refaktoryzacji kodu i testów jednostkowych;

Zdecydowanie szybsza implementacja poprawek i nowych funkcjonalności w porównaniu z rozwiązaniem opartym na XML.


Przy powyższych niewątpliwych zaletach należy mieć świadomość następujących konsekwencji tego rozwiązania:

Tylko programista może konfigurować raport;

Zaprojektowanie dobrego Fluent API wymaga sporo czasu i wysiłku;

Stworzenie narzędzia WYSIWYG do konfigurowania raportu wymaga znacznego nakładu prac.



Krótkie podsumowanie

Zarówno XML jaki Fluent Interface mają swoje plusy dodatnie i ujemne. Można próbować określić zakresy przydatności każdego z rozwiązań. W omawianym przykładzie framework  raporty był biblioteką programistyczną. Jedynymi jej użytkownikami byli programiści. Gdybym jeszcze raz brał udział w tym projekcie z pewnością przychylałbym się ku Fluent Interface. Głównym moim argument są korzyści wynikające z łatwości testowania, refaktoryzacji i możliwości szybkiej rozbudowy narzędzia. Gdyby jednak framework miał być wykorzystywany przez zewnętrzne systemy np. narzędzia WYSIWYG to XML, mimo narzutów implementacyjnych, jest rozwiązaniem bezkonkurencyjnym.

Przedstawione tu rozwiązania to nie jedyny sposób tworzenia DSL. Gdy tworzyliśmy framework raportowy pojawiały się pomysły napisania języka do opisu raportów przy użyciu Ruby. Wtedy jednak nie nazywaliśmy tego jeszcze DSL. Zainteresowanych tematem odsyłam do bliki Martina Fowlera.



Nawyki programisty
2009-04-07T12:41:00.002+02:00
Artykuł ukazał się w kwietniowym numerze Software Developer's Journal

Jak myślisz, co ma wpływ na Twoją skuteczność, kiedy programujesz? Wśród wielu czynników z pewnością wymienisz: wiedzę, umiejętności techniczne, doświadczenie, motywację, zaangażowanie, współpracę, chęć uczenia się i wiele, wiele innych. Na ogólnym poziomie wymienione rzeczy dzielą się na dwie grupy: czynniki techniczne oraz czynniki nietechniczne. Zakładamy, że skoro jesteś programistą, to doskonale wiesz, czego potrzebujesz w obszarze umiejętności technicznych. Dlatego proponujemy Ci przyjrzenie się umiejętnościom z drugiej grupy – umiejętnościom nietechnicznym.

Rzucamy wyzwanie

Zaprezentujemy kilka prostych czynności, które konsekwentnie stosowane każdego dnia mogą wprowadzić ogromną jakościową zmianę w Twojej pracy. 
Nie próbujemy Cię przekonywać, nie prosimy, abyś uwierzył na słowo. Sprawdź
i przekonaj się sam. 

Zawrzyjmy kontrakt, że przez najbliższe trzydzieści dni będziesz stosować opisywane nawyki, a potem ocenisz efekty. W tym względzie wymagamy sumienności. Trzydzieści dni to trzydzieści dni i ani jednego mniej. To bardzo niewielkie wymaganie, biorąc pod uwagę fakt, że jakość Twojej pracy znacząco wzrośnie. Jeśli zrobisz przerwę w trakcie eksperymentu, to zacznij odliczanie od nowa. Mamy umowę?

Nawyk 1. – Rozpoczynaj pracę o stałej porze

Nie bez powodu metodyki z nurtu Agile zalecają trzymanie się ustalonej długości iteracji. Gdy wykonujesz rzeczy regularnie, w określonym porządku – nabierasz rytmu. W ten sposób skupiasz się na rzeczach najistotniejszych i nie zaprzątasz sobie głowy nieustannym organizowaniem swojego dnia pracy, ponieważ masz pewien nawykowy schemat postępowania.

Wielu programistów ma elastyczny czas pracy. Muszą być być na swoim stanowisku, np.: od 10 do 16, a pozostałe godziny mogą odpracować w domu. To bardzo wygodne rozwiązanie, ale powoduje, że dużo energii poświęcają na zorganizowanie każdego dnia, ponieważ każdy dzień jest inny. Stosowanie stałego rozkładu dnia pozwoli Ci skoncentrować się na rzeczach najważniejszych. Na początek rozpoczynaj dzień pracy o stałej porze.

Nawyk 2. – Planuj  swój dzień

Jak często zdarza Ci się mówić: Nie mam czasu? To zdanie to bardzo dobry pretekst lub wymówka. Masz czas. Masz dokładnie tyle samo czasu, co każdy inny programista na Ziemi – 24 godziny w ciągu doby (życie na innych planetach pomijamy). Najważniejsze pytanie brzmi – co robisz z czasem, który masz do dyspozycji?

Przeprowadź eksperyment. Przeznacz jeden dzień na przyglądanie się wszystkiemu, co robisz w trakcie pracy. Zanim cokolwiek zrobisz – zapisz to. Przykładowe czynności, które możesz zanotować: napisanie testu metody, napisanie implementacji metody, wdrożenie aplikacji na serwer testowy, wyszukanie informacji w Internecie, rozmowa telefoniczna, sprawdzanie poczty, rozmowa, problemy z oprogramowaniem lub sprzętem. 

Zapisanie zajmie najwyżej kilka sekund, zatem koszt naszego eksperymentu jest znikomy. Na koniec dnia powinieneś mieć spis rzeczy, które robiłeś w ciągu dnia. Następnie oblicz, jaki procent czasu przeznaczyłeś na programowanie. Jak bardzo zdziwił cię wynik?
Niech planowanie dnia stanie się Twoim codziennym rytuałem. Zanim zaczniesz pracę zaplanuj, co będziesz robić danego dnia i ustal, co jest dziś najważniejsze. Przeanalizuj jak wiele zrobiłeś i zaznacz wykonane zadania w swoim planie. Być może właśnie postanowiłeś, że najpierw przeczytasz jakąś supermądrą książkę na temat zarządzania czasem, zainstalujesz odpowiednie oprogramowanie i dopiero wtedy będziesz gotowy do działania zgodnie z planem. Nic z tych rzeczy, absolutnie tego nie rób. Jesteśmy bardzo dumni z Twojej kreatywności, ale książki i oprogramowanie nie są Ci w tej chwili potrzebne. Wystarczy kartka papieru i długopis. Zachowuj te kartki, niech to będzie Twój Osobisty Dziennik Sukcesów.

Nawyk 3. – Opracuj rozwiązanie przed implementacją

Słynny fizyk John Wheeler powiedział kiedyś: Nigdy nie zabieraj się do obliczeń, dopóki nie znasz odpowiedzi. Możemy sparafrazować tę myśl: nigdy nie zbieraj się do programowania, dopóki nie znasz rozwiązania. Dość często programiści rzucają się do implementowania, nie zadając sobie sobie podstawowego pytania: Czy to ma sens?. Gdy programujesz pod wpływem impulsu, napotykasz szereg problemów, na które nie jesteś przygotowany. Poświęcasz na ich rozwiązanie wiele energii i jednocześnie odczuwasz frustrację, że to zajmuje aż tyle czasu. Po kilku godzinach lub co gorsza po kilku dniach okazuje się, że  funkcjonalność najlepiej zaimplementować w zupełnie inny sposób. Dochodzisz wtedy do wniosku, że wykonałeś kawał wspaniałej, lecz niepotrzebnej roboty.

Nigdy nie zabieraj się do programowania, dopóki nie znasz rozwiązania. Najpierw przemyśl swój pomysł, naszkicuj kilka diagramów, zbadaj konsekwencje rozwiązania, zastanów się nad alternatywami. Czasem kilkanaście minut prac koncepcyjnych oszczędza wiele godzin programowania.

Nawyk 4. – Szacuj zadania

Wykonanie zadania zajmie przeważnie co najmniej tyle czasu, ile na nie przeznaczysz. Jeśli na zaimplementowanie jakiejś funkcjonalności przeznaczysz 16 godzin, a uda Ci się zakończyć zadanie w 10, to kolejne 6 spędzisz na udoskonalaniu i poprawianiu rozwiązania albo nawet na sześciogodzinnej refaktoryzacji. Co więcej, znajdziesz bardzo wiele racjonalnych powodów, dla których było to absolutnie konieczne. 

Zanim przystąpisz do programowania, oszacuj czas potrzebny na to zadanie. Prawdopodobnie miałeś już do czynienia z podobnymi zadaniami, a nawet jeśli nie, to znasz kogoś, kto robił coś podobnego. Będziesz mieć punkt odniesienia dla szacowania. W skrajnym przypadku oszacuj intuicyjnie. Od razu uprzedzamy, że często będziesz się mylić – to nieuniknione. Wszelkie informacje dotyczące odchylenia od przewidywanego czasu zapisuj w swojej bazie szacowań. Zaglądaj do niej często i koryguj przewidywania według zapisanych obserwacji. Bardzo szybko staniesz się ekspertem w tym obszarze.

Nawyk 5. – Odłącz się od internetu

Internet jest niecenioną pomocą w naszej pracy, lecz potrafi przykuć uwagę na długie godziny. Zastanów się jak często poszukujesz informacji w sieci i jak często kończysz surfowanie, gdy znajdziesz potrzebne rzeczy. Czy  odsyłacze do innych stron nie kuszą Cię? Czy podczas zapoznawania się z API danej metody, nabierasz chęci zapoznania się z całą dostępną dokumentacją   biblioteki lub frameworka? Jeśli tak,to odłącz się od internetu na czas pracy. Być może przychodzą Ci teraz do głowy myśli, że nie możesz dobrze pracować bez internetu, że będziesz potrzebował absolutnie niezbędnych informacji. Jeśli tak właśnie myślisz, to zajrzyj do notatek, które zrobiłeś w trakcie ćwiczenia dotyczącego planowania dnia (lub zrób je jeszcze raz na bardziej szczegółowym poziomie). Ile czasu poświęcasz poszukiwanie informacji potrzebnych do pracy, a ile na czytanie ciekawych artykułów nie związanych z tym co aktualnie robisz, na sprawdzanie poczty co pięć minut, na korzystanie z komunikatorów internetowych? Porównaj wyniki z czasem, który przeznaczasz na odnajdywanie informacji związanych z Twoim bieżącym zadaniem.

Aby pożytecznie korzystać z internetu, najlepiej podporządkować to aktualnemu zadaniu. Proponujemy następując schemat postępowania:

Zaplanuj swój dzień (patrz: Nawyk 2.);

Opracuj rozwiązanie przed implementacją (patrz: Nawyk 3.);

Zdobądź informacje potrzebne do wykonania zadania;

Odłącz internet i programuj przez dwie godziny;

Zrób przerwę, przeanalizuj to, co udało się wykonać i przejdź do kolejnej części zadania.


Musimy wyjaśnić jeszcze jedną rzecz. Przyczyną naszej propozycji odłączenia się od sieci nie jest internet sam w sobie, a celem wskazanego sposobu postępowania nie jest odcięcie Cię od źródła informacji. Naszym zamierzeniem jest zapanowanie na nawykowym i częstym, niż to potrzebne, korzystaniem z internetu, które rozprasza programistę i negatywnie wpływa na jego efektywność.

Nawyk 6. – W pierwszej kolejności poszukuj błędów w swoim kodzie

Za chwilę przeczytasz bardzo kontrowersyjny akapit, zatem zrób krótką przerwę. Przerwij na chwilę czytanie, popatrz na drzewa, zanuć ulubioną piosenkę.

Uwaga! Z naszego doświadczenia i z doświadczenia liderów, z którymi współpracujemy wynika, że większość przyczyn błędów w oprogramowaniu leży po stronie programisty, natomiast ten poszukuje ich na zewnątrz: w technologiach, w bibliotekach, w niedociągnięciach innych programistów, w złośliwości rzeczy martwych.

Przed Tobą ostatnie i najtrudniejsze ćwiczenie. Najtrudniejsze, ponieważ dotyka Twoich przekonań. Wiemy, że to niełatwe zdanie. Odwagi, uda Ci się!
Za każdym razem, gdy napotkasz irytujący błąd w kodzie, nad którym pracujesz, załóż, że to Ty zrobiłeś coś, co go spowodowało. Poszukuj przyczyny przez założony czas i dopiero, gdy to nie przyniesie efektu, przyjmij, że możesz szukać na zewnątrz.

Nie ma drogi na skróty

Być może zadajesz sobie pytanie: Ile czasu mam poświęcić, aby stać się wysoce efektywnym programistą?. Odpowiedź brzmi: Tyle, ile trzeba. Nie ma drogi na skróty. Nabywanie nowych umiejętności i rozwijanie ich wymaga czasu, pracy, cierpliwości i sumienności. Jeśli zaakceptujesz ten fakt, nauka stanie się łatwiejsza i przyjemniejsza. Nawyki, które opisaliśmy, mogą pomóc Ci skoncentrować działanie na ważnych rzeczach i zorganizować sposób pracy, lecz odpowiedzialność za ich wprowadzenie w życie leży po Twojej stronie – Ty decydujesz.




mistrzprogramowania.pl
2009-01-14T13:56:00.003+01:00
Z przyjemnością informuję, że BNS IT wydało swoją pierwszą książkę!
Nosi piękny tytuł Jak całkowicie odmienić sposób programowania używając REFAKTORYZACJI.

Autorem książki jest Mariusz Sieraczkiewicz.

Szczegóły na mistrzprogramowania.pl

Możesz pobrać wersję bezpłatną (jest to ok. połowa książki i zawiera trochę reklam BNS IT).

Miłej lektury!


7 Kroków Zła w Projektach IT
2009-01-02T08:02:00.012+01:00


Wersja PDF



Czy zastanawiałeś się już jak to się dzieje, że na początku projektu jesteś maksymalnie zmotywowany, piszesz wspaniałe testy (wszystkie są oczywiście green-bar), używasz swojego najpiękniejszego stylu kodowania, klasy, interfejsy metody, ba! nawet pola mają swoją własną, niepowtarzalną odpowiedzialność. Rysujesz piękne diagramy, używasz wzorców projektowych w rozsądnej ilości, a Twój kod czyta się jak najbardziej przejrzystego ebooka. A potem...potem pojawia się niewielki, ledwo zauważalny zgrzyt, mała rysa na wspaniałym krysztale projektu. Ignorujesz to, bo przecież nic się nie stało. Rysa rośnie, a przez nią wsączają się kolejne niedociągnięcia i niedoróbki, aż po jakimś czasie nie poznajesz już tego wspaniałego projektu, siadasz do niego z największym obrzydzeniem i myślisz tylko kiedy to się skończy? Lecz projekt się nie kończy, wciąż są nowe wymagania, wciąż trzeba go utrzymywać. I to, mój przyjacielu, jest Programistyczne Piekło!

Jako przestrogę podam Ci kilka prostych wskazówek jak się tam znaleźć. Ścieżka prowadząca wprost do Programistycznego Piekła jest szeroka, gładka i bardzo prosta. Wystarczy siedem kroków.


Bądź obojętny
Czy to ja powinienem zająć się tym //FIXME? Nieee, to nie ja pisałem, niech ktoś inny to zrobi. 
Czy często zdarza ci się rozumować w ten sposób? Jeśli tak, to gratuluję! Osiągnąłeś pierwszy poziom wtajemniczenia. Obojętność wobec niewielkich rys na projekcie to początek drogi w dół. Być może pomyślisz: oj, jeśli w jednej klasie będzie niewielki bałagan, to przecież nic się nie stanie. Pamiętaj, że małe rzeczy się kumulują. Nie zauważysz od razu różnicy pomiędzy metodą nazwaną divideByTwo(), a div2()
, bo łatwo umyka wśród reszty kodu. Lecz z pewnością dostrzeżesz różnicę za pół roku, gdy tego typu nazewnictwo będzie obecne w całym projekcie. Ziarnko do ziarnka...

Bądź w miarę wierny swoim ideałom
Cóż, w zasadzie stosuję wzorce projektowe...to znaczy w niektórych projektach. Tych w domu. Piszę też testy...prawie wszystkie przechodzą. Piszę zgodnie ze standardem kodowania...właściwe to w 30%, bo reszta jest niepotrzebna. Odpowiedzialność? Taa, fajny koncept, ale moim zdaniem.... 
Znasz to? Czy uważasz, że techniki programowania obiektowego teoretycznie są bardzo dobre ale faktycznie się nie sprawdzają? Jak wyrobiłeś sobie takie zdanie? Acha, przetestowałeś to, rozumiem. Wiesz, to że nie działają, to tylko jedna możliwość. Druga to taka, że używasz ich niewłaściwie. Co wybierasz?

Postępuj zgodnie z procedurami
Pokrycie kodu ma być co najmniej 90% więc w tym tygodniu już nie muszę pisać żadnego testu! Ta metoda jest nieczytelna...no, ale CheckStyle się nie czepia. Diagramy muszą być tylko do istotnych elementów systemu...moja jest chyba nieistotna?
Procedury, reguły, zasady są dobre. Precyzują sposób pracy i optymalizują sposób wytwórczy. Często jednak, niemal automatycznie, uważa się, że stosowanie procedur w zupełności wystarczy, zatem można zwolnić się z myślenia. Kłopot w tym, że nawet najbardziej wyrafinowane zasady nie przewidują wszystkich sytuacji, które mogą wystąpić w życiu. Bardzo wiele problemów, z którymi się spotkasz, nie da się rozwiązać za pomocą Księgi Procedur używanej w twoim zespole. Jednak z każdym z nich można sobie poradzić przy użyciu zdrowego rozsądku.

Graj dla zespołu
Nie wychylaj się. Bezkrytycznie akceptuj opinie bardziej doświadczonych kolegów. Postaw cele zespołu nad swoimi własnymi
Przede wszystkim: dlaczego pracujesz w tym zespole? Wymień dziesięć przyczyn. Zrób to teraz!
Jeśli praca, która wykonujesz nie jest zgodna z twoimi osobistymi celami, nie prowadzi cię do jakiegoś wyżej postawionego celu, to prędzej czy później, zaczniesz sabotować to, co robisz. Krok po kroku, niepostrzeżenie, zaczniesz wprowadzać w życie misterny plan obniżania jakości swojej pracy. Być może już teraz warto wybrać się na rozmowę z samym sobą.

Dziel się odpowiedzialnością
Jest błąd w mojej części kodu? ...ale Paweł kazał mi tak napisać...powiedział, że będzie działać...
Zadziwiające, że jeśli chodzi o sukces, to chętnie podpisujemy się pod nim sami. Jeśli chodzi o wzięcie odpowiedzialności za błąd i niepowodzenie chętnie dzielimy się odpowiedzialnością z innymi.

Ceń ludzi takich jak ty
MY programiści i ONI analitycy. MY javowcy i ONI .NETowcy. MY od kluczowego projektu i ONI od maintenance. MY starzy pracownicy i ONI nowi...
Dzieląc swoich i innych sprawia, że nadajemy grupie osób wspólne cechy odróżniające ich od nas samych, czyniących w jakimś stopniu gorszymi. Etykietowanie zapewnia poczucie bezpieczeństwa i porządkuje świat. Daje złudzenie, że nie zginiemy w zespole jako indywidualność. Jak na ironię, takie postępowanie likwiduje indywidualność członków zespołu i blokuje efekt synergii, obejmującą ludzi nic nie znaczącą etykietą oni.

Wierz w najlepsze rozwiązanie
Ok, pracujemy w Agile, teraz już będzie dobrze. JEE rozwiąże wszystkie problemy. Nowy framework sprawi, że praktycznie kod będzie pisał się sam.
Gdyby istniało rozwiązanie/technologia/framework rozwiązująca wszystkie problemy to już dawno by zostało wymyślone i żylibyśmy w świecie, w którym nie byłoby wojen, nikt nie przekraczałby  prędkości, a programy by się nie zawieszały. Nie istnieje najlepsze rozwiązanie (w ogóle). Co najwyżej może istnieć rozwiązanie najlepsze, w sensie: najbardziej odpowiednie i optymalne, w danej chwili, dla danego problemu, w danym zespole. Jedyne co może zrobić nowa technologia, framework, biblioteka, czy język to przenieść ciężar problemu w inne miejsce. To coś jak dźwignia pozwalająca zużyć mniej energii do uzyskania tego samego efektu. Pamiętaj jednak, że zawsze istnieją dwie strony medalu. Coś co rozwiązuje jedne problemy zazwyczaj generuje nowe.


Tekst powstał z inspiracji artykułem Philipa Zimbardio Evil's Seven Step Seduction Scenario opublikowanym w Charaktery 9/2008


"Coaching dla programisty". Ruszł program pilotażowy
2008-12-29T21:23:00.002+01:00
O postępach w rozwijaniu rozwijaniu umiejętności dowiesz się z bloga jednego z uczestników programu: Rafała 0.


Wzorce projektowe - Fabryki. Rysunkowy tutorial
2008-12-22T18:24:00.005+01:00


Wersja PDF


Kreacyjne wzorce projektowe dostarczają programistą szeregu metod pozwalających na sprawne zarządzanie tworzeniem obiektów w systemie. W tutorialu omawiam kilka z nich, prezentując strukturę w postaci diagramów UML, implementację oraz obszary zastosowań.

Jeśli chcesz przypomnieć sobie jak czytać diagramy UML w odniesieniu do kodu Java przeczytaj najpierw wcześniejsze tutoriale:

Java i UML - Diagram klas

Java i UML - Diagram sekwencji




















Light? heavy?
2008-12-12T22:18:00.005+01:00
Sporo już powiedziano o relacji pomiędzy Spring a EJB. Jedni twierdzili, że to konkurencyjne rozwiązania, inni zgodzili się, że wzajemnie się uzupełniają. Moje prywatne zdanie jest takie, że Spring wyrósł na obrzydzeniu do EJB2.x i jego podstawowymi zaletami były: nieinwazyjność, lekkość, elastyczność i coś co nazywam sobie lepkością czyli umiejętność integracji i "przylepiania się" do istniejących rozwiązań. Pojawienie się EJB3 trochę rozmyło granice. Oto bowiem dostaliśmy eleganckie rozwiązanie korporacyjne z niezależną od kontenera częścią do trwałego przechowywania danych i innymi bajerami. Co prawda całość była nieco w tyle, za rozwiązaniami z community, ale aura standardu słodziła niedogodności. W takiej sytuacji moim zdaniem pomiędzy Spring a EJB istniały 2 zasadnicze:

EJB wymaga osobnego kontenera, Spring nie

jeśli używasz EJB to bierzesz całą technologię, cało wielgachną maszynerię którą oferuje, w Springu bierzesz tyle ile potrzebujesz

Ostatecznie każde z nich znalazło swoją niszę i dobrze się tam miało. Szczególnie punkt nr 2 stanowił o przewadze Spring w systemach działających na jednej maszynie, nie wymagających rozproszonych transakcji, asynchroniczności, itd., itd.

Bardzo podoba mi się w Sunie to, że uczy konsekwentnie się uczy. Uczy się diabelnie dużo od społeczności OpenSource, czego efektem było właśnie rzeczone EJB3.
Wydarzyły się też dwie ważne rzeczy, które rzucają nowe światło na relację Spring - EJB. 

Po pierwsze Interface21 vel SpringFramework vel. SpringSource dostało kupę forsy od inwestora (słyszałem o $10mln). Sprawiło to, że chcąc używać Springa za darmo będziemy korzystać tylko z głównych wydań bez późniejszych poprawek, aż do kolejnego wydania głównego...chyba, że opłacimy subskrypcję:) Trochę głupio, ale trudno mieć im za złe, że chcą zarobić pieniądze na swojej pracy. Sęk w tym, że będąc najpierw projektem OO naruszyli pewną barierę psychologiczną. Bardzo Springowi pomagało bycie darmową "alternatywą" dla EJB, do tego użyteczną i świetnie napisaną. To było coś w stylu Robin Hooda - w tej roli bezinteresowny Spring Framework, a z przeciwnej strony Szeryf z Nottingham - czyli EJB Samo Zło. I w całej sytuacji najlepsze jest to, że Robin wybudował sobie własny zamek i ściąga jeszcze większą daninę niż Szeryf, walcząc zażarcie o każdą piędź Lasu Sherwood.

Po drugie: Przeglądając nowości w JEE6 i EJB3.1 jeszcze bardziej podoba mi się kierunek, w którym Sun zmierza. Moją uwagę zwróciła koncepcja profili, której ideą jest, aby można było użyć tylko taką cześć platformy, która jest akurat potrzebna. Czyli można będzie odchudzić sobie korporacyjną Javę np. z asynchroniczności i rozproszonych transakcji jeśli zajdzie taka potrzeba. Ja tu widzę światełko w tunelu do zapewnienia tej użytecznej możliwości, którą posiada Spring czyli: bierzesz tyle ile potrzebujesz. 
Jest więcej ciekawych (bardzo ciekawych: żeby zwrócić uwagę na adnotację @Singleton i specyfikację WebBeans) rzeczy w EJB3.1, ażeby się nie powtarzać  zamieszczam na końcu linki do artykułów.

Jak to dalej będzie ze EJB i Springiem? Może JEE6 albo JEE7 da nam wszystko czego potrzebujemy? A może jakiś nowy pomysł SprigSource okaże się tak rewolucyjny, że zdeklasuje alternatywy na długie lata? A może jeszcze inaczej? Któż to może wiedzieć w czasach kryzysu:)


Literatura
http://blog.dywicki.pl/2008/09/28/spring-commercial-source-replaces-open-source/
http://springinpractice.wordpress.com/2008/12/02/new-stuff-in-spring-30/
http://springinpractice.wordpress.com/2008/12/03/new-stuff-in-spring-30-part-2/
http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-1
http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31
http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31-3
http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-Part4


Weekendowe Warsztaty: Wzorce Projektowe w Paraktyce
2008-12-09T14:51:00.000+01:00
Zapraszam na „Weekendowe Warsztaty: Wzorce Projektowe w
Paraktyce".

Każdy uczestnik ma swój komputer (notebook), aby realizować ćwiczenia.
Osią warsztatów jest projekt, który jest sukcesywnie rozwijany -
dodawane są nowe funkcjonalności. Rozbudowa systemu jest pretekstem do
wprowadzania kolejnych wzorców.

Warsztaty mają charakter praktyczny i ostatecznie prowadzą do stworzenia
systemu opartego o wzorce, zachowując pragmatyzm przy ich użyciu. Przede
wszystkim stawiamy na podkreślenie aspektu współpracy między wzorcami,
gdyż największa ich siła ujawnia się dopiero wtedy.

ZOBACZ PROGRAM
http://www.bnsit.pl/files/Wzorce_projektowe_java_i_refaktoring.pdf

KIEDY?: 13, 14 grudnia br.

CZAS TRWANIA: 2 x 8 godzin (sobota, niedziela), od 9 do 17

GDZIE?: W centrum Łodzi; wybór konkretnej sali zależy od ilości uczestników

CZEGO POTRZEBUJESZ?:
    * Notebook z kartą Wi-Fi
    * Zapału i chęci do poznania czegoś nowego

JAK SIĘ ZGŁOSIĆ?:
    * przesłać mail na adres bnsit@bnsit.pl z tematem WARSZTATY
    * wpłacić zaliczkę (do piątku 12 grudnia br.) w wysokości 100zł na
konto mBank 12 1140 2004 0000 3902 5596 2724, w tytule przelewu proszę
wpisać swoje imię i nazwisko; dane adresowe firmy znajdziesz w stopce maila
    * pozostała część opłaty wnoszona jest przed rozpoczęciem zajęć w sobotę
    * w przypadku, gdy nie zgłosi się wystarczająca ilość uczestników, aby
uruchomić szkolenie, otrzymasz zwrot zaliczki w ciągu 3 dni roboczych

TWOJA INWESTYCJA: 800 zł

Na dodatkowe pytania odpowie Michał Bartyzel m.bartyzel{{{orangutan}}}bnsit.pl


Java i UML - Diagram sekwencji. Rysunkowy tutorial
2008-12-09T14:44:00.005+01:00


Wersja PDF


Diagram sekwencji jest, obok diagramu klas, najczęściej używanym diagramem UML. Pozwala ma modelowanie dynamicznych aspektów systemu.
W artykule zamieszczam bardzo zwięzły rysunkowy tutorial, obrazujący sposób korzystania z diagramu sekwencji. Dodatkowo dodałem przykłady pokazujące relację pomiędzy diagramem, a kodem w języku Java.










Ad.pilotażowego programu "Coaching dla programisty"
2008-12-02T12:53:00.003+01:00
W związku z pytaniami zamieszczam więcej szczegółowych informacji nt. programu.

CEL: Praktyczne zweryfikowanie hipotezy: "Każdy może stać się dobrym programistą"

ADRESACI: Osoby, które:
    * znają język Java
    * posiadają niewielkie doświadczenie w pracy w tym języku (np.: język Java poznany na studiach, certyfikat SCJP, samodzielna nauka języka, pisanie programów na zaliczenia albo jako hobby)
    * chcą pracować jako programiści Java/JEE
    * potrafią prezcyzyjnie określić swój cel zawodowy w perspektywnie najbliższych 2 lat

KOSZT: bns it nie pobiera opłaty od uczestników programu

ZOBOWIĄZNIA UCZESTNIKA:
    * ukończenie programu
    * systematyczna praca
    * prowadzenie bloga programistycznego, na którym uczestnik będzie regularnie opisywał swoje doświadczenia, spostrzeżenia, porady dla innych, itp.

ZOBOWIĄZANIA BNS IT:
    * zapewnienie wykwalifikowanego trenera
    * prowadzenie zajęć i ocenianie postępów

JAK APLIKOWAĆ:
    * przysłać zgłoszenie na adres m.bartyzel {maupeczka} bnsit.pl
    * w treści maila proszę umieścić frazę [COACHING]
    * do zgłoszenia proszę dołączyć kod źródłowy programu napisanego w języku Java (np. program, z którego jesteś najbardziej dumny/a albo taki, który napiszesz specjalnie dla mnie:))
    * do zgłoszenia proszę dołączyć linki do 3 ofert pracy, którymi jesteś zainteresowany
    * do zgłoszenia proszę dołączyć informację: w jakich miastach rozważasz pracę jako programista, kiedy orientacyjnie planujesz zacząć pracę
    * na każde zgłoszenie odpowiemy do 20 grudnia
    * zastrzegamy sobie prawo do przyjęcia tylko wybranych kandydatów/kandydatek

FORMA ZAJĘĆ:
    * zajęcia odbywają się zdalnie za pośrdednictwem komunikatora
    * sesje odbywają się 1 lub 2 razy w tygodniu w odzinach
ustalonych indywidualnie z trenerem
    * ogólny plan zajęć można przedstawić następująco:   
        - sformułowanie celu do osiągniecia
        - stworzenie harmonogramu prac
        - systematyczna praca nad przygotowaniem się do osiągnięcia postawionego celu
        - osiągnięcie celu
        - koniec uczestnictwa w programie

CZAS TRWANIA:
    * zależy od czestnika oraz postawionego celu
    * szacunkowo można zakładać od 3 miesięcy w górę

DALSZE PERSPEKTYWY:
    * Po pozytywnym ukończeniu programu "Coaching dla programisty":
        - osiągniesz postawiony przez siebie cel

    * Do poniższych rzeczy się nie zobowiązujemy, ale też nie wykluczamy, że:
        - być może przygotujemy Cię do rozmowy kwalifikacyjnej
        - być może polecimy Ci firmę rekruterską
        - być może być może zorganizujemy Ci spoktanie z potencjalnym pracodawcą
        - być może zaproponujemy Ci pracę w jednym z projektów projektów prowadzonych przez nas
        - być może...:) 

i jeszcze krótka notatka dot. przykładowego kodu, o który proszę:
1. To nie musi być ukończony i działający program. Chciałbym się zorientować co do sposobu pisania
2. Interfejs użytkownika jest dla mnie na chwilę obecną najmniej ważny
3. Przykładowe aplikacje:
    * System ankietujący - ma umożliwiać przygotowanie, wysłanie i zebranie odpowiedzi na pytania zawarte w ankiecie
    * System aukcyjny - ma umożliwiać przeprowadzanie aukcji internetowych

A TERAZ UWAGA! Ponieważ wiem, że programiści mają tendencję do perfekcjonizmu i wykonanie zadanie mogło by kogoś pochłonąć na kilka najbliższych lat:) proszę ustawić sobie czasomierz i przesłać mi tyle ile da się napisać W CIĄGU 36 GODZIN(oczywiście nie trzeba siedzieć przed komputerem 3 dni z rzędu:) można rozłożyć pracę na tydzień albo 2)


Zdobądź wymarzoną pracę jako programista/projektant Java/JEE!
2008-11-28T09:39:00.004+01:00
Jeśli marzysz o programowaniu,

Jeśli chcesz stać się ekspertem,

Jeśli stale przeglądasz oferty pracy dla programistów

ale

Twoje doświadczenie nie jest wystarczające,

Nie wiesz od czego zacząć,

Przytłacza cię mnogość wymagań w ofertach pracy.

Weź udział w pilotażowym programie Coachig dla programisty. Jeśli dołączysz do programu, zostanie ci przydzielony trener, który podczas indywidualnej pracy z tobą wprowadzi cię w tajniki programowania.
W ciągu kilku miesięcy możesz zostać świetnym programistą i dostać wymarzoną pracę. Przy pomocy trenera sformułujesz cel, który osiągniesz. Czy masz odwagę marzyć...?

U podstaw programu leży przekonanie, że każdy może stać się świetnym programistą. 
Stawiamy tylko dwa wymagania:

 znajomość języka Java (np. wyniesione ze studiów)

 umiejętność systematycznej pracy



Ile to kosztuje? 0 zł (słownie: zero zł)

Twój kontakt dot. pilotażowego programu Coaching dla programisty:
Michał Bartyzel
m.bartyzel {{{maupeczka}}} bnsit.pl
+48 503 062 421


Język wzorców
2008-11-06T09:14:00.008+01:00


Wersja PDF




Przewrotnie nadałem temu wpisowi tytuł nawiązujący do książki Christophera Alexandra, gdyż od niego zaczęła się ta cała zabawa i chyba już nigdy się nie skończy. 
Trudno powiedzieć czy Alexander odkrył naturę powtarzalności czy też tylko uświadomił ludziom to, co czynili od zawsze.

Architektura oprogramowania

Jak na złość koncept powtarzalnych wzorców zyskał największy posłuch wśród inżynierów oprogramowania. Gdy się zastanowić, to są ku temu ważkie powody. Po pierwsze znakomita większość projektów programistycznych przekracza budżet i/lub założone ramy czasowe. Po drugie tworząc milion razy ten sam system można to zrobić na milion różnych sposobów. Naturalnie powstaje pytanie: który ze sposobów jest najlepszy? Bez wahania można odpowiedzieć, że ten który najlepiej spełnia założone kryteria będące w tym przypadku funkcją oceny produktu. Utożsamienie wspomnianej funkcji oceny oprogramowania z, tylko i wyłącznie, wymaganiami użytkowników jest poważanym uproszczeniem. Rzeczona funkcja ma wiele składowych: wymagania użytkowników, założony koszt, ramy czasowe, oczekiwania każdego z członków zespołu, itd. Jedne z nich są specyfikowane jawnie, inne manifestowane zupełnie nieświadomie. Mamy zatem pewne kryterium ewaluacji sposobu programowania: końcowy produkt ma być optymalny ze względu na przyjętą funkcję oceny.

Wzorce projektowe

Szansę na optymalizację funkcji oceny oprogramowania dostrzeżono właśnie w konceptach Christophera Alexandra. Założenia były proste: wiele systemów jest do siebie podobnych, podobieństwo dotyczy różnych poziomów abstrakcji i różnych części systemu. Dodatkowo systemy tworzone są za pomocą języka programowania. Stąd pytanie: czy istnieją takie konstrukcje językowe, które w optymalny sposób rozwiązują problemy związane z programowaniem?  

Wspomniane problemy dotyczą sposobu w jaki współpracują obiekty w systemie w celu realizacji określonego zdania. (Część zagadnień opisałem w artykule Organizowanie logiki biznesowej.) W 1995 światło dzienne ujrzała książka Design Patterns katalogująca 23 wzorce projektowe dotyczących inżynierii oprogramowania. Niezwykle ważną rzeczą, prócz samych wzorców, którą wniosła wspomniana publikacja, był aparat pojęciowy umożliwiający rozpoznawanie oraz klasyfikowanie nowych pojawiających się wzorców projektowych. Od tego momentu nastąpiła gwałtowna eksploracja tego tematu przez różnych autorów.

Design Patterns została napisana przez czterech autorów i przyjęło się określać ich jako Gang of Four (GoF), natomiast wzorce przez nich skatalogowane jako Wzorce GoF. 
Ich charakterystyczną cechą jest, że dotyczą konstrukcji programistycznych używanych do poprawy jakość tworzonego kodu. Wzorce te dotyczą współpracy obiektów w obrębie jednego systemu.
Umiejętne posługiwanie się tymi wzorcami jest absolutnym minimum kompetencji programisty i bazą dzięki której może on efektywnie korzystać z kolejnych technologii. Wzorce GoF są podstawą piramidy, na której opiera się praca i rozwój programisty. Istnieje możliwość wzięcia udziału w Weekendowych Warsztatach z Wzorców GoF, o których wspominałem w poprzednim wpisie.

Klienci stawiali przed programistami coraz większe wymagania. Systemy informatyczne musiały mieć coraz większą funkcjonalność, stawały się coraz większe. Dało to impuls do rozwoju technologii takich jak J2EE czy .NET. Technologie dostarczają wiele możliwości, czasem zbyt wiele,...technologie bywają niedoskonałe. W przypadku J2EE te niedoskonałości i problemy z użytkowaniem spowodowały powstawanie wzorców projektowych w odniesieniu do tej konkretnej technologii, czego egzemplifikacją stała się przełomowa publikacja Core J2EE Patterns.

Z drugiej strony skala systemów informatycznych, niezależnie od użytej technologii rodziła problemy, których nie rozwiązywały klasyczne Wzorce GoF (GoF, jak pamiętamy, dotyczyły przede wszystkim efektywnej współpracy obiektów pomiędzy sobą w obrębie systemu). Zastosowanie Wzorców GoF w dużym systemie, rzeczywiście ułatwiało pracę i czyniło go bardziej elastycznym, lecz już sama jego rozległość wymagała dodatkowego podejścia - podejścia globalnego, podejścia od strony architektury całego systemu. System miał wykonywać pewne zadania, prezentować dane użytkownikowi i trwale przechowywać wyniki swoich działań. Rozwinęły się: koncepcja warstw w systemie informatycznym oraz pomysły na udostępnianie danych klientom oraz na ich trwałe przechowywanie. Klasyką w tym obszarze jest publikacja Martina Fowlera Patterns of Enterprise Application Architecture, w której autor opisuje wzorce projektowe w aplikacjach klasy enterprise. Pozycja ta daje globalny pogląd na architekturę systemów informatycznych. Wzorce tam opisywane, na własny użytek i dla odróżnienia od GoF, nazywam Wzorcami Architektonicznymi. Warto nadmienić, że Martin Fowler przy gotowuje kolejną publikację na temat Wzorców Architektonicznych. Nie wiadomo kiedy się ona ukaże, jednak z postępem prac można zapoznać się na blogu Fowlera.

Problemy związane z architekturą aplikacji, z użytkowaniem technologii J2EE sprowokowały co najmniej trzy bardzo wartościowe następstwa. Po pierwsze: "stworzyły" środowisko sprzyjające rozwojowi wzorców projektowych. Po drugie: jako implementacja konkretnych Wzorców Architektonicznych powstały frameworki takie jak: Struts, Hibernate, JDO, Spring Framework, WebWork, iBatis i wiele innych. Po trzecie: w konsekwencji popularności frameworków rozpoczął się proces standaryzacyjny JCP, który zaowocował specyfikacją JEE5.

Dalszy rozwój systemów informatycznych uświadomił wszystkim zaangażowanym, że żadna z istniejących technologii jest w jakiś szczególny sposób uprzywilejowana. Jakkolwiek by nie argumentować każda będzie miała swoich zwolenników i przeciwników. Można się z tym poglądem nie zgadzać, ale nie sposób zaprzeczyć, że istnieje jego namacalna konsekwencja: w strukturze informatycznej przedsiębiorstwa działają systemy różnego typu stworzone w różnych technologiach. I choć najbardziej popularne rozwiązania dostarczają sposobów na obsługę całego infrastruktury informatycznej, to jednak każde przedsiębiorstwo ma swoją historię i nikt przy zdrowych zmysłach nie będzie zmieniał sprawnie działającego systemu tylko dlatego, że został napisany w Fortranie a nie w Javie.

Zatem każdy nowy system musi sprawnie komunikować się z istniejącą infrastrukturą. Wymaganie to spowodowało odkrywanie wzorców dotyczących integracji systemów informatycznych. Tę gałąź wzorców projektowych nazywam Wzorcami Integracyjnymi, a jako programową publikację można podać Enterprise Integration Patterns napisaną przez Gregora Hohpe'a i Bobbyego Woolfa.

Poszukiwanie pewnej powtarzalności w tworzeniu systemów informatycznych, mające na celu optymalizowanie określonej wcześniej funkcji oceny, pojawia się na każdym etapie złożoności nie zależnie od tego, czy jest to oprogramowanie desktopowe czy system obsługujący wielką korporację.

Okazuje się, że stosowanie konstrukcji architektonicznych to jedna część układanki. Pracując w różnych projektach programiści wypracowali swego rodzaju wiedzę plemienną, która pomaga im w pracy. Zaznaczam, że nie chodzi tutaj o wzorce projektowe, które rozwiązują konkretne problemy, chodzi raczej o sposób posługiwania się wzorcami w możliwie efektywny sposób.
Odkrycie strategii postępowania programistów wiąże się ze spostrzeżeniem, iż kod źródłowy jest częściej czytany niż pisany. Zatem sposób pisania kodu, konwencje, standardy, w tym sposób używania wzorców projektowych jest kolejnym obszarem, w którym można poszukiwać powtarzalności. 
Doświadczony programista przechodząc z projektu do projektu będzie przenosił pewne pomocne nawyki mające ułatwić mu tworzenie oprogramowania. Dalej, doświadczony lider będzie dbał o to, aby uspójniać te nawyki wśród zespołu. Po co? Celem jest tu efektywna komunikacja. Jeden programista sprawniej pracuje posługując się sposobem kodowania który zna, zespół sprawnie pracuje posługując się tym samym stylem kodowania, nowa osoba w projekcie łatwiej wdroży się do zadań jeśli będzie mogła czytać kod wg pewnych, z góry określonych, zasad.
Wzorce wyodrębnione na tym poziomie zostały zaprezentowane przez Kenta Becka w książce
Implementation Patterns. 

Wzorce Implementacyjne to kolejny kamień milowy w poszukiwaniu powtarzalnych schematów podczas wytwarzania oprogramowania. Dotyczą one sposobów posługiwania się językiem oraz wzorcami projektowymi, a nie konkretnej architektury oprogramowania. Używając porównania do budownictwa: Wzorce Projektowe mówią jakich cegieł należy używać, Wzorce Implementacyjne wskazują jak najlepiej pchać taczkę.


Dalsza dekompozycja

Richard Dawkins w swojej książce Samolubny gen stawia hipotezę, że rozwój nie jest progresywny lecz ekspansywny. Nie przebiega zgodnie z odgórnie ustalonym planem lecz odbywa się poprzez najlepsze dopasowanie do sytuacji bieżącej. Jednostką rozwoju nie jest istota wysokiego rzędu np. człowiek, lecz najbardziej elementarna jednostka - gen. Gen maksymalizuje swoje korzyści w danej chwili, a rozwój osobników wyższego rzędu jest jedynie skutkiem "samolubnych" zachowań genu.

Zastanawia mnie czy ta sama zasada obowiązuje, jawnie bądź w ukrytej postaci, podczas wytwarzania oprogramowania? Bytem wyższego rzędu jest system informatyczny, lecz kto jest samolubnym genem? Obiekt, czy może...programista? Kto dąży to maksymalizowania swoich korzyści w danej chwili? Dawkinsowy gen zachowuje się samolubnie, gdyż pragnie przetrwać, przekazać swój materiał genetyczny. Rozważając programowanie obiektowe musimy zrezygnować z przypisywania obiektom cech genów, gdyż jest obiekt jest ze swej strony bierny w obszarze replikacji. A zatem programista? Czy programista jest samolubnym genem? Zaznaczam, że nie chodzi to celowe działanie na szkodę, lecz o nieświadomy mechanizm funkcjonowania. Jeśli programista spełnia funkcję genu, to materiałem genetycznym musi być kod, który jest przez niego pisany!

Końcowy produkt jest zatem wypadkową: wymagań klienta, budżetu, ram czasowych oraz samolubności programisty. O ile z zewnątrz, w działaniach objawiających się bezpośrednio użytkownikowi, pierwsze cztery czynniki mają znaczącą rolę, o tyle wewnątrz systemu największe znaczenie ma samolubność programisty. Na czym miałaby ona polegać? Na przekazaniu jak największej ilości swoich koncepcji, rozwiązań, pomysłów do kodu systemu. Z kolei koncepcje te zależą od indywidualnych predyspozycji, umiejętności stosowania Wzorców Projektowych i Implementacyjncych,...humoru, itd. Stąd najkorzystniej dla projektu jest dbać o jakość przekazywanych koncepcji dbając o rozwój programistów.

Wspomniany Chirstopher Alexander w książce Timeless Way of Building przedstawia, podobny w idei, koncept, który nazywa porządkiem naturalnym. 
(Przykład za Christopher Alexander czyli w poszukiwaniu doskonałości) Wyobraźmy salę wypełnioną krzesłami w uporządkowany sposób. Chcąc umieścić na sali jak najwięcej osób, można identyczne krzesła ustawić równo w rzędach optymalnie wypełniając salę. Na sali zmieści się wiele osób, ale nie wszystkim będzie wygodnie.
Z drugiej strony można poprosić osoby aby przyszły z własnymi krzesłami i usiadły możliwie najbliżej siebie. W tej sytuacji na sali będą krzesła różnego typu: duże i małe, odległości między nimi będą różne - w zależności od potrzeb siedzących, lecz wszyscy będą się starali, aby na sali zmieściło się najwięcej osób. Takie uporządkowanie Alexander nazywa porządkiem naturalnym. Charakteryzuje się on tym, każda osób ma tyle miejsca ile potrzebuje oraz występuje sprzężenie zwrotne z całością systemu (chęć zmieszczenia jak największej ilości osób). Charakterystyczną cechą porządku naturalnego jest to, że za każdym razem będzie przebiegał według tych samych reguł i za każdym razem efekt końcowy będzie nieco inny od poprzedniego.

W obu przedstawionych koncepcjach kształt ostatecznego systemu jest sterowany przez działania programisty. Alexander dokłada jednak jedną drobną, acz kluczową rzecz: sprzężenie zwrotne. 
Można zatem wnioskować, że jeżeli każdy programista ma dokładną świadomość ostatecznego celu, ostatecznego kształtu systemu i dbając przekazywanie własnych koncepcji w kodzie, weźmie pod uwagę to sprzężenie zwrotne, to jakość wytworzonego oprogramowania wzrośnie.

Koncept sprzężenia zwrotnego uwidacznia się w programowaniu między innymi w takich podejściach jak Continuous Integration, Continuous Testing, czy Test-Driven Development. Całość podejścia do wytwarzania oprogramowania wywiedzionego z porządku naturalnego uwidacznia się w metodykach Agile.
Należy podkreślić jednak niezwykle istotną rzecz. We wspomnianym przykładzie nt. porządku naturalnego, to ludzie przynosili własne krzesła i ustawiali je optymalnie do własnych potrzeb, biorąc pod uwagę całość systemu. Również w podejściu Agile ciężar odpowiedzialności przeniesiony został na programistę. Już nie procedury sterują projektem, lecz ludzie. Wymaga to od programisty wiele uwagi, dojrzałości, a przede wszystkim odpowiedzialności. Wymaga również kompetencji innego rodzaju niż biegłość techniczna w stosowaniu określonych technologii, Wzorców Projektowych, czy Implementacyjnych.

Poza kodem źródłowym

W poszukiwaniu powtarzalności podczas wytwarzania oprogramowania przeszliśmy ścieżkę od Wzorców GoF, poprzez Wzorce Architektoniczne, Implementacyjne, aż do powtarzalnych procesów Agile, gdzie programista tworząc kod nieustannie bierze pod uwagę końcowy kształt systemu.
Każdy programista wie, że nauka wymienionych rzeczy zabiera wiele czasu. Moim zdaniem minimum 2 lata, a to i tak w odpowiednich warunkach. Jednym zabiera to wspomniane 2 lata, innym dłużej, a może i krócej, wielu zniechęca się po drodze. Lecz ci, którym się udało zaczęli programować w inny sposób. Jaka jest zatem różnica pomiędzy stanem początkowym, a końcowym w ścieżce rozwoju programisty i gdzie tej różnicy poszukiwać?
Z pewnością różnica nie polega na znajomości wzorców, bo wiedza teoretyczna może nie zmienić się przez ten czas. Ale przecież różnica istniej! Widać ją w sposobie kodowania, w sposobie podejścia do problemu, w jakości wytwarzanego oprogramowania.
Być może chodzi o to, że taki programista czuje programowanie, myśli poprzez wzorce, widzi je i potrafi zastosować w praktyce. Następuje zatem zmiana w sposobie myślenia (o pewnych jej aspektach pisałem w artykule Metaprogramy w tworzeniu oprogramowania). 

Skoro programista czujący programowanie ma pewien nowy sposób myślenia, a jest wielu takich programistów, to można wnioskować, że istnieje pewien zbiór sposobów postępowania czy myślenia, charakterystyczny dla tych ludzi. Z pewnością każdy robi to w nieco inny sposób, ale skoro potrafią otrzymywać identyczne wyniki w postaci fantastycznie napisanego kodu, to jest jakaś część wspólna tych strategii. Zatem istnieją pewne powtarzalne wzorce, coś jak najlepsze praktyki skutecznych programistów, które charakteryzują ludzie osiągających sukcesy w naszej branży.
Odkrycie tych wzorców jest moim zdaniem kolejnym wyzwaniem przed inżynierią oprogramowania, kolejnym etapem odkrywania i stosowania optymalnych metod pracy. 
Kolejne kroki usprawniania pracy wiodą od udoskonalania narzędzi i metod do rozwoju programisty. Tak już jest, że jakkolwiek skomplikowany by system nie był, w centralnym punkcje i tak znajduje się człowiek.


Weekendowe Warsztaty Wzorce Projektowe
2008-11-05T22:42:00.004+01:00
Serdecznie zapraszamy na „Warsztaty weekendowe poświęcone wzorcom projektowym”. Jest to oferta specjalna dla użytkowników portalu Goldenline.pl i czytelników mojego bloga i bloga Mariusza. Tej oferty nie znajdziesz na stronie BNS IT!

Warsztaty umożliwiają nabycie praktycznych umiejętności tworzenia aplikacji z użyciem wzorców projektowych w języku Java.

Zobacz program warsztatów


Czego potrzebujesz?
• Notebook z kartą wi-fi
• Zapału, chęci i otwartego umysłu

Twoja inwestycja to jedyne: 800 zł.

Nigdzie nie znajdziesz szkolenia ani warsztatów w takiej cenie i jakości.

Powiedz znajomym.

Gdzie?
Warszawa, 13-14.12.2008
Wrocław, 13-14.12.2008
Kraków, 13-14.12.2008

Kontakt:
m.sieraczkiewicz [[[[[ MAUPA ]]]]]] bnsit.pl
+48 500 189 752
http://www.bnsit.pl


Wzorce projektowe: Temporal Object
2008-10-31T15:21:00.011+01:00


Wersja PDF


Kod źródłowy


Gdy zaczynałem poznawać wzorce projektowe punktem wyjścia dla mnie były książki w stylu GoF, blogi, fora, itd. Znajdowałem tam przede wszystkim diagramy UML, oraz banalne przykłady kodu w stylu: fabryka pizzy, szablon algorytmu, budowniczy okienka. Mój kłopot polegał na tym, że chociaż rozumiałem o czym się do mnie pisze, to nie wiedziałem jak zastosować te koncepcje w moim kodzie. Moje projekty związane były np. ze sklepem internetowym lub systemem ankietowym i nijak to się miało do pizzy, algorytmów czy okienek. Brakowało mi przede wszystkim sensownej implementacji wzorca oraz konkretnych wskazówek jak i gdzie go użyć.

Po jakimś czasie zacząłem analizować źródła programów OpenSource takie jak Spring i apache-commons. Sęk w tym, że aby zrozumieć dobrze te projekty trzeba było wzorce projektowe wcześniej znać, a ja dopiero chciałem się ich nauczyć. Sporo mnie kosztowało rozgryzanie tego tematu.

W tej serii artykułów odpowiem choć na część w/w pytań. Będę: omawiał różne wzorce, podawał przykładowe implementacje i podpowiadał gdzie można ich użyć. Jeśli chodzi o sam sposób użycia czyli wprowadzanie wzorca do projektu i wykrywanie potencjalnych miejsc jego zastosowania w projekcie, to ten temat zostanie poruszony w wątku o refaktoringu (w najbliższej przyszłości).

Obiekty z historią

Wyobraźmy sobie, że należy stworzyć model obiektowy, który posłuży do zrealizowania funkcjonalności sklepu (taaa...wiem, że przykład mocno wyświechtany, lecz jakże użyteczny i skoro skojarzenia takie jak Hello world!, foo bar i Team-Member mocno zapadły w umysły rzesz programistów, więc i ja nie będę odstawał i posłużę się dobrze znanym przykładem rzeczonego sklepu).

Centralną klasą modelu będzie obiekt Order. Zakładając, że klient użytkujący sklep może zapisać stan swojego zamówienia, a następnie do niego wrócić, okazuje się, że warto śledzić historię jego...hmmm...niezdecydowania? W przypadku sklepu może być to pomocne np. podczas analizy aktywności klienta, na podstawie której można będzie mu w przyszłości zaproponować nowe produkty i usługi. 

Postawiony problem można uogólnić następująco: stan danego obiektu może zmieniać się w czasie i należy zapewnić możliwość śledzenia historii zmian.
W tym miejscu zrób krótką przerwę, weź kartkę i długopis oraz zaproponuj przykładowe rozwiązanie omówionej kwestii. 

Już masz? Świetnie, zatem porównaj je z dalszą częścią artykułu.

Temporal Object

Twoje rozwiązanie jest z pewnością wystarczające, lecz posłuchaj o innym, które jest na tyle często eksploatowane przez programistów, zostało określone mianem wzorca projektowego. 

Intencją wzorca Temporal Object jest śledzenie zmian w obiekcie i udostępnianie ich na życzenie. Wzorzec ten jest również znany pod nazwami History on Self oraz Version History.

W przykładzie mamy do czynienia obiektem reprezentującym zamówienie. Sformułujmy wymagania co do funkcjonalności:

usługa pracuje z obiektem zamówienia Order

zamówienie można dowolnie zmieniać

historia zmiana ma być śledzona i udostępniana na życzenie

dla celów raportowych, oprócz bieżących, należy zapamiętywać godzinowe milestones


Spójrzmy na projekt rozwiązania:

Głównym konceptem jest wprowadzenie obiektu OrderVersion, który śledzi zmiany w zamówieni, tzn. dla każdej zmiany tworzony jest nowy obiekt OrderVersion. Sam obiekt klasy Order, z które będą korzystały usługi jest niejako proxy bieżącej wersji zamówienia. Dodatkowo wprowadzona została klasa VersionHistory, której odpowiedzialnością jest zarządzanie historią zamówienia.

Całe piękno tego rozwiązania polega na tym, że usłudze udostępniony będzie obiekt Order, który powinien proksować API OrderVersion tyle, że pracuje zawsze na wersji bieżącej. Reszta przetwarzania jest ukryta przed klientem.

Zgodnie z założeniem tej serii artykułów przedstawiam również implementację wzorca.

public class Order implements Serializable {
 private Long id;
 private VersionHistory versioningHistory = new VersionHistory();
 private OrderVersion currentVersion;
 public void createNewVersion( String productId, 
            String productName, Double price ) {
  OrderVersion orderVersion = new OrderVersion();
  orderVersion.setCustomId( productId );
  orderVersion.setName( productName );
  orderVersion.setPrice( price );
  versioningHistory
                    .addOrderVersion( orderVersion.getDate(),   
                       orderVersion );
  currentVersion = orderVersion;
 }
 
 public void setCurrentVersionTo( Date when ) {
  currentVersion = versioningHistory.findVersion( when );
 }
 protected OrderVersion getCurrentVersion() {
  return currentVersion;
 }
 public String getCustomId() {
  return getCurrentVersion().getCustomId();
 }
 public void setCustomId( String customId ) {
  getCurrentVersion().setCustomId( customId );
 }
 //delegacje reszty getterów i setterów
}



public class VersionHistory implements Serializable {
 private Map orderVersions
            = new HashMap();
 private List orderHourMilestones
            = new ArrayList();
 public OrderVersion findVersion( Date date ) {
  return orderVersions.get( date );
 }
 public void addOrderVersion( Date date, OrderVersion version ) {
  orderVersions.put( date , version );
 }
 public void createHourMilestone() {
  //...
 }
}



public class OrderVersion implements Serializable {
 private Long id;
 private String customId;
 private String name;
 private Double price;
 private Date date;
 public OrderVersion() {
     this.date = Utils.getNow();
 } 
}
 //gettery i settery



A co z persystencją?

Kolejny problem, o który można potknąć się podczas nauki wzorców to kwestia związana z trwałym przechowywaniem danych. O ile w języku obiektowym można napisać niemal wszystko, również w bazie danych można stworzyć dowolnie złożone rozwiązanie to jednak sklejenie tego razem czasem nastręcza kłopotów. Dlatego, aby opis wzorca był kompletny zajmijmy się teraz trwałym przechowywaniem danych w relacyjnej bazie danych.

Domyślnie, używając dostarczycieli persystencji dla JPA, przyjmowana jest zasada, że jeden obiekt jest mapowany do jednej tabeli w bazie danych. Moim zdaniem przyjęcie takiej arbitralnej zasady prowadzi do bałaganu w bazie danych oraz do jej „niewyważenia”. Niewyważenie rozumiem jako sytuację, gdzie poszczególne tabele przechowują nieproporcjonalnie dużą ilość danych, np. jedna tabela ma 2 kolumny oraz 10 wierszy, natomiast inna 20 kolumn i 10000 wierszy. Taka sytuacja w moim mniemaniu daje przesłanki do zastanowienia się, czy ta mała tabela jest potrzebna. Być może można znajdujące się w niej dane umieścić jako dodatkową kolumnę i innej tabeli i w ten sposób uprość zapytania SQL pracujące na bazie. Zaznaczam, że to moje prywatne zdanie.

Wykorzystując mapowania JPA umieścimy strukturę obiektową w dwóch tabelach: orders – przechowującej zamówienia oraz orders_versions – przechowującą wersje poszczególnych zamówień.

Schemat bazy danych będzie wyglądał następująco:

Wiersze z orders identyfikują poszczególne zamówienia oraz wskazują na jego bieżącą wersję. Natomiast wiersze z orders_versions przechowują dane na temat danej wersji.

Dodatkowo każda wersja wskazuje na zamówienie do którego należy oraz, jeśli jest godzinowym milestonem, to wskazuje na właściciela. Na poziomie obiektowym pomiędzy obiektami Order oraz VersionHistory występuje relacja 1:1, zatem wiersze z orders identyfikują również obiekt VersionHistory. Z tego względu orders_versions posiada dodatkowe wskazanie na orders w postaci klucza ref_order_hour_milestone, określające, że dana wersja należy do historii wersji danego zamówienia.

Odpowiednie mapowania JPA wyglądają następująco:

@Entity @Table( name = "orders" )
@NamedQuery( name="Order.findAll", query="from Order" )
public class Order implements Serializable {
 @Id
 @GeneratedValue( strategy=GenerationType.AUTO )
 private Long id;

 @Embedded
 private VersionHistory versioningHistory = new VersionHistory();

 @OneToOne
 @JoinColumn(name="ref_current_version")
 private OrderVersion currentVersion;
}



@Embeddable
public class VersionHistory implements Serializable {
 
 @OneToMany(cascade=CascadeType.ALL)
 @MapKey( name="date" )

     @JoinColumn( name="ref_order_history" )   
 private Map orderVersions
  = new HashMap();
 
 @OneToMany
 @JoinColumn( name="ref_order_hour_milestone" )
 private List orderHourMilestones
            = new ArrayList();
}



@Entity @Table( name = "orders_versions" )
public class OrderVersion implements Serializable {
 @Id
 @GeneratedValue( strategy=GenerationType.AUTO )
 private Long id;
 @Column( name="custom_id" )
 private String customId;
 private String name;
 private Double price;
 private Date date; 
}



Jak można zauważyć pomiędzy tabelami ordersa orders_versions występuje powiązanie dwukierunkowe.  
Na wstępie tego rozdziału wspominałem o dbaniu o optymalność zapytań. Przeprowadziłem test i zapis jednego zamówienia z trzema wersjami powoduje wykonanie na bazie następujących zapytań SQL:

Hibernate: insert into orders (ref_current_version) values (?)
Hibernate: insert into orders_versions (custom_id, date, name, price) values (?, ?, ?, ?)
Hibernate: insert into orders_versions (custom_id, date, name, price) values (?, ?, ?, ?)
Hibernate: insert into orders_versions (custom_id, date, name, price) values (?, ?, ?, ?)
Hibernate: update orders set ref_current_version=? where id=?
Hibernate: update orders_versions set ref_order_hour_milestone=? where id=?
Hibernate: update orders_versions set ref_order_history=? where id=?
Hibernate: update orders_versions set ref_order_history=? where id=?
Hibernate: update orders_versions set ref_order_history=? where id=?



Zmieńmy jedna nieco schemat bazy danych przenosząc powiązanie zamówienia z jego bieżącą wersją do tabeli orders_versions. Rysunek poniżej:

Zmiana na w mapowaniach jest bardzo niewielka:

 //...
public class Order implements Serializable {
 //...
 @OneToOne(mappedBy="parentOrder")
 private OrderVersion currentVersion;
 //...
 public void createNewVersion( String productId, String productName, 
  Double price ) {
  //..
  orderVersion.setParentOrder( this );
 }
}



//..
public class OrderVersion implements Serializable {
 //..
 @OneToOne
 @JoinColumn(name="ref_order")
 private Order parentOrder;
 //..
}


Zestaw zapytań tym razem wygenerowany przez Hibernate wygląda następująco:

Hibernate: insert into orders values ( )
Hibernate: insert into orders_versions (custom_id, date, name, ref_order, price) values (?, ?, ?, ?, ?)
Hibernate: insert into orders_versions (custom_id, date, name, ref_order, price) values (?, ?, ?, ?, ?)
Hibernate: insert into orders_versions (custom_id, date, name, ref_order, price) values (?, ?, ?, ?, ?)
Hibernate: update orders_versions set ref_order_hour_milestone=? where id=?
Hibernate: update orders_versions set ref_order_history=? where id=?
Hibernate: update orders_versions set ref_order_history=? where id=?
Hibernate: update orders_versions set ref_order_history=? where id=?


Zatem mamy o jedno zapytanie mniej. Czy to dużo? Trudno powiedzieć, aczkolwiek na każde tysiąc zapisów zamówienia do bazy danych mamy tysiąc zapytań mniej...

Podsumowując

Wzorca Temporal Object można użyć jeśli występuje potrzeba śledzenia i zapamiętywania zmian w modelu obiektowym. Używając narzędzi O\RM o trwałego zapisu danych, nie dajmy się zwieść iluzji, że programista może zapomnieć o bazie danych. Jeśli mamy na uwadze wydajność należy o tym pamiętać, zwłaszcza wtedy, gdy większość narzędzi ukrywa przed programistą złożoność swoich działań.

Kompletny kod źródłowy omawianego rozwiązania znajdziesz na blogu, którego adres widoczny jest na stronie tytułowej artykułu. W projekcie zostały użyte mapowania JPA, Hibernate jako dostarczyciel persystencji oraz baza danych MySQL


Uwaga na Immutable + JPA
2008-10-29T19:46:00.007+01:00
Ostatnio użyłem wzorca Immutable w tradycyjnej implementacji


public class Team {
  
   public Member getMember() {
     return new Member( this.member );
   }
  
}


Po zmapowaniu klasy adnotacjami JPA sporo głowiłem się dlaczego dostaję albo zbyt wiele wierszy w bazie albo wyjątek z informacją, że nastąpiła próba zapisu obiektu transient...rzut oka na powyższy kod wyjaśnia sprawę ;) ech...


Strzeż się ludzi, którzy są pewni tego, że mają rację!
2008-10-28T17:53:00.006+01:00
Programista, architekt, bazodanowiec, temaleader...cokolwiek człowiek by nie robił, z biegiem czasu się specjalizuje, z biegiem czasu staje się ekspertem. I to chyba jest bardzo niebezpieczne... 

Zbyt łatwo zdarza się nam powiedzieć do siebie samego: "Ok, już wszystko umiem". Kiedy przyjdzie Ci do głowy takie zdanie wiedz, że już po tobie! Twoja kariera, kimkolwiek byś nie był, właśnie rozpoczęła powolny lecz konsekwentny ruch w dół, czy raczej w tył.

Powyższe, wypowiedziane na głos lub choć wewnętrznie zadeklarowane, stwierdzenie automatycznie zamyka na dalszy rozwój, gdyż zakłada, że on się zakończył. Świat się rozwija, technologia się rozwija i zatrzymanie się w miejscu faktycznie oznacza cofanie się.

Profesjonalizm można poznać po tym, że osoba pozostaje otwarta. Otwarta na to, że każdego dnia może nauczyć się czegoś nowego, że może nauczyć się czegoś od młodszego kolegi właśnie przyjętego do pracy, od podwładnego, od kogoś kogo uważa za mniej kompetentnego od siebie, że może nauczyć się czegoś od swojego ucznia. Tylko ta postawa gwarantuje możliwość ciągłego doskonalenia się. Oto jest sens słynnego Wiem, że nic nie wiem!


Organizowanie logiki biznesowej
2008-10-02T20:27:00.005+02:00
Chris Richardson, w książce Pojo in Action podaje kilka decyzji, które musi podjąć projektant systemu enterprise w Jawie. Jednym z wyborów przed którym rzeczony projektant stoi dotyczy sposobu w jaki zorganizowana jest logika biznesowa. Autor nazywa to wyborem pomiędzy podejściem proceduralnym a obiektowym. Rzecz w tym, by wybrać jeden z trzech opisanych przez Martina Fowlera wzorców. Choć Richardson podaje pewne kryteria, to jednak operuje na pojęciach wybitnie nieostrych typu: duże projekty, małe projekty, skomplikowana logika, niewiele logiki. W artykule chciałbym przyjrzeć się problemowi i podać bardziej namacalne kryteria wyboru.
(Czytelnik niezaznajomiony z wzorcami enterprise znajdzie zwięzłe charakterystyki na końcu artykułu; po szczegóły odsyłam do bliki Martina Fowlera, rozdział Domain Logic Patterns.

Proceduralnie czy obiektowo?

Bez obawy! Nikt nie zmusza Cię do cofnięcia się w świat języków proceduralnych, nie w tym rzecz...Istotę problemu można sformułować następująco: Powstało wymaganie biznesowe, aby napisać system robiący COŚ TAM. Jak się do tego zabrać, aby uczynić zadość oczekiwaniom klienta i jednocześnie włożyć to wysiłek odpowiedni do natury rzeczy. Wiadomo, że klient chciałby jak najwyższą jakość za jak najniższą ceną, natomiast dostawca chce dostarczyć najniższą dopuszczalną jakość za jak najwyższą cenę. Słowem, kwestia jest poważna.

Klasyczne podejście obiektowe każe nam zbudować obiektowy model dziedziny problemu charakteryzujący się współpracującymi pomiędzy sobą obiektami, z których każdy charakteryzuje się swoim stanem oraz zachowaniem. Obiekty będą współpracować ze sobą odzwierciedlając swój stan w bazie danych oraz w interfejsie użytkownika w taki sposób, aby zrealizować zdefiniowane przez niego wymagania.

W podejściu proceduralnym nie będziemy modelować rzeczywistości, nie będziemy modelować dziedziny problemu. W tym podejściu każemy bazie danych krok po kroku zapamiętać pewne dane, każemy interfejsowi użytkownika wprost wypisać pewne dane tak, aby w konsekwencji użytkownik dostał to, co chciał. Skąd wiemy co chciał? Chciał to, co definiują use cases.

Jak przełożą się powyższe decyzje na prace programisty? Np. tak, że w pierwszym przypadku zaprzęgniemy do działania Spring Framework, JSF i Hibernate albo EJB i resztę a drugim zdecydujemy się na PHP. Albo jeśli lubimy Jawę, to w drugim przypadku weźmiemy Tomcata, Struts2 i  nie zważając na to co nam mówią o warstwach i odpowiedzialnościach, zaimplementujemy całą logikę w akcjach (tu właśnie mogą być pomocne Transaction Script lub Table Module, sprawdź w jaki sposób:))

Zauważmy, że działania użytkownika w każdym, nawet najbardziej skomplikowanym systemie, w ostatecznym rozrachunku sprowadzają się odpowiedniej sekwencji operacji CRUD. Tak, końcowym rezultatem interakcji pomiędzy obiektami jest zmiana stanu bazy danych. Można zatem twierdzić, że każdą usługę systemu zdefiniowaną poprzez use case można zastąpić skończoną ilością operacji elementarnych CRUD. Ot i istota całego problemu.

Kwestia wyboru pomiędzy podejściem obiektowym a proceduralnym sprowadza się do rozstrzygnięcia jaka jest relacja pomiędzy usługą systemu a operacjami elementarnymi.

Jeśli jest to przełożenie 1:1 np. sklep internetowy, katalog książek, itp, gdzie działania użytkowników sprowadzają się właściwie do operacji CRUD to opłaca się użyć podejścia proceduralnego.

Jeśli mamy do czynienia np. z aplikacją kadr i płac, bankiem czy obsługą giełdy to usługa systemu może mieć przełożenie na setki albo tysiące operacji elementarnych. W takim przypadku stworzenie rzetelnego modelu dziedziny ułatwi panowanie nad rozwojem projektu. Skorzystamy też z dobrodziejstwa wielu frameworków, które ułatwiają pracę. Pamiętajmy, że w konsekwencji i tak ostatecznym rezultatem będzie zestaw CRUDów z tą różnicą, że nie będziemy zmuszeni tworzyć go samodzielnie, dzięki modelowi obiektowemu oraz frameworkom zatrzymamy się na wysokim poziomie abstrakcji.

Wiem, że pominąłem kilka istotnych aspektów takich jak bezpieczeństwo, transakcyjnośc itd. Koncentrowałem się tylko na organizowaniu logiki biznesowej.


Transaction Script - w podejściu proceduralnym pozwala na ujecie w całość wielu operacji, które muszą być wykonane w jednej transakcji

Domain Model - podejście obiektowe charakteryzuje się tworzenie modelu obiektowego dziedziny problemu

Table Module - w podejściu proceduralnym jest czymś pośrednim pomiedzy Transaction Script a Domain Model, pozwala na skupienie logiki biznesowej w okół danych, na których logika pracuje


Jakieś to takie skomplikowane...
2008-07-22T19:59:00.011+02:00
Ostatnio miałem trochę do czynienia z narzędziem PowerDesigner. Ogólnie rzecz ujmując jest to narzędzie do modelowania... 
Próbując określić odpowiedzialność tego narzędzia doszedłem do wniosku, że jest to narzędzie, które wychodząc od procesu biznesowego, pozwala w zrozumiały dla wszystkich (od dołu aż do góry korporacyjnej hierarchii) sposób opisać to, co dzieje się w biznesie, wspomóc analizę tegoż oraz, jeśli zajdzie taka potrzeba, doprowadzić do zaprojektowania stosownych narzędzi informatycznych, począwszy od wstępnych wymagań, na szkielecie systemu z wykorzystaniem konkretnych technologii skończywszy, uff!

Po pierwsze: zgubiłem się w strukturze

Rzeczą, która od razu rzuciła mi się w oczy, to ogrom możliwości tego narzędzia. Użytkownik może stworzyć różnego rodzaju modele, diagramy i zależności między nimi. Jako (zaznaczam: początkującemu) użytkownikowi brakowało mi procesu, który wskazywałby kierunek prac. PowerDesigner nie wspiera żadnej metodyki, więc w zasadzie nie wiadomo co należy robić. I mimo, że można wszystko, to i tak nie wiadomo co...

Po drugie: "Na przekór czasom i ludziom wbrew..."

Projektanci narzędzia z pewnością mieli pomysł na jego używanie. Przynajmniej ja gorąco w to wierzę. Aczkolwiek odniosłem wrażenie, że Sybase próbuje forsować jakieś własne podejście do modelowania, za nic sobie mając przyzwyczajenia analityków. Owszem, PowerDesigner wspiera co tylko może wspierać, ale odpowiedzialności poszczególnych składowych nachodzą na siebie. Tego właśnie mi brakowało! - dokładnie zdefiniowanych odpowiedzialności poszczególnych modelów.

Skoro 95% tego, co można zrobić w PowerDesigner, da się zrealizować za pomocą UML, to po co mi narzędzie za $7000?

Trzeba uczciwie przyznać, że po głębszym przyjrzeniu się narzędzie szokuje możliwościami, lecz nie wychodzenie na przeciw przyzwyczajeniom użytkowników sprawia, że próbują oni używać programu na swój własnny sposób, niezgodny z pomysłem projektantów. Oczywiście powoduje to frustrację, a interfejs użytkownika czyni nieergonomicznym do granic możliwości.

Wiele narzędzi przekonało mnie, że próby generowania kodu "z automatu" kończą się źle. Nie inaczej i w tym przypadku. Totalna kaszana, choć wierzę, że intencje były dobre.

PowerDesigner sprawia wrażenia programu rozwijanego przez grupę fantastycznych, ale kompletnie oderwanych od rzeczywistości, programistów.

Po trzecie: Narzędzie do wszystkiego

Mówią, że "jeśli coś jest do wszystkiego, to jest do niczego". Odkryłem, że to bzdura i daleko idące uogólnienie. Takie, na przykład, koło, dźwignia albo
klin. Używane są wszędzie i do wszystkiego, ale nikt im nie zarzuca, że są nieprzydatne.

Otóż i esencja mojego odkrycia: jeśli coś jest wystarczająco proste, może być "do wszystkiego" albo inaczej złożoność narzędzia/koncepcji/rozwiązania jest odwrotnie proporcjonalna do zakresu jego stosowalności.

Gdyby zatem Sybase, zamiast gigantycznego all-in-one, wypuścił zestaw narzędzi o określonej specjalizacji, które dodatkowo świetnie ze sobą współpracują, to miałby u mnie lepsze noty:)
Dobrym przykładem jest pakiet MS Office. Pomiając indywidualne upodobania, mamy klarowną sytuację: Word - piszemy, Excel - liczmy, PowerPoint - prezentujemy, Outlook - organizujemy, Binder - i to jest genialne, spinamy wszystko razem ale tak, że narzędzie nie zatracają własnej indywidualności. Dla użytkownika jest w miarę jasne co ma zrobić, aby uzyskać określony efekt.

A teraz objadę sobie UMLa

Ilu diagramów UML najczęściej używasz? Ja 2 - klas i sekwencji. A ilu elementów z tych diagramów najczęściej korzystasz? Ja z co najwyżej 10. Duch Pareto nie śpi, co? UML, z początku fajny, ale w miarę rozrastania się i usztywniania zrobił się beee. To musi pęknąć, już pęka. Powstają mutacje w stylu Robustness Diagrams, które wybierają z UML tylko to, co jest naprawdę niezbędne do określonego celu.

Osobiście traktuję UML jako zbiór sugestii odnośnie modelowania Używam piktogramów, ale konkretne zasady traktuje raczej luźno. Jestem zdania, że jeśli zespół jednoznacznie rozumie notację, to jest to ok. Nawet jeśli jest to notacja nieformalna.

Więc czego bym tak naprawdę chciał?

Myślę, że jeśli chodzi o projekty (nie tylko IT) będziemy świadkami następujących przemian:

centralizacja na rzecz decentralizacji i współpracy

szansą na ogarnięcie coraz to bardziej złożonych projektów jest podzielenie ich na mniejsze kawałki; brzmi trywialnie...coraz trudniej centralnie sterować ogromnymi przedsięwzięciami programistycznymi, zatem należy zrezygnować (pozornego) kontrolowania sytuacji i bardziej polegać na współpracy niewielkich, wyspecjalizowanych zespołów programistycznych; zamiast na dokładne modele, należy postawić na zaufanie i na kompetentnych ludzi

ustrukturyzowanie na rzecz procesów, elementów składowych oraz płaskich relacji

w miarę rozrostu projektu, utrzymywanie odpowiedniej struktury staje się coraz bardziej pracochłonne; po pewnym czasie nadchodzi moment, w którym dbanie, aby wszystko odbywało się wg wytycznych jest kosztowniejsze niż dodawanie wartości biznesowej do produktu; strukturę mogą zastąpić procesy - łatwiejsze w modyfikacji i bardziej elastyczne oraz elementy składowe wraz z płaskimi relacjami pomiędzy nimi; 




TDD: O co właściwie chodzi?
2008-07-21T07:21:00.001+02:00


Wersja PDF


Szczerze mówiąc nie wiem jak jest w polskich firmach z TDD. Wiem, że testy się pisze, pokrycie się bada, ale jak z samym TDD sprawy się mają – pojęcie mam bliskie zeru. Wszak pisanie testów i TDD to nie to samo.

Testy jednostkowe

Wiadomo co to są testy jednostkowe i jak działają – w gruncie rzeczy, chodzi o to, aby rozpocząć testowanie możliwie wcześnie na najbardziej elementarnym poziomie – na poziomie obiektów i ich metod. Co i jak testować – na tym skupię się innym razem. Teraz chodzi mi raczej o wyszczególnienie sytuacji z jakimi można zetknąć się podczas pisania testów jednostkowych.

Testy dopisywane są po zakończeniu implementacji – cóż, jeśli w projekcie do tej pory testów nie praktykowano, to nie ma innej rady. Trzeba pamiętać tylko o jednej rzeczy: jeśli istniejąca metoda zawiera buga, który jeszcze się nie objawił, to napisany do niej test traktuje go jako poprawne działanie metody.   Jest tak właśnie dlatego, że test pisany jest do istniejącej metody, przy założeniu że działa ona poprawnie. Trzeba się więc przygotować na niespodzianki.

Najpierw pisany jest cały test, a następnie cała implementacja – jest to kłopotliwe ponieważ: trudno jest od razu zaplanować kompletny test dla metody, po implementacji często okazuje się, że nawet jeśli jest ona poprawna i tak otrzymujemy green bar. Często z tego powodu, że pomyłka była w teście. I co wtedy, o zgrozo, się dzieje? Zmieniany jest test, a to przecież to on miał być naszą ostoją i gwarantem poprawności implementacji. Jak się za chwilę przekonamy, testy i implementację piszemy przyrostowo – po kawałku.

Pisane są zbędne testy w celu podniesienia współczynnika pokrycia – to taki przejaw instynktu samozachowawczego. Narzędzia do badania pokrycia po części wykrywają takie sytuacje. Ocenę tych praktyk pozostawiam Czytelnikowi.

Wykrycie błędów nie powoduje dodania nowego przypadku testowego – jeśli testy nie ewoluują wraz z kodem, to osłabiana jest tkwiąca w nich siła. Każdy błąd wykryty w kodzie powinien spowodować, że: zostanie dodane nowy przypadek testowy wykrywający dany błąd, a następnie implementacja zostanie poprawiona. Dodanie nowego testu zabezpiecza przed ponownym wystąpieniem danego błędu.

Test odpowiada klasie tylko z nazwy – czasami, w magiczny sposób, implementacja znacznie oddala się od testów. Dzieje się to zwłaszcza wtedy, gdy programiści nie mają nawyku rozpoczynania programowania od testu, pozornie brak czasu na testowanie, a jednocześnie w projekcie nie istnieje kontrola kodu.

Zapomina się, że testy również podlegają refaktoringowi oraz wypracowano dla nich stosowne wzorce projektowe – wiadomo, że entropia wzrasta z upływem czasu. Nic dziwnego zatem, jeśli w pewnym momencie kod klasy testującej jest tak obrzydliwy i ciężki, że wcale nie chce się go czytać. Wzorce i refaktoring testów to temat na osobny artykuł.



Filozofia TDD

Całe TDD można zamknąć w powiedzeniu: „Kapitanowi, który nie wie dokąd płynie, każdy wiatr jest na rękę”. TDD stwierdza wprost: najpierw postaw cel, a potem do niego zmierzaj – najpierw test, potem implementacja. Ma to dawać następujące korzyści: tworzony jest tylko niezbędny kod – ten który jest istotny dla osiągnięcia celu, rozwiązanie jest przemyślane, ze względu na konieczność rozpoczynania od testu, TDD wymusza dobry projekt obiektowy, gdyż testowanie kodu luźno traktującego inżynierię oprogramowania, to droga przez mękę. Dodatkowo posiadanie zestawu dobrych testów to rzecz absolutnie konieczna jeśli chce się myśleć o bezpiecznym refaktoringu kodu.
Zatem jeśli najpierw należy napisać test, to jak ma wyglądać cały proces? 
Wspomniałem wcześniej, że pisanie kompletnego testu, a następnie kompletnej implementacji nie jest dobrą praktyką. Zatem jak? Otóż, przyrostowo, spiralnie – kawałek testu, kawałek implementacji. 

Napisz fragment testu

Napisz najprostszy możliwy kod, który spełnia test

Zrefaktoruj implementację do pożądanego stanu

Czy implementacja wciąż spełnia test?

Tak: Jeśli implementacja nie zakończona idź do 1

Nie: Idź do 3




Powyżej znajduje się ramowy algorytm tworzenia oprogramowanie poprzez TDD. Warto podkreślić istotność punktu 2. Dlaczego piszemy najprostszą możliwą implementację spełniającą test? Aby przekonać się czy test jest poprawny. Dlatego właśnie pisanie kompletnego testu od razu jest niewskazane – trudno jest zweryfikować jego poprawność. 

Red-Green-Refactor: przykład Eclipse'a wzięty

Załóżmy, że tworzony jest sklep internetowy. Pierwszą funkcjonalnością, którą warto się zająć jest koszyk, z którego będzie korzystał użytkownik. Zaczniemy od odnajdywania produktów w koszyku.

Tworzę szkielet klas:
public class CartManager {
    public Product findProduct( String name ) {
        return null;
    }
}

public class Product {
    private String name;
    //...
}


Tworzę fragment testu jednostkowego jednostkowego:
public class CartManagerTest extends TestCase {
    public void testFindProduct() {
        CartManager cartManager = new CartManager();

        Product product = cartManager
            .findProduct( "myProduct" );

        assertNotNull( product );
    }    
}


Uruchamiam test:  Red Bar 

Refaktoruję implementację metody (najprostsza możliwa implmentacja!):
public Product findProduct( String name ) {
    return new Product();
}


Uruchamiam test:  Green Bar 

Rozbudowuję test:
public void testFindProduct() {
    CartManager cartManager = new CartManager();
    Product product = cartManager.findProduct( "myProduct" );
        
    assertNotNull( product );
    assertEquals( "myProduct" , product.getName() );
}


Uruchamiam test:  Red Bar 

Refaktoruję implementację metody (najprostsza możliwa implmentacja!):
public Product findProduct( String name ) {
    Product product = new Product();
    product.setName( "myProduct" );
    return product;
}


Uruchamiam test:  Green Bar 

Refaktoruję implementację klasy:
public class CartManager {
    private Map<String, Product> cartMap
         = new HashMap<String, Product>();

    public Product findProduct( String name ) {
        Product product = new Product();
        product.setName( "myProduct" );
        
        cartMap.put( "myProduct" , product );
        return cartMap.get( "myProduct" );
    }    
}


Uruchamiam test: wciąż  Green Bar 

1.Refaktoruję test:
public void testFindProduct() {
    CartManager cartManager = new CartManager();
    final String PRODUCT_NAME = "myProduct"; 
        
    Product putProduct = new Product();
    putProduct.setName( PRODUCT_NAME );
        
    Map<String, Product> cartMap
         = new HashMap<String, Product>();
    cartMap.put( PRODUCT_NAME , putProduct );
        
    cartManager.setCartMap( cartMap );
        
    Product product = cartManager.findProduct( PRODUCT_NAME );
        
    assertNotNull( product );
    assertEquals( PRODUCT_NAME , product.getName() );
}


Uruchamiam test: wciąż  Green Bar 

Dodaję do testu nową asercję:
public void testFindProduct() {    
    //...    
    assertNotNull( product );
    assertEquals( PRODUCT_NAME , product.getName() );
    assertSame( putProduct , product );
}


Uruchamiam test:  Red Bar 

Refaktoruję implementację metody:
public Product findProduct( String name ) {
    return cartMap.get( "myProduct" );
}


Uruchamiam test:  Green Bar 

1.Refaktoruję implementację metody:
public Product findProduct( String name ) {
    return cartMap.get( name );
}


Uruchamiam test:  Green Bar 


To wszystko jeśli chodzi o zasadniczą funkcjonalność wyszukiwania w koszyku. Zadanie domowe brzmi następująco: jeśli w koszuku nie ma produktu o danej nazwie metoda findProduct powinna rzucić wyjątek. Dodaj tę funcjonalność pracując zgodnie z TDD. Podpowiedź: aby wymusić red bar użyj metody fail().

Czyli...

Gdybym chciał wybrać jedną rzecz do zapamiętania z tego artykułu to powiedziałbym: kawałek testu, kawałek implementacji...


Antywzorce w pracy programistów: Wymyślanie koła na nowo
2008-07-18T09:45:00.002+02:00
Zastanawiam się czy wymyślanie koła na nowo ma sens. Ktoś napisał, że jeśli ma być ono bardziej okrągłe niż dotychczasowe to tak. Trudno odmówić sensu temu stwierdzeniu. Ja rozumiem je jako udoskonalanie istniejących rzeczy. Proces udoskonalania jest oczywiście dobry i potrzebny. Jednak podczas programowania „wymyślanie koła na nowo” nabiera czasem nowego, złowieszczego charakteru.

Większość problemów, z którymi się spotkałeś została już rozwiązana. Większość bibliotek, które opracowujesz po nocach została już napisana. Większość algorytmów, które wymyślasz w przypływie twórczego geniuszu już została opublikowana. Dlaczego więc nie korzystasz z tego bogactwa wiedzy?Napisałem „większość”, uwzględniając fakt, że „są na niebie i ziemi rzeczy, o których nie śniło się filozofom".

Jeśli Twoje, z pasją tworzone, autorskie rozwiązania mają charakter edukacyjny albo zwyczajnie robisz to dla własnej satysfakcji – tym lepiej dla Ciebie. Nauczysz się czegoś ciekawego i będziesz dobrze się bawić. Lecz jeśli pracujesz i zależy Ci na wydajności – korzystaj z dorobku innych. Pamiętaj, że ludzie po prostu kochają dzielić się swoją wiedzą i doświadczeniem. Gdyby było inaczej, nie mielibyśmy w internecie żadnej grupy dyskusyjnej.

Kłopot w tym, że większość uczelni kształcących programistów zniechęca do korzystania zewnętrznych bibliotek. No, bo po co używać JGAP w programie skoro można napisać algorytm genetyczny samemu? W ciągu pięciu lat takiej metodyki nauczania studenci nabierają dziwnych nawyków nieoptymalnej pracy, a potem przyjmując studentów do pracy musimy ich tego oduczać...ech...


Antywzorce w pracy programistów: The error is out there
2008-07-11T09:03:00.004+02:00


Wersja PDF


Coraz częściej dochodzę do wniosku, że sposób pracy programistów nie został jeszcze całkowicie zbadany. Lawina, którą zapoczątkowali Gang of Four zbiera coraz większe żniwo. Zaczęliśmy od wzorców projektowych w tworzeniu kodu, dalej już popłynęło wzorce w projektowaniu stron www, wzorce J2EE (w innych technologiach pewnie też), wzorce integracyjne, wzorce, wzorce, wzorce...

Nie sposób zauważyć, że choć odkrywanie wzorców projektowych przebiega bardzo ekspansywnie, to jednak ogranicza się on tylko do jednej płaszczyzny: umiejętności technicznych. Nietrudno odgadnąć przyczynę tego stanu rzeczy, wszak pracujemy w konkretnej technologii, za pomocą konkretnych narzędzi i biegłość w praktyce jest gwarantem naszej atrakcyjności jako profesjonalisty w zawodzie.

Pracując z programistami w trakcie szkoleń, jako zewnętrzny konsultant, czy też jako członek zespołu, zauważam, że doskonalenie naszych umiejętności i poszukiwanie wzorców powinno odbywać się w co najmniej dwóch płaszczyznach. Pierwsza – wspomniane wcześniej umiejętności techniczne – rozwija się bardzo ekspansywnie. Druga – umiejętności nietechniczne (mniejsza teraz o nazwę) – trzeba przyznać, że trochę kuleje. Nie tak dawno pisałem o tego rodzaju umiejętnościach w artykule Metaprogramy w tworzeniu oprogramowania. Od tamtej chwili rosła we mnie chęć poszukiwania dobrych praktyk programistycznych na nietechnicznym poziomie. Owa chęć nabiera kształtu w niniejszym artykule. Postanowiłem sobie tropić wzorce w pracy programistów. Ponieważ łatwiej mi najpierw zdefiniować antywzorzec, to od nich właśnie zacznę. Będę wyróżniał postawy i schematy działania, które w moim odczuciu negatywnie wpływają na pracę programisty i jeśli to możliwe będę poszukiwał remedium.

Kilka postów wcześniej pisałem o postawie roboczo nazwanej Job Security, którą z cała pewnością można można nazwać antywzorcem. Teraz czas na drugi, który pozwoliłem sobie nazwać: The error is out there.

Niełatwo zapanować na tym schematem postępowania. Gdy poszukujemy przyczyny wadliwego działania kodu, niemal zawsze przyjmowane jest milczące założenie, że przyczyną błędu jest wadliwie działający framework, lub błąd w bibliotece, lub błąd w systemie, lub błąd współpracownika, lub działanie sił wyższych. Po kilku godzinach poszukiwań okazuje się jednak, że przyczyną zamieszania była literówka. Oczywiście wszystkie z uprzednio wymienionych błędów mogą się zdarzyć, lecz najczęściej wina leży po naszej stronie. Z jakiś powodów programiści odczuwają opór przed zaakceptowaniem faktu, że to oni mogą być przyczyną swoich niepowodzeń. A spróbuj takiemu programiście powiedzieć, że to on jest przyczyną błędu! Zdarzyło mi się parę razy narobić sobie w ten sposób wrogów, więc teraz jestem ostrożny w tego typu komentarzach.
Jak zatem sobie radzić w tego typu sytuacjach? Pytanie trzeba rozbić na dwie części. Po pierwsze, jak radzić sobie jeśli komuś pomagam oraz jak radzić sobie jeśli problem dotyczy mnie samego.

W pierwszym przypadku jest dużo prościej. Tak to już jest, że szybciej dostrzegamy czyjeś błędy niż nasze własne. Jeśli chcę komuś pomóc to unikam mówienia wprost o jego błędach – to zwyczajnie nie działa. Sprawdzają się za to niedyrektywne metafory, np. „Mój kolega też miał podobny problem i...”. Buduję krótką historyjkę o „moim koledze”, w której przekazuję wskazówki odnośnie możliwych rozwiązań. Metoda sprawdza się w 90% przypadków. Pozostałe 10% albo wymaga bardziej wyrafinowanych metod albo trafiliśmy na nieuleczalny przypadek.

Sprawy stają się bardziej skomplikowane, gdy chodzi o nas samych. Kluczem do sukcesu w tej materii jest rozwijanie umiejętności introspekcji. Wyjściowym ćwiczeniem może być tu przyjęcie założenia, że „przyczyna wadliwego działania aplikacji leży po mojej stronie”. Zdaję sobie sprawę, że reguła nie sprawdza się w 100% przypadków, ale w większości tak. Przyjęcie tego wstępnego założenia znacząco oszczędza czas. Dopiero po upewnieniu się, za pomocą możliwie obiektywnych kryteriów (warto poprosić kogoś o przeanalizowanie problemu) można przystąpić do oskarżania bibliotek i  frameworków o spowodowanie kłopotów.


Iluzja O/RM
2008-07-04T16:18:00.005+02:00
Gdy po raz pierwszy dałem się uwieść wspaniałemu konceptowi O/RM, Hibernate był w wersji 2 z kawałkiem, a o JPA nawet nie słyszałem.
Idea jest naprawdę wspaniała: raz mapujesz pomiędzy tabelami a obiektami, ba (!) nawet framework stworzy schemat bazy danych za ciebie, a potem już tylko pracujesz z obiektami - programista obiektowy swoją drogą, bazodanowiec swoją. Prawdziwy raj!

We wspomnianej wersji Hibernate'a pałętało się sporo plików xml, ale wspomagając się xdocletem można było jakoś przeżyć. Weszły anotacje i miało być jeszcze prościej, wspanialej - no, słowem obiektowa orgia.

Moim zdaniem wcale nie jest tak kolorowo. Po pierwsze dlatego, że nie możliwe jest zmapowanie O/R raz na zawsze. Baza danych wciąż o sobie przypomina. A to wyskoczy jakiś constraint i trzeba pogrzebać w bazie w poszukiwaniu przyczyn (a potem okazuje się, że to jakiś błąd mapowania:]), a to model obiektowy ulega refaktoringowi albo rozbudowie i znów należy wracać do bazy danych - wciąż wracamy do bazy danych stojąc okrakiem pomiędzy obiektami i relacjami.

Kolejną kwestią jest to, że cała idea O/RM skłania do zaniedbywania bazy danych (myślimy - nie jest moją rzeczą zajmować się bazą danych, jestem programistą obiektowym...). W związku z czym baza jest projektowana niechlujne lub (o zgrozo!) pozwala się frameworkom na zarządzanie schematem. Prowadzi to tak wielkiej kaszany w bazie danych, jak wielka kaszana tylko może być: każdy obiekt ma swoją tabele, istnieje wiele tabel zawierających po kilka wierszy ("a, bo mnie tak wyszło z mapowania..."), tabele z jedną kolumną są na porządku dziennym.

Do czego to prowadzi? Ano, bywa, że O/RM mają problem z wydajnością i czasem korzystnie jest wspomóc się jakimiś procedurami składowanymi i widokami. W takim momencie okazuje się, że praca ze schematem zarządzanym przez O/R M to gorzej niż czyściec dla duszy programisty.

W pewnym momencie rozwoju J(2)EE było paru ludzi (żeby nie wymieniać nazwisk), którzy pchnęli dalszy rozwój technologii w określonym kierunku. A społeczność za tym poszła, bo wizja była fajna. Aktualnie mam na myśli idę O/RM i całą resztę kryjąca się za wzorcem Domain Store. A przecież istnieją rozwiązania, które społeczności Javy zostały zignorowane, a które świetnie się sprawdzają w innych technologiach. Mówię rozwiązaniach, które warstwę danych organizują w okół bazy danych, a nie w okół modelu obiektowego, np: Oracle BC4J albo implementacja Active Record w Ruby on Rails

O faworyzowaniu pewnych rozwiązań świadczy choćby fakt, że do tej pory nie doczekaliśmy się popularnej i w pełni funkcjonalnej implementacji Active Record dla Javy. Myślę, że mogło by to wnieść wiele dobrego do aplikacji, które rozwijamy.


Wzorzec Job Security
2008-06-25T20:48:00.004+02:00
Prowadząc szkolenia z refaktoringu, coraz częściej natykam się na pewien specyficzny schemat zachowania. Schemat, który napawa mnie przerażeniem i kładzie cień na moich programistycznych ideałach. A było to tak...

Wykładałem pracowicie cel refaktoringu, konkretne techniki właściwe dla poszczególnych warstw i technologii i...nic jak grochem o ścianę - wszyscy uparcie twierdzili, że ich manager w życiu nie zgodzi się na poświęcenie choćby chwili na refaktoring. Przeszedłem więc do broni masowego rażenia - korzyści płynące ze stosowania refaktoringu:

Kod jest łatwiejszy w czytaniu

Łatwiej jest dokładać nowe funkcjonalności

Wdrożenie nowej osoby do projektu zajmuje mniej czasu

Testowanie kodu jest łatwiejsze

Odnajdywanie błędów trwa krócej

Rozbudowywanie projektu zajmuje mniej czasu


A zatem, argumentowałem, potencjalnie zyskujemy najcenniejszy zasób: czas. A czas to, jak wiadomo, pieniądz! Zatem manager musi zgodzić się na rozprzestrzenianie praktyki refaktoringu...

Słuchaj, Michał - powiedział jeden z uczestników szkolenia - jeśli napiszę w czasie krótszym niż mój manager to oszacował to dostanę kolejny projekt. Dodatkowo na projekt zostanie przydzielone mniej czasu, bo już pokazałem, że potrafię pracować efektywniej. I tak z każdym kolejnym projektem mój manager wyciśnie ze mnie wszystkie soki. Jeśli dostanę 10 dni na skończenie projektu, to choćbym wyrobił się w 3, nigdy się do tego nie przyznam. Nie opłaca mi się. Poza tym, mam płacone za każdą nadgodzinę. Im dłużej pracuję, tym więcej zarabiam.
Powiedziałeś, że łatwiej jest wdrażać nowe osoby do projektu. Też mi korzyść! A jeśli nowy będzie lepszy ode mnie? Wtedy ja wylecę z roboty. Piszę mój kod tak, żebym tylko ja mógł go zrozumieć. Być może praca z JSP liczącym 2000 wierszy nie jest zbyt wygodna, ale przynajmniej wiem, że będę potrzebny. Wiem, że będę miał pracę. Refaktoring jest mi zbędny.

Szczerze mówiąc nie wiedziałem co odpowiedzieć na takie dictum...Myślałem, że gdy podzielę się tą historią, to będzie mi lepiej. Nie jest ;/


Metaprogramy w tworzeniu oprogramowania
2008-06-24T19:52:00.010+02:00


Wersja PDF


Jeśli jesteś programistą albo w jakikolwiek inny sposób związany z branżą IT, to najprawdopodobniej po przeczytaniu tytułu, spodziewałeś się  porcji informacji technicznych. Muszę Cię zaskoczyć, artykuł będzie o innych programach i o innym programowaniu niż sobie wyobrażasz. 

 Ludzie posługują się swoimi myślami w zorganizowany sposób. Dzieje się to często na poziomie nieświadomym. Gdy o czymś myślimy, w umyśle pojawiają się różnego rodzaju obrazy, odczucia czy dźwięki. Choć nie zawsze zdajemy sobie z tego sprawę, w ten właśnie sposób przetwarzamy informacje docierające z zewnątrz (i z wewnątrz). 

 Psycholingwistyce zawdzięczamy badania nad tą wewnętrzną organizacją codziennych doświadczeń. Okazuje się, że można wyróżnić pewne schematy, że ludzie posługują się pewnymi wzorcami zachowań, które nazwano metaprogramami. Metaprogramy zostały pogrupowane w przeciwstawne, uzupełniające się pary scenariuszy w następujący sposób:

Unikanie – Dążenie

Autorytet wewnętrzny – Autorytet zewnętrzny

Podobieństwa – Różnice

Ja – Inni

Informacje szczegółowe – Informacje globalne

Proaktywne – Reaktywne

Opcje – Procedury


Dla osoby skoncentrowanej na unikaniu, bodźcem do działania będzie chęć uniknięcia niepożądanych sytuacji. Przeciwnie, dla osoby posługującej się metaprogramem Dążenie, ważniejsze będzie osiągnięcie wyznaczonego celu. Czytelników zainteresowanych dokładnym poznaniem metaprogramów odsyłam do literatury.
Preferowane metaprogramy

 W praktyce nigdy nie jest tak, aby dany scenariusz np. Unikanie występował w czystej formie. Jest tak przede wszystkim dlatego, że procesy myślowe są w swej naturze zbyt skomplikowane (i jeszcze wiele jest do odkrycia), by opisać je za pomocą tak prostego modelu jakim są metaprogramy. Koncept metaprogramów należy traktować zatem jako pewne przybliżenie rzeczywistości o ograniczonym zakresie stosowalności.

 Używanie metaprogramu jest zależne od kontekstu (kontekstualizm), środowiska w którym znajduje się człowiek. Ktoś na co dzień skoncentrowany na Dążeniu może radykalnie zmienić sposób myślenia, gdy ucieka przed goniącym go psem – wtedy najprawdopodobniej skupi się na uniknięciu niebezpieczeństwa, bez znaczenia w jaki sposób.

 Bardzo istotne jest to, że metaprogramy nie podlegają ewaluacji. Żaden z nich nie jest lepszy lub gorszy – są inne. Jedyne co można powiedzieć to, że dany scenariusz może być mniej lub bardziej użyteczny w określonej sytuacji. Zadaniem artykułu jest, przede wszystkim, pobudzenie do refleksji nad własnym stylem pracy.

 Choć obserwując zachowania ludzi, można wskazać pewne przejawy każdego z metaprogramów to jednak poszczególne osoby mają osobiste preferencje. Najczęściej 1 do 3 metaprogramów dominuje, pozostałe pojawiają się sporadycznie. W dalszej części zastanowimy się, które z metaprogramów są najistotniejsze w pracy programisty.
Zbieranie wymagań

 Zbieranie wymagań oraz modelowanie systemu są czynnościami o tyle ważnymi, że kierunkują dalsze prace zespołu. Prace nad projektem rozpoczynają się (powinny się rozpoczynać) od stworzenia jego wizji. Wizja, w postaci metafory, jest metacelem, do którego zmierzać będzie projekt w kolejnych fazach rozwoju. Dalej wyłania się zbiór wymagań, zestaw procesów, w których może brać udział użytkownik. Pojawia luźny koncept rozwiązania i będzie uszczegóławiany w dalszych krokach. 

 W opisanym wyżej procesie projektowania zauważamy, że prace odbywają się na poziomie ogólnym. Programiści/projektanci wykazują w tym miejscu tendencję do skupiania się na konkretnym rozwiązaniu. Podczas rozmowy z potencjalnym użytkownikiem, od którego należy zebrać wymagania, deweloper stara się podążać za tokiem myślowym rozmówcy. Jednocześnie zastanawia się, czy i jak konkretne wymaganie zostanie zrealizowane. Myślenie o rozwiązaniu jest jak najbardziej w porządku tyle, że nie na to jest miejsce podczas zbierania wymagań, gdy należy się skoncentrować na zrozumieniu wyobrażeń użytkownika o sposobie pracy z przyszłym narzędziem. Z tego względu zbieranie wymagań warto przeprowadzać w sesjach, np.: godzinę rozmowy z użytkownikiem, a następnie pół godziny na analizę wymagań i formułowanie dodatkowych pytań. 

 W artykule Klient, który wie, czego chce rozważałem różnice w sposobie myślenia analityka i klienta. Głównym wnioskiem było to, że klienci jednak wiedzą, czego chcą. Opisują to jednak w postaci procesów, natomiast analityk widzi system jako strukturę. Podążając za procesem łatwiej dokonywać w nim zmian. Z kolei zmiany wprowadzane w strukturze wymagają przeanalizowania całej koncepcji od nowa. Podczas zbierania wymagań klient często zastanawia się nad pożądanym sposobem pracy. Próbuje różnych alternatywnych przebiegów tego samego procesu i oczekuje od analityka pomocy w wyborze najlepszego rozwiązania. Jeśli analityk nie podąża w procesie za klientem, lecz percypuje system jako strukturę, to ma nie lada kłopot. Alternatywne ścieżki procesu klienta zazwyczaj mają istotny wpływ na domniemaną strukturę systemu i/lub implementację. 

 Dochodzimy do kolejnego, istotnego w pracy programisty, metaprogramu: Opcje – Procedury. Najczęściej klient chce próbować różnych możliwości – jest nastawiony na opcje. Analityk powinien wyjść naprzeciw tym oczekiwaniom. Należy przypomnieć fakt, że nastawienie na opcje może nie być głównym metaprogramem klienta. Jednak w kontekście zbierania wymagań, gdy zastanawia się on nad sposobem pracy z narzędziem i analizuje różne procesy, najczęściej chce mieć możliwość wybrania najlepszego rozwiązania spośród dostępnych.

 Podsumowując część o zbieraniu wymagań stwierdzamy, że w tym kontekście pracy programisty ważne jest nastawienie na Ogół oraz na Opcje. Te sposoby myślenia pozwalają pozostać na odpowiednim poziomie abstrakcji i skupić się na wizji i celu istnienia systemu zamiast brnąć w konkretne technologie i rozwiązania tylko po to, aby w następstwie późniejszych decyzji w pośpiechu się z nich wycofywać.
Programowanie

 Po zebraniu wymagań i zaplanowaniu prac przychodzi czas na implementację. W chwili obecnej role projektanta oraz programisty przenikają w projekcie. Myślę, że to dobrze, gdyż można w pełni wykorzystać potencjał tkwiący w programistach. W tej sytuacji deweloperzy dostają pewne wytyczne z projektem systemu i mają dość dużą dowolność w implementowaniu poszczególnych klas oraz metod.

 Implementacja złożonego systemu informatycznego, gdzie współpracuje ze sobą wiele niezależnych bytów, jest skomplikowanym zadaniem. Na tym etapie programujemy już konkretne zachowania i procesy. Od programisty oczekujemy, że będzie potrafił uzasadnić wybór tego, a nie innego rozwiązania. Dodatkowo należy przestrzegać obowiązujących w zespole konwencji kodowania, zasad projektowania, wytycznych pisania testów, itp. Nie ma tu miejsca na swobodną twórczość albo raczej ma ona miejsce drugorzędne. Ważniejsze jest przestrzeganie określonych zasad – procedur. Ujawnia się nam  kolejny scenariusz pomocny programiście: Procedury. Osoba, sprawnie posługująca się procedurami, rozważa rzeczywistość jako ciąg logicznych następstw, gdzie każde zdarzenie ma swoją przyczynę oraz konsekwencje. Intuicyjnie czujemy, że Procedury to jeden największych sprzymierzeńców programistów. Możemy być dumni z faktu, że wykorzystujemy metaprogram do tworzenia wspaniałego oprogramowania.

 Warto jeszcze poruszyć jeszcze jeden aspekt programowania, istotny w kontekście rozważania metaprogramów. Mowa o abstrahowaniu. Języki obiektowe dają sposobność budowania złożonych zależności pomiędzy klasami dzięki np. dziedziczeniu, polimorfizmowi, interfejsom. Możliwości te, aż same zachęcają do ich korzystania. Istota kwestii leży w sposobie korzystania z tych udogodnień. Gdy programista implementuje daną funkcjonalność ma tendencję do tworzenia całej gamy abstrakcyjnych bytów „na wyrost”. Efekt jest taki, że w projekcie każda klasa implementuje specyficzny interfejs (nie używany nigdzie indziej) oraz posiada, do niczego nie potrzebną, klasę abstrakcyjną. Z kolei podczas używania danych klas i tak wszędzie następuje rzutowanie na obiekty konkretne. Przyczyną takiego tworzenia kodu jest „zachłyśnięcie się” paradygmatem reużywalności i elastyczności komponentów. Oczywiście paradygmat ten jest jak najbardziej słuszny, lecz sposób jego egzekwowania już nie. Błąd programisty polega na próbie zaprojektowanie stworzenia maksymalnie rozszerzalnego kodu i „zapomina” że każde rozwiązanie ma ściśle określone granice stosowalności. Programista próbuje stworzyć komponenty możliwe do zastosowania wszędzie (Golden Hammer). Popatrzmy na poniższy kod:


public interface Problem {
 //...
}
public interface Solution {
 //...
}
public interface UniversalProblemSolver {
 public Solution solve( Problem problem );
}


Właściwie każda klasa mogłaby implementować interfejs UniversalProblemSolver, prawda? Gdy tworzymy kod, który ma dostarczać określoną funkcjonalność i koncentrujemy się przede wszystkim na jego uniwersalności, zamiast na konkretnym zadaniu które ma wykonać, popadamy w opisaną wyżej pułapkę. W takiej sytuacji myślimy poprzez Ogół i tworząc abstrakcyjne byty, zmierzamy do celu wyjątkowo krętą ścieżką.

 Optymalne programowanie wymaga podejścia od strony Szczegółu. Najpierw tworzymy konkretne rozwiązanie implementujące żądaną funkcjonalność. Jeśli w trakcie tworzenia kodu zajdzie potrzeba abstrahowania: wydzielenia hierarchii dziedziczenia, interfejsów – refaktorujemy kod. Praca odbywa się zatem od Szczegółu do Ogółu – w odwrotnym kierunku niż w przypadku zbierania wymagań i modelowania systemu. Ten styl programowania wymaga od deweloperów wewnętrznej samodyscypliny. Warto skorzystać z technik programowania np. Test-Driven Development, które wspomagają ten styl pracy. TDD, dzięki filozofii pisania testu funkcjonalności przed jej implementacją, zabezpiecza przed nadmiarowym „rozdmuchiwaniem” klas i dokładaniem kodu, być może użytecznego, lecz zbędnego z punktu widzenia tworzonego systemu.

Przenoszenie metaprogramów

 Powyżej wyróżniłem dwa konteksty pracy programisty, w których pożądane jest posługiwanie się odmiennymi scenariuszami metaprogramów Ogół – Szczegół oraz Opcje – Procedury. Ta właśnie potrzeba przełączania się pomiędzy różnymi scenariuszami rodzi wiele kłopotów i frustracji. Jest tak przeważnie dla tego, że „uruchamianie” odpowiedniego metaprogramu odbywa się w sposób nieświadomy. Drugą przyczyną, jak na ironię, jest zdolność do uczenia się. Przypuśćmy, że ktoś uczy się programowania. Po jakimś czasie wykształca sobie pewien sposób myślenia i sprawnie posługuje się scenariuszami Procedury oraz Szczegół. W umyśle człowieka rodzi się skrót myślowy: jeśli TO zadziałało w TYM przypadku, z pewnością zadziała również w TAMTYM. Ów człowiek, za pomocą metaprogramu, dobrze działającego w jednym kontekście (praca) próbuje wykonywać działanie w zupełnie innym kontekście (np. relacje międzyludzkie). To zjawisko może prowadzić do niepożądanych skutków. Praca nad własnymi metaprogramami uwrażliwia nas na podobne sytuacje i uczy efektywnego funkcjonowania w różnych kontekstach.

Korzyści

 Najważniejszą, moim zdaniem, korzyścią ze znajomości i rozwijania określonych metaprogramów jest rozszerzenie spektrum możliwych reakcji na sytuacje pojawiające się podczas prac nad projektem. Umiejętność posługiwania sposobami myślenia innymi niż nasze własne sprawia, że efektywniej współpracujemy z klientami, użytkownikami oraz z innymi członkami zespołu. Poniżej wymieniam dodatkowe korzyści:

pomoc w formowaniu zespołu projektowego

wyznacznik dla osób rekrutujących programistów

skrócenie czasu zbierania wymagań

poprawa komunikacji w zespole

pomoc podczas projektowania ścieżki rozwoju dla programistów



Podsumowanie

 W artykule wyróżniłem metaprogramy Ogół – Szczegół oraz Opcje – Procedury jako bardzo istotne w pracy programisty. Zdaję sobie sprawę, że istnieje wiele punktów w procesie rozwoju oprogramowania, które nie zostały tu wspomniane. W obszarach tych również korzystamy ze specyficznych metaprogramów i wiedza o nich będzie nieocenioną pomocą. Dalszą eksplorację tego zagadnienia rezerwuję sobie na najbliższą przyszłość. Warto wskazać czego potrzeba opracowaniu tego typu, aby stanowiło rzetelną pomoc w pracy dewelopera:

kompletny opis procesu wytwarzania oprogramowania z punktu widzenia wykorzystywanych metaprogramów,

opis efektywnych technik pracy na każdym z etapów,

zestaw ćwiczeń pozwalających rozwijać pożądane metaprogramy.


 Każdy krok w kierunku rozwoju własnego warsztatu pracy uświadamia, że istnieje coś poza technologią, coś co porządkuje poszczególne umiejętności i pozwala korzystać z ich jeszcze efektywniej. Odkrywanie tych zasobów jest fascynującą podróżą ku doskonałości.


Strategie decouplingu
2008-06-13T01:39:00.012+02:00


Wersja PDF


 W inżynierii oprogramowania występuje masowe dążenie do tworzenia systemów informatycznych z komponentów wielokrotnego użytku. Komponenty te mogą występować na różnym poziomie abstrakcji oraz złożoność. Artykuł poświęcony jest komponentom najniższego poziomu jakimi są klasy oraz ich obiekty.

Swobodna twórczość

O co właściwie chodzi z tym całym decouplingiem1? W gruncie rzeczy o przejrzystość, elastyczność i elegancję kodu. Wyobraźmy sobie następującą sytuację:

Pewien interfejs, SecurityManager, jest odpowiedzialny za zrealizowanie operacji autentykacji oraz autoryzacji. Po krótkiej analizie stwierdzamy, że chociaż przeprowadzenie operacji autentykacji należy do interfejsu SecurityManager, to już sama czynność sięgnięcia do bazy danych w celu pobrania potrzebnych informacji leży poza tą odpowiedzialnością. Na diagramie widać, że działania na bazie danych delegowane są do pomocniczego interfejsu UserCredentialsDAO.
Pojęcie decouplingu dotyczy powiązań pomiędzy poszczególnymi klasami/interfejsami w systemie, np.: powiązania pomiędzy implementacjami interfejsów SecurityManager i UserCredentialsDAO. Jak zatem zapewnić to powiązanie? Najprostszym możliwym sposobem – w konstruktorze.


public class JdbcSecurityManager implements SecurityManager {

  public UserCredentialsDAO userCredentialsDAO;

  public JdbcSecurityManager() {

      userCredentialsDAO = new JdbcUserCredentialsDAO();

}


Szybko jednak okazuje się, że dana klasa wymaga więcej zależności, aby wykonać swoje zadanie. Dodatkowo chcemy mieć możliwość decydowania, które konkretne implementacje klas zależnych zostaną dostarczone do obiektu. W takim przypadku można zastosować parametryzowane konstruktory.

public class JdbcSecurityManager implements SecurityManager {

  public UserCredentialsDAO userCredentialsDAO;
 
  public SecurityHolder securityHolder;
 
  public JdbcSecurityManager( UserCredentialsDAO credentialsDAO, 
    SecurityHolder securityHolder ) {

    this.userCredentialsDAO = credentialsDAO;
    this.securityHolder = securityHolder;
}



Rozwiązanie to sprawia kłopot, gdy pisane są testy jednostkowe wykorzystujące klasę JdbcSecurityManager lub jej mocka. Niedogodność polega na tym, że czasem , teście jednostkowym chcemy mieć możliwość podmiany  implementacji interfejsów UserCredentialsDAO oraz SecurityHolder. Z tego względu warto do tworzonej klasy , prócz parametryzowan/ch konstruktorów dodać również konstruktor domyślny oraz setery i getery do odpowiednich pól. W klasie wykorzystującej interfejs SecurityManager można wstawić następujący kod:


UserCredentialsDAO credentialsDAO = new JdbcUserCredentialsDAO();
SecurityHolder securityHolder = new SecurityHolder();

JdbcSecurityManager securityManager = new JdbcSecurityManager();
securityManager.setUserCredentialsDAO( credentialsDAO );
securityManager.setSecurityHolder( securityHolder );



Stosując opisaną powyżej strategię zapewniamy utworzenie powiązań pomiędzy obiektami w systemie. Jednocześnie sprawiamy, że obiekty są silnie uzależnione od siebie. Jest tak dlatego, że instancje poszczególnych klas są tworzone w kodzie – klasa nadrzędna tworzy instancje klas z nią współpracujących. O klasach, w których powiązania między nimi są realizowane w ten sposób mówimy, że są coupled. Konsekwencją takiego podejścia jest to, że jakakolwiek podmiana poszczególnych implementacji wiąże się z ingerencją w kod źródłowy. Taki kod jest nieelastyczny oraz trudny w utrzymaniu i rozwoju.

Przeciwwagą kodu, w którym klasy są coupled, jest kod w którym są one decoupled, to znaczy w maksymalnym stopniu od siebie niezależne. Współpracują ze sobą, ale można w łatwy sposób wymieniać poszczególne implementacje, a ingerencja w projekt jest ograniczona do minimum. Czynność zapewniania takiego stanu rzeczy nazywa się decoupling (lub po lekkim spolszczeniu decouplingiem) i jest przedmiotem niniejszego artykułu.

Fabryka

Ponownie odwołując się do pojęcia odpowiedzialności obiektów można zapytać, czy tworzenie nowych obiektów należy do odpowiedzialności klasy JdbcSecurityManager? Nie, gdyż jej zadaniem jest przeprowadzać operacje związane z bezpieczeństwem. Obiekt tej klasy nie może wykonywać swoich działań gdy nie ma obiektów pomocniczych, do których deleguje odpowiednie operacje. Remedium przychodzi w postaci scentralizowanego miejsca, w którym tworzone będą obiekty używane w systemie. Można zaimplementować  to rozwiązanie w postaci wzorca SimpleFactory.


public final class ObjectFactory {
  public static SecurityManager createSecurityManager( 
    String type ) {

    SecurityManager securityManager = //...  
    return securityManager;
  }
  public static UserCredentialsDAO createUserCredentialsDAO( 
    String type ) {
  //... 
  }
}



Metody fabryki muszą zdecydować, w jaki sposób należy zbudować dany obiekt, np. którą implementację należy utworzyć. Decyzja zostanie podjęta na podstawie parametru type metod fabryki.


public class BankTransferManager {
  private SecurityManager securityManager;

  public BankTransferManager() {
    securityManager = ObjectFactory.createSecurityManager(                                                             
      "securityManager" );
  } 
}


W powyższym rozwiązaniu tworzenie klas i powiązań pomiędzy nimi zostało oddelegowane do osobnego obiektu  fabryki. Dzięki temu nie klasa decyduje o użytych implementacjach lecz fabryka. Rozwiązanie zapewnia decoupling kodu, gdyż konkretne klasy nie są ze sobą trwale związane (np. poprzez tworzenie zależności w konstruktorach), zatem można w dowolnym momencie podmieniać implementacje modyfikując odpowiednio działanie klasy ObjectFactory. Oczywiście ingerencja w kod jest nieodzowna, lecz dotyczy tylko jednego obiektu, nie wszystkich.

Singleton

Czasem zachodzi konieczność, aby dany obiekt występował tylko raz w systemie, np. SecurityManager jeśli nie chcemy, próba autentykacji użytkownika była podejmowana przez dwa byty. 
Może być też tak, że nie ma sensu tworzyć wielu bezstanowych obiektów zajmujących się tylko logiką, np. UserCredentialsDAO, gdyż w zupełności wystarczy tylko jeden. 
W powyższych wypadkach stosuje się wzorzec Singleton, aby zapewnić, że dany obiekt zostanie utworzony tylko raz. Poniżej znajduje się przykładowa implementacja Singletonu.


public class LdapSecurityManager implements SecurityManager {

  private static LdapSecurityManager instance;
 
  private static LdapSecurityManager getInstance() {
    if ( instance == null ) {
      instance = new LdapSecurityManager();
    }
      return instance;
    }
} 


Klasa ObjectFactory musi skorzystać z metod getInstance() do pobrania obiektu. Jeśli singleton ma być używany w aplikacji wielowątkowej musi być thread-safe. Za Williamem Pughem podaję taką implementację:


public class LdapSecurityManager implements SecurityManager {
 
  private static class SingletonHolder {
    private final static LdapSecurityManager instance
      = new LdapSecurityManager();
  }

  private static LdapSecurityManager getInstance() {
    return SingletonHolder.instance;
  }
}


Należy pamiętać, że jeśli system działa na wielu maszynach wirtualnych, to klasa singletonu będzie ładowana na każdej z nich. Z tego względu zaleca się unikać tego rozwiązania w systemach rozproszonych.

Service Locator

Uogólnieniem ObjectFactory jest wzorzec Service Locator, którego zadaniem jest dostarczenie klientowi żądanej klasy usługowej, z tą różnicą, że klient nie wie skąd pochodzi dana usługa – czy jest lokalna, czy też zdalna.

Kontekst aplikacji

Alternatywą dla ObjectFactory jest zastosowanie obiektu, w którym przechowywany jest tzw. kontekst aplikacji. Kontekst zawiera w sobie wszystko to, czego system potrzebuje do poprawnego działania, np. obiekty realizujące konkretne usługi.


public class LdapSecurityManager implements SecurityManager {

  public void authenticate( UserCredentials credentials,
    AppContext context ) {

    UserCredentialsDAO credentialsDAO
      = context.get( "userCredentialsDAO" );
  }
}


Każda metoda, w której potrzeba użyć usługi przechowywanej w kontekście będzie przyjmować dodatkowy parametr – AppContext, który umożliwia pobranie potrzebnego obiektu. Oczywiście podczas startu aplikacji należy najpierw zbudować odpowiedni kontekst.

Kiedy zatem używać obiektu kontekstu, a kiedy fabryki? Obiekt kontekstu umożliwia przechowywanie aktualnego stanu aplikacji do którego powinny mieć dostęp wszystkie obiekty (przechowywanie stanu w zewnętrznym obiekcie dostępnym poprzez metody statyczne jest mało eleganckie i nieintuicyjne). Fabryka skupia się tylko na tworzeniu obiektów. Konkretny wybór zależy o bieżących potrzeb. Kontekst, podobnie jak fabryka, zapewnia decoupling obiektów.

Dependency Injection

Konsekwencją stosowania zarówno fabryki jak i kontekstu aplikacji jest sytuacja, w której dana klasa musi zażądać obiektów pomocniczych, których chce użyć, od fabryki lub pobrać je z kontekstu aplikacji. Zatem dany obiekt dba o to, aby odnaleźć potrzebne mu obiekty współpracujące za pomocą fabryki, lokatora lub konktestu. Obiekt dba o swoje zależności. 

Przeformułujmy problem w następujący sposób: żądamy takiej architektury aplikacji, w której dostarczony zostanie nam obiekt gotowy do użycia z już rozwiązanymi zależnościami. Takie podejście nosi nazwę Dependency Injection. Obiekty są zarządzane przez tzw. kontener. Przed użyciem należy zdefiniować obiekty oraz powiązania pomiędzy nimi, a następnie pobierać obiekty z kontenera i używać ich w systemie.



Na rysunku widać schemat Dependency Injection. Wszystkie obiekty oraz ich wzajemne relacje zdefiniowane są w zewnętrznym pliku XML, np:


<bean id="userCredentialsDAO" 
  class="mbartyzel.decoupling.JdbcUserCredentialsDAO" />
<bean id="securityManager" 
  class="mbartyzel.decoupling.JdbcSecurityManager">
 <property name="credentialsDAO" ref="userCredentialsDAO" />
</bean>

Natomiast w systemie pobierane są obiekty z kontenera:

SecurityManager securitManager = BeanFactoryHolder
  .getBean( "securityManager" );


Przykłady frameworków dostarczających kontenera DI to np.: SpringFramework, PicoContainer, Google-Guice.

Aby kod aplikacji był decoupled od frameworka oczekujemy, aby nie narzucał zarządzanym przez siebie obiektom implementowania specyficznych interfejsów. Gdyby tak było, kod stałby się zbyt zależny od samego framewokra. Niemożliwa byłaby wtedy sprawna zamiana jednego kontenera na inny, a testowanie utrudnione.

Podsumowanie

W artykule omówione zostały strategie decouplingu w systemach informatycznych takie jak: fabryka, Service Locator, kontekst aplikacji, kontener Dependency Injection. Autor ma nadzieje, że podane przykłady implementacji pozwolą Czytelnikom poprawić jakość tworzonego kodu. Nadrzędnym celem było wskazanie kilku możliwości osiągnięcia tego samego efektu. Mając wybór możemy, w danej sytuacji,  świadomie decydować o przewadze jednego rozwiązania nad innym. Pamiętajmy, że jeśli jednym dostępnym narzędziem jest młotek, wszystko zaczyna wyglądać jak gwóźdź...


Historia jednego JUGa
2008-06-11T15:18:00.001+02:00
Czasem tworzysz coś planowo, czasem coś zwyczajnie się dzieje, lub też planujesz a i tak rzeczy biegną swoim torem. Nie inaczej był z JUGiem łódzkim.
 Ubolewaliśmy z Mariuszem, że wcześniejsze plany nie pozwolą nam zjawić się ja Javarsovi. W pewnym momencie zaczęła się dyskusja o starych pomysłach utworzenia w Łodzi jakiejś javowej społeczności. No, więc szukamy w necie, szukamy i nic. Wyobrażacie sobie?!? Łódź - ponad milion ludzi, centra akademickie, kilka poważnych firmy developerskich, a lokalnej społeczności Java ani widu ani słychu. 
 Nieśmiało założyłem grupę na gmail, wysławszy następnie info na JDN. Następnego dołączył Tomek i wrzucił pierwsze logo, porozmawialiśmy trochę pogratulowaliśmy sobie powstania JUGa i tyle. Potem pojawił Bartek ze swoim zapasem niekończącej się energii:). Długo rozmawialiśmy na GG, Bartek jednocześnie spamował :) do JackaL z WawaJUG z prośbą o podzielenie się doświadczeniami. Na koniec dnia mieliśmy dość mglistą wizję: Co, gdzie, kiedy i jak...
 Szczerze mówiąc potem już straciłem nad tym, kto kiedy dołączył i co powiedział. Jakoś tak z niczego pojawiły się logo, zjawili się studenci z PŁ z propozycją udostępnienia sal, koledzy z innych JUGów aktywnie właczyli się do dyskusji...mój Thunderbird pracował jak oszalały.
 Spotkaliśmy się w sobotę 7 czerwca by proklamować powstanie łódzkiego JUGa. Doszliśmy do wniosku, że przez wakacje będziemy testować działanie społeczności, aby pełną parą ruszyć we wrześniu/październiku.
Pierwsze spotkanie odbędzie się już za miesiąc 5 lipca i poruszać się będziemy wokół EJB3.
 Mam nadzieję, że entuzjazm i energia zostaną utrzymane na długo, a rodząca się społeczność jest zaczątkiem czegoś wielkiego.



Klient, który wie, czego chce
2008-05-27T00:44:00.003+02:00

Wersja PDF

 Powszechnie przyjętym dogmatem wśród analityków, projektantów, architektów, deweloperów i innych osób biorących udział w cyklu wytwarzania oprogramowania jest, że Klient nie wie czego chce. Sytuację rodem z głuchego telefonu przedstawia rysunek (http://philhord.com/phord/wp-content/development.jpg), w którym klient opisuje swoje oczekiwania. Następnie trafiają one do poszczególnych osób zajmujących się tworzeniem systemu i w efekcie biedny klient dostaje coś, co drastycznie mija się z jego potrzebami.  
  Jak to zatem jest z owym klientem? Czy rzeczywiście nie ma on bladego pojęcia czego naprawdę chce? Jak wiadomo: punkt widzenia zależy od punktu siedzenia. Programiści wiedzą, że klient nie ma bladego pojęcia o swoich potrzebach, natomiast klienci są absolutnie przekonani, że deweloperzy dają im coś innego niż zostało to uzgodnione. Jaka jest więc prawda? Hmmm, żyję na świecie wystarczająco długo, by wiedzieć że każdy ma swoją własną prawdę. Jednakże twierdzę, że klient dokładnie wie, czego chce. Z doświadczenia wiem, że:
 Klient  wie, czego chce  – aktualne oczekiwania wobec systemu wyniknęły z problemów,  które doskwierają klientowi w pracy, zatem chce on je  rozwiązać i ma na to konkretny pomysł. Klient (metaforycznie  rzecz ujmując) jest ekspertem z dziedziny problemu, więc tym  bardziej wie, czego chce.
  
Klient  nie zawsze wie, czego potrzebuje  – wynika to z jego niewielkiej wiedzy o możliwych technologiach.  Często klient sugeruje rozwiązanie (na miarę swojej wiedzy), gdy  tym czasem powinien zatrzymać się na sformułowaniu problemu i  oczekiwanych rezultatów.
  
Klient  często nie uświadamia sobie konsekwencji własnych oczekiwań  – jest to bolesne zwłaszcza, gdy prosi się nas o dodatkową  funkcjonalność w systemie. 

 
Przyczyna rozmijania się oczekiwań klient z rezultatem prac programistów koncentruje się wokół następujących faktów:
 Klient  myśli procesowo  – ma bardzo konkretne pomysły na sposób pracy z systemem.  Potrafi określić warunki początkowe dla danego procesu oraz  określić jego rezultat.
  
Projektant  myśli strukturalnie  – porusza się w przestrzeni baz danych, tabel, klas, obiektów.  Niejednokrotnie już podczas rozmowy z klientem myśli o  implementacji. Z tego względu częste zmiany w wymaganiach oraz  modyfikacje sposobów pracy z systemem, które klientowi  przychodzą niezwykle łatwo, u projektanta powodują frustrację.
 
 
 Mit o niewiedzy klienta nt. własnych oczekiwań bierze się powyższych różnić w myśleniu i analizowaniu informacji.
 W swojej pracy wykorzystuję następujące praktyki pomagające w ustaleniu potrzeb klienta:
 Opisywanie  cyklu pracy z systemem –  tworzę zestaw procesów, które opisują co użytkownik  może zrobić w systemie. Jeden proces to jedna konkretna rzecz,  np.: wykonanie przelewu, zalogowanie, wygenerowanie raportu
  
Rysowanie  z klientem ekrany systemu i zaznaczanie przepływu sterowania pomiędzy  nimi – puryści mówią,  że tym powinien zajmować się projektant UI, natomiast do  definiowania wymagań służą UML  use cases. Cóż , nie spotkałem jeszcze klienta, który miałby ochotę uczyć  się nowych symboli (nawet jeśli jest ich kilka), aby definiować  swoje wymagania. Klient doświadcza systemu poprzez to co widzi –  ekrany.   
  
Pilnowanie,  aby klient precyzował jaki efekt chce uzyskać  – klient jest od tego, aby wskazać problem i określić  oczekiwane rezultaty. Od rozwiązywania zadania jestem ja. Dobrze  jeśli klient może udzielić rad odnośnie implementacji, jednak  niekontrolowane mieszanie się tych odpowiedzialności nie raz  zapędziło mnie w kozi róg.
  
Skłanianie  klienta do przewidywania konsekwencji swoich oczekiwań – duże  korzyści przynosi to przy rozbudowanych systemach. Niestety klient  patrzy lokalnie na system – skupia się na aktualnym problemie i  nie ma wizji całości. Prowadzi to łatania dziur, dodawania  funkcyjnie zależnych od siebie usług do systemu i ogólnego  bałaganu. Prowokowanie klienta do globalnego spojrzenia na system i  przewidywania globalnych konsekwencji swoich oczekiwań ma  następujące zalety:
 
    ulepszany system jest traktowany jako całość
   
   unika się dublowania funkcjonalności
   
   czasem okazuje się, że poprawa komfortu pracy o 5% nie jest   warta wysiłku programistów
  
 



Ewolucja Agile
2008-05-19T10:00:00.003+02:00

Wersja PDF

 Metodyki z nurtu Agile nazywane są ostatnio nowoczesnym podejściem do programowania. Zdobywają one coraz większą popularność dzięki swojej skuteczności i przestępności dla klienta. W tym artykule chciałbym zastanowić się, czy podejście Agile jest tym oczekiwanym, „prawie idealnym”, sposobem na wytwarzanie oprogramowania.
 Lekkie podejście do programowania
  W odległej historii branży IT, projektanci oprogramowania zmęczeni wymogami popularnych wówczas metodyk prowadzenia projektów programistycznych, postanowili pozbyć się ciążącego balastu przeszłości. Doszli do wniosku, że wytwarzanie oprogramowania powinno przebiegać szybciej, płynniej, efektywniej, że powinno być bardziej otwarte na klienta i, co za tym idzie,  na zmianę jego oczekiwań. Słowem: nowa metodyka powinna w optymalny sposób zmierzać do usatysfakcjonowania sponsora projektu, użytkownika i programistów. Efektem tych przemyśleć był Manifest Agile.
  W metodykach z nurtu Agile (np.: eXtreme Programming, Scrum) oprogramowanie tworzy się przyrostowo. W krótkich iteracjach implementuje się kolejne funkcjonalności systemu. Użytkownik, przynajmniej w założeniu, jest cały czas dostępny i może podjąć wiążące decyzje dotyczące kierunku rozwoju projektu.
  Lekkie metodyki są ściśle zorientowane na jak najlepszą komunikację w zespole (przypominam, że zespół stanowią programiści wraz z klientem).   Poleganie na relacja pociąga za sobą rezygnację z formalizmu. Ogranicza się tworzenie produktów ubocznych tak bardzo jak jest to możliwe bez szkody dla projektu. Mówiąc o produktach ubocznych mam na myśli: dokumentację projektu, podręczniki użytkownika, biblioteki programistyczne, itp. 
 Granice Agile
  Na podstawie tego, co zostało już wyżej napisane rodzi się pytanie: czy Agile jest ukoronowaniem ewolucji inżynierii oprogramowania? Moim zdaniem jest etapem pośrednim. Zniechęcenie tradycyjnymi metodykami spowodowało „huraoptymistyczny” odwrót w stronę metodyk lekkich. Mniej dokumentacji, mniej wymagań formalnych, mniej pracy – być może myśleli programiści. Takie rozumowanie nie jest zgodne z prawdą. Programowanie w Agile jest równie (jeśli nie bardziej) wymagające co programowanie w metodykach tradycyjnych. Narzuca ono na członków zespołu dość dużą dyscyplinę. Dzięki krótkim iteracjom, które absolutnie muszą zakończyć się konkretnym (czytaj: widocznym dla użytkownika) efektem nie ma miejsca na zajmowanie się mało istotnymi, lecz interesującymi, miejscami w systemie. Postępy pracy monitorowane są z dokładnością do jednego osobodnia.
  Wyobraźmy sobie system zarządzania siecią elektrowni stworzony przez zespół pracujący według wytycznych Agile. System taki można nazwać dużym systemem informatycznym. Z pewnością będzie on rozwijany i modyfikowany przez lata. Co najważniejsze, ze względu na problematykę, wymaga dokładnej specyfikacji. Tego typu systemy są poza zasięgiem zainteresowania lekkich metodyk. Przedsięwzięcia informatyczne wspomnianego kalibru wymagają takiej metodyki prowadzenia projektu, która precyzyjnie definiuje każdy element procesu wytwarzania oprogramowania (np. metodyka RUP). Stosowanie twardej metodyki jest konieczne ze względu na skalę i potencjalny czas trwania projektu. Ma ona za zadanie zapewnić bezpieczeństwo przedsięwzięcia oraz osiągnięcie postawionych celów.
  Podsumowując zakres stosowalności metodyk Agile można powiedzieć, że świetnie nadają się do realizowania małych i średnich projektów programistycznych o relatywnie krótkim czasie wykonania, np.: serwisy internetowe lub oprogramowanie dedykowane specyficznym potrzebom klientów. Nie bez znaczenia dla skuteczności metodyki jest ilość osób biorących udział w pracach. Powyżej 12 osób Agile przestaje być lekką metodyką, a staje się metodyką chaotyczną.
 Metodyka „Adaptable Process”
  Obszar dużych i długotrwałych projektów programistycznych jeszcze nie został zdominowany przez nurt Agile. Sądzę, że nie stanie się to aż do chwili, gdy zwinna metodyka zapewni wysoki poziom kontroli prac nad projektem w każdym momencie jego trwania, przy jednoczesnym zachowaniu lekkości. Taką metodykę można by oprzeć z jednej strony na jednej z implementacji Agile, z drugiej na twardej metodyce o ściśle zdefiniowanym procesie realizowania projektu. Na własny użytek nazwałem taką metodykę Adaptable Process. Wyobrażam ją sobie jako proces, który może być dopasowywany do zmieniających się wymagań klienta. Można pokusić się o wskazanie kryteriów, które powinna spełniać metodyka Adaptable Process, np.:
 Posiada zdefiniowany proces wytwarzania oprogramowania. Każdy  element procesu ma określone kryteria wejścia i wyjścia.
  
Umożliwia szybką reakcję na zmianę oczekiwań klienta.
  
Pozwala utrzymać wysoki poziom kontroli prac nad projektem –  w każdym momencie (nawet po zakończeniu projektu) wiadomo z  jakiego powodu podjęte zostały określone decyzje w projekcie.
  
Angażuje do pracy klienta/użytkownika.
  
Angażuje programistę do prac projektowych – nie wydziela  osobnych ról: projektanta i programisty.
  
Definiuje standardy pracy programisty np. jakość kodu,  pokrycie kodu testami, technika programowania.
  
Umożliwia zespołowi pracę w rozsądnym tempie i przez  rozsądną ilość godzin w tygodniu...
 
  Jeśli chodzi o inżynierię oprogramowania, z pewnością jeszcze długo nie zostanie wypowiedziane ostatnie słowo. Nowe wyzwania, które przed nią staną, sprowokują specjalistów do stworzenia nowych kreatywnych podejść. Dzięki temu następuje rozwój i możliwe coraz lepsze spełnianie oczekiwań klientów.

Artykuł ukazał się w kwietniowym numerze czasopisma DDI, http://ddinformatyku.pl