Anticorruption layer

Dziś łikendowy post z serii geek humor.

W ostatnim poście wspomniałem o hermetyzacji modelu domenowego poprzez Anticorruption layer, z którą to komunikujemy się poprzez Command i Query i z której nie wyciekają Encje.

Zobaczmy jak Eric Evans zobrazował to zagadnienie w 14 rozdziale swej książki (strona 367):



//==================

Więcej tego typu humoru w ospałych prezentacjach Evansa.

Lazy loading w kontekście paradygmatu Command-query Separation

ODŚWIEŻENIE KONTEKSTU

Kilka miesięcy temu popełniłem dwa posty na temat Lazy loadingu (wiem, że nie chce się Wam ich czytać więc streszczam):

Lazy Loading a sprawa wydajności - post traktujący ogólnie o drastycznym spadku wydajności w sytuacjach gdy LL jest stosowany w niewłaściwym momencie.

Chodzi głównie o klasyczny "n+1 Select problem", który potrafi totalnie zamulić system. W skrócie: problem pojawia się gdy pobieramy z EnityManagera/Sesji hibernate kolekcję a następnie iterujemy po niej i getterami pobieramy zagregowane obiekty. Wówczas do bazy wysyłane jest 1 zapytanie o kolekcję oraz dla każdego z jej n elementów koleje zapytania dociągające potrzebne obiekty.

Podobne schorzenie występuje gdy naiwnie ustawimy w mapowaniu FetchMode na EAGER.

DAO a sprawa Lazy Loading - post poruszający problem tak zwanej cieknącej abstrakcji, czyli "brudzenia" kodu logiki warstw wyższych szczegółami technicznymi typu zamknięta sesji persystencji.

Oczywiście mamy sprawdzony sposób na cieknącą abstrakcję - podejście Open Session in View (rozwiązanie w Springu np przez Mateusza Mirackiego). Niestety w tym przypadku łatwo dopuścić do opisanego powyżej "n+1 Select Problem". Ciekawe rozwiązanie z testowaniem ilości wysyłanych do bazy zapytań przy pomocy statystyk Hibernate zaproponował w komentarzu do mojego posta Milus.


CREDO

Od razu śpieszę wyjaśnić - żeby nie było, że jestem jakimś fanatycznym wrogiem Lazy loadingu czy ORM w ogólności. Wręcz przeciwnie, namiętnie go stosuję od 5 lat i uważam za bardzo wygodny młotek w większości sytuacji.


PROBLEM
Od czasu opublikowania tych postów dostałem kilka maili z zapytaniami o sposoby radzenia sobie z powyższymi problemami.

Pod postami wywiązały się też krótkie dyskusje prezentujące możliwe podejścia.

Właściwie to chodzi głównie o problemem z wydajnością, ponieważ filozoficzny problem cieknącej abstrakcji prawie nikogo nie boli. Nauczyliśmy się z nim żyć i raczej się nad nim nie zastanawiamy (na szczęście Jacek podziela moje rozterki).

PRAWDZIWY PROBLEM
Wg mnie prawdziwy problem leży w samym podejściu do dostępu do danych, czyli architekturze aplikacji. Problem polega na zbytnim uogólnieniu.

Tak samo traktujemy dwa diametralnie różnie rodzaje obiektów:
- obiekty domenowe, które wykonują operacje biznesowe (lub na których to wykonujemy modyfikacje w podejściu proceduralnym)
- dane "przekrojowe" potrzebne jedynie do prezentacji (np wyświetlenia na GUI) wycinka aktualnego stanu systemu

CQS
Teraz nadszedł wreszcie czas na przedstawienie tytułowego bohatera tego posta: zapomniany i zakurzony paradygmat: Command-query Separation.

Paradygmat tez zakłada, że system posiada "interfejs", przez który wysyłamy do niego polecenia oraz osobny, przez który odpytujemy o dane. Nigdy nie projektujemy operacji, które zarówno coś modyfikują jak i odczytują dane.

W jaki sposób możemy wykorzystać to podejście w systemach enterprise?
"Interfejsem" przez który klienty (nie klienci) komunikują się z systemem może być warstwa aplikacji. Cienka warstwa, która zajmuje się wszystkim, oprócz logiki biznesowej i dostępu do danych.






COMMAND
Ok, chcemy coś zrobić w systemie, wysyłamy do niego Polecenie. Tak jak wspomniałem "interfejsem" jest warstwa aplikacji "opublikowana" jako jakieś bezstanowe servisy lub obiekty stanowe - zależnie od wymagań.
Jeżeli klient wyśle do tej warstwy Command, wówczas pobiera ona z Repozytorium jakieś encje (lub agregaty w DDD). Dalej na encjach/agregatach uruchamiamy ich metody biznesowe - jeżeli bawimy się obiektowo, lub wywołujemy jakieś biznesowe servisy przekazując im jako parametry pobrane właśnie encje. Nic specjalnego, klasyczna architektura warstwowa.

Natomiast w tym właśnie przypadku - gdy wysyłamy do systemu Command mający zwykle na celu wykonanie jakiś operacji biznesowych - jak najbardziej możemy (ba powinniśmy) radośnie korzystać z Lazy loadingu. Jest to jak najbardziej właściwy moment ponieważ natura takich operacji jest zwykle taka, że pobieramy kilka obiektów, które wchodzą ze sobą w jakąś interakcję (lub władają nimi servisy). Rzeczone obiekty biznesowe ewentualnie potrzebują do wypełnienia swej biznesowej odpowiedzialności zagregowanych składników. Raczej nic złego się nie stanie, gdy zamiast 3 prostych zapytań do bazy wyślemy ich 5 czy nawet 10.
Czasem nawet będzie to bardziej wskazane niż join - zależy do natury danych.

Cała operacja wykonuje się w obrębie metody z warstwy aplikacji więc jest objęta transakcją i ma cały czas otwartą sesję persystencji więc nie martwimy się o wyjątki Lazy loadingu.


QUERY
Natomiast jeżeli do systemu trafia Query, czyli zapytanie o dane, to wówczas sprawa wygląda nieco inaczej...
Przede wszystkim warstwa aplikacji nie ma pod sobą warstwy z logiką (żadnych servisów biznesowych). Czy potrzebujecie abstrakcji dostępu do danych (DAO/Repozytorium)? Raczej nie zmienicie nigdy źródła danych. Nie ma sensu również testowanie jednostkowe "Finderów" aplikacyjnych z podmienionymi na mocki DAO. Czyli czyste pobieranie danych.

W mniej złożonych systemach możemy sobie pozwolić na zwrócenie encji w odpowiedzi na kwerendę.
W bardziej poważnych raczej nie możemy pozwolić sobie na ujawnianie klientom naszego modelu, więc zwrócimy jakiś Data Transfer Object (DTO). Hermetyzacja modelu to podstawa - dzięki temu może on ewoluować iteracyjnie bez obaw o zniweczenie pracy teamu dospawującego prezentację.


QUERY ZWRACAJĄCE ENCJE
Jeżeli zdecydujemy się na zwracanie encji to musimy uporać się z paroma problemami technicznymi:
- wydajność: zwykle scenariusz obsługi kwerendy to pobranie kolekcji danych. Wówczas mamy jak w banku opisany na wstępie "n+1 Select problem". Rozwiązanie jest bardzo proste - wystarczy się pofatygować i napisać zapytanie z klauzulą JOIN FETCH. Przykładowo SELECT p FROM Person p JOIN FETCH p.addresses - dzięki temu chciwie/łapczywie (nie wiem, na które rozkoszne tłumaczenie się zdecydować) pobierzemy osoby wraz z podciągniętymi adresami. Po prostu ORM wygeneruje SQLa z JOINem.

Niezbyt dobrym pomysłem jest ustawienie w mapowaniu powiązania obiektów z FetchMode.EAGER. Spowoduje ono, że zawsze wyciągając jeden obiekt pobierzemy jego "dziecko". Owszem są sytuacje, gdzie z kontekstu biznesowego takie podejście jest sensowne, ale zwykle stanowią zdecydowaną mniejszość. Zwykle w jednym Use Case zależy nam na pobraniu np osób z adresami a winnym adresy są zbędne.

Warto pamiętać, że domyślnie strategia EAGER obowiązuje dla powiązań wiele-jeden, jeden-jeden i warto ją wyłączać.

- Open Session in View - podejście to o ile jest wygodne to niestety pozwala łatwo zapomnieć o tym, że leniwie podciągamy jakieś dane. Po prostu istnieje niemała szansa, że na widoku odwołamy się do adresów osoby a w zapytaniu zapomnimy dopisać JOIN FETCH. Działa? Działa. Muli? W środowisku developerskim z małą ilością danych pewnie nie;P

- Ilość danych - zwykle Use Case gdzie do systemu trafia Query zakłada, że z bazy trzeba pobrać dane "przekrojowe". Czyli dane z wielu tabel, ale z każdej z nich interesuje nas zaledwie kilka kolumn. W małych systemach, gdzie warstwa GUI i warstwa aplikacji stoją na tej samej JVM będzie to w śmigać.

Ale nawet w takiej konfiguracji mamy problem z pobieraniem zbędnych danych. Przykładowo: gdy pobieramy z bazy np dokumenty aby jedynie wyświetlić ich listę (data, autor) a każdy z nich ma kolumnę przechowującą dziesiątki stron textu. Rozwiązaniem jest leniwe ładowanie pól - czyli ich nieładowanie:) W hibernate wymaga to poddanie skompilowanego bytecodu instrumentalizacji.

Innym podejściem może być zamapowanie tabeli przez kilka klas. Przykładowo DocumentFull, DocumentLight, itp... Jeżeli czujecie niesmak na myśl o mnożeniu bytów to nie jesteście sami.

Hibernate pozwala na pobieranie danych wprost do DTO. Tworzymy DTO szyte na miarę danego Use Case, a składnia wygląda tak:
SELECT new pakiet.KlasaDTO(pole1, pole2.podpole) FROM...
Oczywiście przy założeniu, że odpowiedni konstruktor istnieje.

QUERY ZWRACAJĄCE DTO
Jeżeli zdecydujemy się na zwracanie DTO to zapewne dlatego, że potrzebne dane są na tyle przekrojowe, że żaden zestaw encji nie modeluje ich sensownie (i optymalnie).
Innym powodem może być chęć hermetyzacji zmiennego modelu poza stabilną anticorruption layer. Warstwa zapobiegająca gniciu to pojęcie z DDD i ma pragmatyczny sens w nieco bardziej perspektywicznych projektach.

Poza tym możemy być dumni, że nawet nasza architektura wspiera Agile umożliwiając ewolucję modelu domenowego bez rujnowania wszystkiego dookoła:)

Częstym błędem w tym przypadku jest pobieranie z ORM encji a następnie przepakowywanie ich w DTO.
Nie tędy droga...

Pobierzmy tylko to co tak na prawdę jest potrzebne. Najprościej zrealizować to z użyciem wspomnianej konstrukcji Hibernate SELECT NEW. Jednak w złożonych systemach zwykle nieodzowny będzie co najmniej w paru jakiś szyty na miarę i zoptymalizowany SQL. Jakąś abstrakcją nad SQLem może być wówczas np iBATIS mapujący result na DTO.


Jak to zwykle bywa najlepsze będzie podejście hybrydowe. Tam gdzie możemy na to sobie pozwolić zwracamy w wyniku obsługi Query encje - zwiększając tym samym swą produktywność. Natomiast tam gdzie krytyczna jest wydajność lub specjalna struktura danych, zwracamy DTO.


//=======================================

Opisane powyżej aspekty wydajności związane z Lazy Loadingiem aplikują się do systemów każdej wielkości - szczególnie "n+1 Select problem". Natomiast rozwiązanie z CQS a szczególnie podejście gdzie zwracamy z kwerendy DTO jest bardziej pracochłonne, przez co aplikuje się do projektów bardziej perspektywicznych.

Ale czy jest sens tworzyć w JEE projekty inne niż perspektywiczne? Do prostych i szybkich zadań typu "przeglądarka do bazy" jest przecież Microsoft Access;P

Dzień bloggera

Ktoś sobie wymyślił, że dzisiaj będzie światowy dzień blogerów. Ok, fajnie.

Aby jakoś uczcić ten niezwykły, magiczny i jedyny w roku dzień postanowiłem zarekomendować nowego bloga poświęconego Javie i IT ogólnie: Technology For Human

Co prawda z założenia blog ma zawierać solidne tutoriale dla początkujących, ale na ile znam autora, to nawet doświadczeni wyjadacze będą mogli dowiedzieć się czegoś nowego z każdego posta.

Autor postawił sobie za cel przekaz rzetelnej wiedzy popartej realistycznymi przykładami. Bez ściemy znanej z tandetnych tutoriali. Autor zapewnia, że przykłady będą pochodzić z placu boju.

//==============================

Przyznam się, że sam miałem kiedyś w planie serię postów na temat własnej "skrzynki z narzędziami" - czyli kilku różnych kompletnych zestawów narzędzi developerskich oraz frameworków, które wykorzystałbym w przypadku problemu danej klasy. Niestety z braku czasu wciąż odkładam to zadanie. Ale na szczęście pojawiła się blog kolegi więc chyba sobie odpuszczę:)

Hasło na zakończenie tego magicznego i jedynego w roku dnia: Blog to zdrowie (a oto dowody tej tezy)

Jeszcze prostota czy może już prostactwo?

Chyba każdy z nas zastanawiał się nad tym co takiego urzekło go w programowaniu, że wybrał właśnie to zajęcie. Co takiego przykuwa nas na długie godziny do komputera i powoduje, że zapominamy o zwyrodnieniach kręgów szyjnych i nadgarstków, o zakrzepach w żyłach głębokich,...

Niektórzy odpowiadają, że pociąga ich możliwość tworzenia i kreowania. Inni lubią mieć kontrolę i możliwość decydowania. Są też tacy, którzy pławią się w masochistycznej rozkoszy (choć nigdy się do tego nie przyznają) lawirowania pomiędzy ograniczeniami różnego rodzaju.

/*
 *Przypadki gdy ktoś po prostu "miał Pascala na studiach"
 *i przypadkiem został zatrudniony z jakiejś "łapanki"
 *a później "tak już zostało" pominę w tych rozważaniach.
 */

Jest jednak jeden wzorzec, który powtarza się byt często aby go zignorować. Mianowicie - większość z nas podkreśla, że największą przyjemność sprawia poszukiwanie prostoty, elegancji i harmonii. Nasze umysły nieustannie poszukują zgrabnych modeli pewnych wycinków modelowanego świata. Nic nas tak nie cieszy jak elegancka i prosta forma.

Po tym przydługim wstępie czas przyznać się co sprowokowało mnie do napisania tego posta: prezentacja Jonathana Dahl Programming and Minimalism.

Szczerze polecam tą prezentację (to tylko ok pół godziny). Pomimo ogromnego stresu w jakim był prelegent jest to aktualnie prezentacja numer 2 na mojej liście prezentacji dla programistów. Wyprzedza ją tylko znakomita Developing Expertise: Herding Racehorses, Racing Sheep o której pisałem tu: The Unforgiven.

Jonathan Dahl dokonał czegoś niezwykłego i pięknego zarazem. Pokusił się o próbę syntezy zasad minimalistycznej prostoty, występujących w języku naturalnym, muzyce oraz programowaniu oczywiście. Szczególnie ciekawie brzmi część przedstawiająca przekrojowo sinusoidalne zmiany komplikacji w muzyce - począwszy od Mozarta a skończywszy na Punk Rocku:) Być może dowiecie się z niej dlaczego pewne gatunki muzyki Wam odpowiadają a innych kompletnie nie trawicie... wszystko zależy od preferowanego poziomu komplikacji "figur" akustycznych.

Ale wracając do kontekstu programistycznego... Prezentacja, którą się tak zachwycam traktuje o programowaniu stricte w dosyć zdawkowym wymiarze. Ot mamy jakąś funkcję w Ruby - pogańskim języku, którego nie rozumiem. Jedna jej wersja została upstrzona składnią, którą zna pewnie 5% programistów tegoż języka, natomiast druga (o identycznej funkcjonalności) zawiera prostego ifa. Wniosek: prostota w programowaniu to podstawa. Dziękujemy i do widzenia.

Chciałbym jednak rozwinąć ten temat, ponieważ z moich obserwacji wynika, że o ile wszyscy powtarzają jakoby prostota była ich świętym Graalem to samo pojęcie prostoty w programowaniu jest mocno rozmyte. Nieraz spotkałem się z sytuacją gdy pewien mniejszy lub większy kawałek kodu był oceniany jak majstersztyk lub kupa guano.

Od czego to zależy?
Nawet w tak dobrze zdefiniowanej domenie jak muzyka mamy sytuacje, gdy pewien utwór/twórca/gatunek/styl "się podoba" lub "się nie podoba". Klasycznym przykładem jest Chopin, którego się uwielbia albo nienawidzi:)
Odwołując się do wspomnianej wyżej prezentacji: zależy to od stopnia komplikacji i możliwości jej ogarnięcia przez odbiorcę. Pewne formy są zbyt banalne, pewne zbyt skomplikowane (wydają się wręcz chaotyczne) a pewne w sam raz nam odpowiadają.
Większość umysłów ścisłych jest jak inż. Mamoń - podoba im się to co już znają. Mechanizm jest prosty: znając jakiś wzorzec (utwór) wiemy czego się spodziewać w danej chwili i cieszymy się gdy słyszmy właśnie to czego się spodziewamy. Przypomnijcie sobie jak irytująca jest nagła zmiana kawałka albo różnego rodzaju zakłócenia;P

Wyobraźmy sobie przykładowy problem, którego rozwiązanie można zapisać w jednej klasie z jedną metodą, która ma powiedzmy 10 ekranów a na nich 100 ifów. Ktoś może powiedzieć, że jest to rozwiązanie najprostsze, ponieważ "wszystko po kolei widać", wystarczy się dobrze wczytać;)
Inne podejście może wymagać powiedzmy 5 interfejsów i 10 klas. Każda klasa zawiera parę linijek kodu. Ktoś może stwierdzić, że jest to rozwiązanie zbyt skomplikowane ponieważ aby zorientować się co się dzieje, "trzeba skakać po wielu plikach" i "nie widać całego przebiegu".

Kto ma rację? To oczywiście zależy od preferencji. Jedni wolą wiele prostych pudełek składających się na bardziej wyrafinowaną strukturę, inni będą preferować jedno pudło, w którym jakoś się połapią.


Aby nie szukać konkretnego przykładu zbyt daleko przyjrzyjmy się strumieniom w standardowej bibliotece Javy. Pamiętacie jeszcze swoje pierwsze z nimi spotkanie?;P Dziesiątki klas, jakieś interfejsy, pokręcone konstruktory. Pierwsza reakcja? Panika i odrzucenie. Ja chcę przecież tylko odczytać głupi tekst z pliku a to panie takie pokomplikowane.

Natomiast znając pewną ogólną zasadę - wzorzec dekoratora całość nagle okazuje się być piękna w swej prostocie. Trudno stwierdzić co cieszy bardziej: elegancja tego rozwiązania czy prostota używania i niezwykła łatwość składania złożonych strumieni.

//===========================
Problem prostoty nie jest jednowymiarowy. Nie zawsze problem polega jedynie na tym po prostu działało. Często musi jeszcze dać się zrozumieć, zmienić, rozbudować, skalować, optymalizować, itd. Wówczas kryteria prostoty i elegancji zmieniają wartości.

Bardzo łatwo wówczas pomylić szlachetną prostotę z pospolitym prostactwem. Linia pomiędzy nimi jest zwykle cienka.

Słynny cytat Einsteina "rzeczy powinny być tak proste jak to możliwe" niesie ze sobą na prawdę głębokie przesłanie...

Jakość (życia)

Kolejna Javarsovia za nami.
Brawa dla organizatorów za profesjonalizm i samą inicjatywę. Podziękowania należą się też (a właściwie to przede wszystkim) prelegentom, którzy altruistycznie dzielili się wiedzą i doświadczeniem.

W stosunku do poprzedniego roku zauważam pozytywną zmianę patrząc na przekrój tematów. Zdecydowanie mniej onanizmu technicznego. Nowe zabawki nie rozwiązują problemów, oprócz tych, które same stwarzają. Stawiamy bardziej na profesję. To chyba znak, że idą zmiany w mentalności naszego comunity - zgodnie z nowym trendem: craftsmanship.

W większości prezentacji, w których uczestniczyłem pojawiała się idea jakości. Jakości rozumianej nie tylko jako atrybut produktu, ale przede wszystkim jako jakość naszej codziennej pracy.

Z jakością produktu bywa różnie - nie zawsze jest istotna. Klient nie jest świadomy - dla niego ma po prostu działać. Szef martwi się o harmonogram i budżet - o inne sprawy będziemy (będziecie;P) martwić się później. Biznes rządzi się swoimi prawami i to jest zrozumiałe.

Natomiast aspekt jakości rozumianej jako jakość codziennej pracy nad projektem IT to coś z goła innego. Chyba nikt nie lubi tego uczucia, gdy budzisz się rano, otwierasz oczy, patrzysz w sufit a pierwsza myśl jaka przychodzi do głowy na dobry początek nowego dnia to "k@#$%, nie po to studiowałem x lat żeby teraz wstawać rano, brać widły do ręki i przerzucać ten zgniły kod".

W wymiarze osobistym jakość codziennej pracy jest jedną z najważniejszych składowych jakości życia.

Chyba stąd u prelegentów, którzy swoje w życiu przerzucili, refleksje na tym co robić aby nie szarpać się w codziennej pracy. Krótka relacja z prelekcji, w których uczestniczyłem:

Randori TDD - Krzysztof Jelski - ciekawe podejście do developemntu. Randori w skrócie (i na ile udało mi się zrozumieć) polega na programowani w parach z rolą kierowcy i pilota. Kierowca programuje skupiając się na detalach podczas gdy pilot dba szerszą wizję.
Programowanie odbywa się w cyklach: najpierw test, działająca implementacja, refaktoryzacja do osiągnięcia jakości rozwiązania. Rozpoczęcie programowania od testu powoduje, że zastanawiamy się nad tym JAK nasza klasa będzie używana przez klasę-klienta.

Co prawda wymaga to zmiany mentalnej, ale spojrzenie z perspektywy klasy-klienta na prawdę się opłaca. Chyba każdy nie raz miał przykre uczucie niesmaku próbując wreszcie użyć swój super zestaw właśnie stworzonych klasek.
Przewiduję również wzrost produktywności - ciężko obijać się gdy siedzi ktoś obok nas;)

Wg mnie jest również doskonały sposób na efektywne przekazywanie wiedzy.
Najszybciej uczymy się przez naśladownictwo. Zjawisko to może zostać spotęgowane przez obecność eksperta, który na bieżąco wyjaśnia rozwiązania problemów i przesłanki stojące za wyborem danego podejścia. Najbardziej efektywnym i przynoszącym najlepsze rezultaty sposobem na wprowadzenie nowego członka do zespołu jest poświęcenie mu czasu na wspólne programowanie. Niemal naturalnie przejmuje on wówczas nawyki i dobre praktyki, których samodzielne wypracowanie zajmuje niejednokrotnie lata.

Drools Guvnor - Jarosław Kijanowski - tutaj aspekt jakości pracy nie był zbyt silnie uwypuklony. Może poza aluzjami do poziomu profesjonalizmu analityków;)
Na na podkreślenie zasługuje sama forma prelekcji: z jajem, bez stresu, ogólna idea-zaciekawienie-przykład. O to chodzi!

Praca z odziedziczonym kodem - Jakub Dziwisz przede wszystkim brawa na Jakuba (agiletuning) - profesjonalny prelegent z charyzmą i klasą. Praca z odziedziczonym kodem, hmm temat w sumie bardzo smutny;) Zaprezentowano techniki refaktoryzacji, mające na celu zmniejszenie bólu. Pamiętajmy jednak, że słaby kod to nie tylko problem przeszłości. On powstaje również tu i teraz zatem przedstawione techniki mogą mieć wykorzystanie w codziennej pracy. Podstawa to dobrze zrozumiany OOD, G.R.A.S.P i S.O.L.I.D oraz wzorce projektowe w granicach rozsądku.

Ewolucja Architektury - Paweł Lipiński. Paweł zaprezentował pragmatyczne podejście do architektury. Architektura - arcy ważny składnik procesu a z dyskusji uczestników widać było, że są różne sposoby rozumienia tego słowa. Przydało by się uporządkowanie pojęć: wskazania domen architektury (aplikacji, systemy, wdrożeniowa) oraz jasnego rozdzielenia architektury od projektowania.

Najważniejsza wg mnie myśl z prelekcji: architekci muszą programować. Jako architekt potwierdzam i podpisuję się pod zdaniem Pawła. Niestety aby móc powiedzieć coś sensownego na temat kształtu systemu trzeba ubabrać sobie rączki. Nie wystarczy mieć doświadczenia x lat temu, a już kuriozalna jest sytuacja gdy architekt może pochwalić się jedynie programikiem w Pascalu napisanym na studiach.

//==============================

Prezentowane zagadnienia poruszyły część aspektów jakości (w sensie bezstresowej pracy) w całym procesie wytwarzania softu.
Do kompletu, jako uzupełnienie, dodałbym:
- Analizę biznesową - zrozumienie problemu klienta, zebranie wymagań
- Rzetelną analizę systemową - analiza to proces myślowy, włożenie wysiłku w uporządkowanie biznesu. Warto wesprzeć się sprawdzonymi rozwiązaniami, takimi jak Archetypy biznesowe. Niestety czasem jest to jedynie spisanie ton dokumentów zawierających nieprzetrawiony bełkot.
- Architektura - podczas prelekcji Pawła padło pytanie o przykłady architektur. Wszystko oczywiście zależy od konkretnego problemu Ja obecnie w nietrywialnych aplikacjach webowych stosuję modyfikowane do problemu architektury Distributed DDD oparte o Command-Query Separation.
- Projekt - Architektura narzuca ogólny styl projektowania. Aby uniknąć w niedalekiej przyszłości koszmaru utrzymania własnego kodu warto wspierać się technikami OO takimi jak SOLID czy GRASP.
Ale podstawa to w ogóle projektować zamiast rzucać się jak dzikus na klawiaturę i radośnie napieprzać;)

Ile Ci to zajmie? (różnice w postrzeganiu czasu)

Niektóre filozofie zakładają, że czas nie istnieje. Jest tylko tu i teraz, upływ czasu to złudzenie. Inni z kolei chcą go wyginać i zaginać.

Ale zejdźmy na ziemię. W biznesie czas to tylko pieniądz. Stąd też najczęściej pojawiającym się pytaniem w komercyjnym procesie tworzenia softu jest nasze ulubione:

ILE CI TO ZAJMIE?

Managerowie uwielbiają zadręczać tym pytaniem swoich/swoje zasoby. Irytują się, gdy developerzy nie są w stanie odpowiedzieć na tak elementarne pytanie. Przecież jeżeli robi się coś od kilku lat to powinno dać się niemal co do godziny określić ilość potrzebnego czasu. Co za durnie, siedzą w tym po uszy i nie potrafią nawet zarządzać sobą, swoimi zadaniami i swoim czasem. Przecież programowanie jest prawie jak budowanie. Macie nawet te swoje wzorce pokrakowe (czy jakieś tam) oparte na latach doświadczeń budowlańców. Muszę mieć harmonogram i się z niego wywiązać. Budżet Panowie! Budżet!

Developerom z drugiej strony ciśnie się na usta "Nie wiem! Nigdy wcześniej tego nie robiłem!" - heh ale tylko Ci o mocnej pozycji w plemieniu mogą sobie pozwolić na zwerbalizowanie swoich myśli. Czy on nie rozumie, ze praca badawczo-rozwojowa (a taką właściwie jest każdy nowy projekt z uwagi na nowe narzędzia) nie jest liniowa a eksponencjalna. Stając w kopalni z kilofem w ręku, kilometr pod ziemią i fedrując na przodku nigdy nie wiadomo kiedy trafimy na skałę, ile będzie trwać stagnacja i kiedy pojawi się nagły wybuch ruszający wszystko do przodu. Programowanie to nie murowanie muru z cegieł (1 cegła na minutę = > mur z 1000 cegieł to 16.7 godziny) - to tak nie działa.

Jedni i drudzy mamroczą pod nosem: co za durnie!



Zagadnienie szacowania czasu, metodyki szacowania to temat na osobna bajkę, dziś będzie o postrzeganiu czasu.

Ale zanim przejdziemy do corowej warstwy posta, zatrzymajmy się na chwilę aby pokazać sceptykom, że postrzeganie czasu rzeczywiście jest względne i każdy doświadcza tego niemal codziennie (proszę nie uciekać od ekranów - względne w sensie poznawczym a nie w sensie teorii względności).

Pomijając filozoficzną i fizyczną naturę czasu, Twój mózg jest po prostu tak skonstruowany, że postrzega upływ czasu. Mamy wbudowane 2 "koprocesory czasu" - zegary dobowy i bieżący. Zegar bieżący opiera się na mechanizmie taktowania (tysiące neuronów) i próbkowania (neurony gwiaździste i piramidalne). Co ciekawe i istotne dla nas, hormony stresu zmieniają stężenie neuroprzekaźników w naszym "koprocesorze" czasu bieżącego co powoduje zmiany w "tykaniu" a co za tym idzie próbkowaniu bodźców ze świata.

Wszyscy znamy uczucie dłużenia się czasu lub odwrotne do niego - szybki upływ czasu. Jak się okazuje niem tu żadnej magii - wszystko zależy od poziomu hormonów stresu. Dzięki temu np w stresowej sytuacji na drodze mamy "gęste" próbkowanie świata, wchłaniamy więcej danych w jednostce czasu i mamy więcej "cykli" na podejmowanie działań związanym z uniknięciem zderzenia z jakimś durniem.


Przejdźmy do meritum, czyli czasu w kontekście IT.
W tym celu zostawmy poziom "techniczny" czyli neurony i przyjrzyjmy się ogólnym strategiom przeżywania czasu: Spontaniczny plan dnia.
Wynika z niego, że dysonans w podejściu do czasu i planowania jaki obserwujemy na różnych stanowiskach może wynikać z różnych sposobów myślenia o czasie. Tak, tak, wg tego modelu różnimy się wewnętrznymi reprezentacjami czasu!

Mamy zatem ludzi żyjących:
- W czasie (In time) - żyją chwilą, odczuwają każdy moment, bez planu i kontroli czasu, skupiają się na aktualnym działaniu
- Pomiędzy Czasem (Between Time) - w pozycji zdystansowanej do czasu, mają na niego ogólny ogląd, widzą możliwości działania, ale nie przypisują im czasu trwania, dowolnie przestawiają zadania
- Poprzez Czas (Through Time) - również z dystansem, ale mając ścisły chronologiczny plan, każde zdarzenie ma czas rozpoczęcia i czas trwania, czas jest linią o ograniczonej pojemności (w sumie logiczne;)

Autorzy artykułu zachęcają nas do trenowania różnych sposobów przeżywania czasu i dobierania najlepszego do danej sytuacji. Powodzenia.

Zastanawiam się czy można w ogóle być dobrym managerem nie żyjąc Poprzez Czas - widząc dokładny plan, zależności czasowe i być przez to cel-oriented?

Czy można w ogóle prowadzić jakąkolwiek kreatywną działalność (mam na myśli sensowną działalność a nie np malarstwo współczesne) nie żyjąc Pomiędzy Czasem - dostrzegając możliwości i potencjał.

A żyjąc chwilą W czasie lepiej chyba nie męczyć się z IT, rzucić to wszystko i rozpocząć karierę w biznesie porno;)

Każdy powinien zająć się tym w czym jest dobry. A szacunek to podstawa.

//==============================

"Ty masz zegarek, ja mam czas"
...Usłyszał w odpowiedzi na nerwowe pokazywanie na cyferblat podróżnik, gdy usiłował ponaglić swego przewodnika na postoju, pod­czas wędrówki gdzieś, na andyjskim bezludziu.

Domain Driven Disaster

Przygotowania do prezentacji o DDD na LJUG w toku. Tymczasem mamy niecodzienną okazję aby zobaczyć jak w praktyce możne wyglądać projekt, którego jednym ze szczytnych założeń było podążanie za DDD.

Dziś pierwszy (i mam nadzieję, że nie ostatni) post z gatunku gościnnych.

Jako pierwszego mamy zaszczyt gościć tajemniczego Malory z krainy deszczowców, który podzieli się doświadczeniami z dużego, zagranicznego projektu. Projektu, w którym niestety nieco rozminięto się z filozofią DDD, TDD i Agile:

<post_goscinny>
Przyjemność bycia częścią projektu napędzanego czystym agilem (iteracje mamy, lecz do Agile nadal daleka droga), z domieszką domain driven, test driven, i ogólnie driven skłonił do podzielenia się kilkoma refleksjami. Tym gościnnym postem u Sławka podzielę się refleksjami o dysonansie miedzy filozofią którą niosą ze sobą ddd, Agile, TDD a praktyką... czyli Projektem.

O ddd Sławek pisał tutaj już nie raz i każdy z czytelników mniej lub bardziej "czuje' o co w ddd chodzi. Esencja to słowa z ddd.org: "ddd is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains". Nic dodać, nic ująć. Koncepcja a raczej filozofia spojrzenia na problem, na domenę. A w praktyce? Bywa różnie. Brak zrozumienia idei którą niesie ze sobą ddd, i twarde (beton) myślenie przez pryzmat aplikacji CRUD driven (formularzyki), gwarantuje Monthego Pythona każdego dnia. Sam wybór ddd nie zawsze jest szczęśliwy bo jak wyraźnie wskazuje cytat: "complicated domain". Więc po co się męczyć, i udawać ddd gdy chcemy zrobić nakładkę na db? Efektem końcowym będzie i tak mieszanka anemicznych encji i a'la serwisów żonglujących encjami w górę i w dół. W praktyce ddd niebezpiecznie zbliża się do kilku „warstewek” klas delegujących wywołania metod z dao. I nie ma w tym nic złego – to rozwiązanie dobiera się do problemu. Nie odwrotnie. Sama sytuacja w której kończymy z pustymi encjami (@Entity, nie żadne tam encje ddd) i serwisami wskazuje że coś jest nie tak. Fundament OOD jest prosty – odpowiedzialność a get/set to chyba jednak trochę za mało...

Siłą napędową ddd to domena, co w odniesieniu do projektu oznacza eksperta domeny, będącego światłem w tunelu dla zespolu. Jako ze projekt nie zawsze ma domain eksperta - bywa śmiesznie. Developerzy to cwani ludzie i dadzą radę, ale to raczej Developer Driven Design (co oczywiście nie jest złe.. ale zależy od doświadczenia zespołu...). W przypadku bogatej domeny, bez pomocy eksperta wątpliwe jest stworzenie nawet poprawnych zrębów domeny, nie wspominając nawet o niuansach i bliższym nakreśleniu relacji w domenie. Pora teraz na agile (fonetyka naszego rodzimego języka, nie żaden tam edżajl).

Skomplikowana domena powoli ewoluuje, nieraz zamiast ewolucji doświadczyć możemy rewolucji, gdy powolny knowledge crunching zaowocuje przełomem w spojrzeniu na domenę. I czy nie jest to "Responding to change over following a plan" który niesie ze sobą agile manifesto? W tym momencie przypomina mi się pytanie podczas jednego z pierwszych spotkań (spotkanie a raczej meeting jest nieodzownym elementem każdego poważnego agile projektu), a mianowicie "kiedy dostaniemy skończony model domeny?". Hmm - odpowiedź była prosta: nigdy. Po czym zaczęło się wyjaśnianie (okraszone nerwowymi spojrzeniami "góry"), że to nie waterfall. Same iteracje nie sprawią, że będziemy Agile. Do tego potrzeba tzw. bigger picture i zmuszenie całego zespołu (łącznie z managementem) do innego spojrzenia na problem. Iteracje i milestony mogą być jednak wystarczającą dawką agilu. O tym, że to wymagania napędzają development niekoniecznie się pamięta. Zresztą, bywa w niektórych projektach że wymagania odpowiadają poziomem testom (assertTrue(true)); //FIX LATER, its friday, 4 o'clock ). Raz zrobiony task (zrobiony w stylu general concept, bo jak inaczej bez wymagań...) zostaje jako skończony i nie ma nawet mowy o refaktoringu pózniej... To przecież zbędne filozofowanie... W wyniku zostaje brązowa (flagowy kolor branży) papka kodu którą ktoś (nieszczęśnik, albo student, niewolnik IT) będzie miał przyjemność poprawiać. Domena zamiast ewoluować - kostnieje, zamiast odpowiadać na zmiany - napierdalamy aby zdążyć w terminie.

Ostatnim kawałkiem układanki jest TDD. Który doskonale wpasowuje się do mieszanki DDD i Agile. Domena powinna ewoluować, dojrzewać, i odpowiadać na zmiany. Tutaj pomocną rączkę wyciąga TDD. Pod warunkiem że napisane testy mają sens. W życiu bywa jednak rożnie, w praktyce testy nie zawsze testują. Mądrze napisane uspokajają sumienie i pozwalają pracować nad aplikacją. Pozwalają na eksperymentowanie i dają ujście wiedzy którą powoli team zdobywa. Testy trzeba jednak umieć pisać.. i mieć na nie czas. Z pierwszym bywa rożnie, na drugie niekoniecznie jest czas w schedule projektu. Efekt - każdy boi się panicznie dotknąć czegoś większego w domenie aby całość się nie rozleciała...

Na koniec link do doskonałej prezentacji o... samochodach. Obejrzyj i popatrz przez pryzmat naszej branży. Tutaj też są projektanci i inżynierowie. W tej branży jest miejsce na pasję, rzemiosło i jakość. Uwolnijmy się od brązu.



</post_goscinny>



//=======================================

Jak wiadomo najlepiej uczyć się na błędach:) Dobrze, gdy mamy okazję z dystansu przyjrzeć się cudzym:]
Potwierdzają się moje przemyślenia na temat metodyk Agile. Idea piękna, ale pod warunkiem, że mamy dojrzały i świadomy zespól profesjonalistów, którzy wiedzą co robią lub przynajmniej mogą poprowadzić duchowo resztę teamu.

Sama filozofia DDD o ile nie jest jakoś specjalnie wysublimowana to niestety posiada pewną barierę wejścia: podstawy OO - i nie mam tu na myśli składni dziedziczenia, lecz myślenie obiektami.