Gadżety Javy

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

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"

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

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:

1. Zatrudnij Strażnika architektury oraz Weryfikatora o wskazanych wyżej cechach - ci muszą być rewelacyjni
2. Zatrudnij pozostałych członków zespołu - ci powinni być dobrzy
3. 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.... :)