I nadeszła ta chwila, zaczynamy nowy projekt, zespół skompletowany, sprzęt stoi, można zacząć kodować. Jednak jak to zwykle bywa, faktyczny start się opóźnia, ale i tak zespół nie marnuje czasu, spędza go na prototypowaniu. W zależności od klienta, zespół wybiera docelową platformę aplikacyjną, język, w którym będzie oddawał się twórczej pasji i kilka mniej istotnych rzeczy. I właśnie tym "pierdółkami" się zajmę.

Nie ważne jakie mamy narzucone ograniczenia, zawsze mamy możliwość wyboru. W moim przypadku muszę tworzyć aplikację na daną platformę, dany szkielet, nie mogę użyć różnych fajnych rzeczy ze świata Open Source. Mam dostępne tylko to co zostało zaaprobowane przez departament Architektury (i parę innych, kompletnie nie związanych z IT ;-).

Mimo ograniczeń, dalej mam wybór. Jeśli tak, to co będzie potrzebne do "upichcenia" aplikacji:

• serwer aplikacyjny - jedyny słuszny u klienta
• baza danych - lokalnie HSQL a na produkcji DB2 lub Oracle
• szkielet www - JSP albo jedyny słuszny wspierany przez jedynie słuszny serwer aplikacyjny
• szkielet persystencji danych - czyste JDBC lub Hibernate - wybór oczywisty (czy aby na pewno?)
• dynamiczna walidacja modelu - to co dostarcza szkielet www (jak sama nazwa wskazuje) nie jest wystarczające i często ma się nijak do wymagań walidacji modelu i logiki biznesowej
• IDE - wybór dowolny, włącznie z preferowanym przez klienta (ktoś to będzie musiał wspierać później)
• narzędzie do zarządzania projektem - wyboru nie ma, klient narzuca swoje i trzeba się dopasować

Patrząc na powyższą listę, wybór sprowadza się do bazy danych, która i tak będzie taka sama jak na produkcji. Jedynie na potrzeby testów jednostkowych zespół wykorzysta HSQL. Ktoś oczywiście będzie zaskoczony "że przecież lokalnie też należy używać HSQLa", a ja powiem, że to proszenie się o problemy. Jeśli tylko można, należy używać środowiska jak najbardziej zbliżonego do produkcyjnego.

Szkielet www - nikt nie ma ochoty na "rzeźbienie" w czystym JSP, więc cokolwiek ponad to i tak będzie super. Zresztą i tak taki szkielet w dużej mierze przekształcimy do naszych potrzeb, bo od tego jest szkielet, ma być rusztowaniem dla pomysłów zespołu. Łatwość rozbudowy to podstawowe kryterium dla szkieletu www. Reszta to marketing ;-)

Persystencja - tu też wybór jest oczywisty, na pierwszy rzut oka. Kto chciałby się "babrać" w czystym JDBC? Pisanie tych wszystkich SQLi, tworzenie połączeń, więc Hibernate jest niczym Święty Graal. I w tym miejscu większość zespołów zapomina o tym elemencie, aż zaczną się problemy ;-) Przyjęcie, że Hibernate zrobi za nas wszystko jest dużym błędem. Decydując się na jego użycie musimy również spełnić założenia, które nakłada na aplikację ten szkielet. Podam tylko dwa problemy, które należy rozwiązać - implementację metod equals() i hashCode().

Dynamiczna walidacja - jeśli dynamiczna to znaczy potrzebujemy jakiegoś języka dynamicznego, coś co będzie można poprawić bez restartowania aplikacji i bez kompilacji. Jakiś język skryptowy będzie odpowiedni, wyszukujemy wśród zaaprobowanych języków skryptowych i jest, mamy język X (podstaw dowolny język skryptowy z jakim miałeś styczność i który pozwala wprost na interakcję z kodem napisanym w Javie). Gotowe, pozostaje tylko napisać generyczny mechanizm, który pozwoli wywoływać nam zapisane walidacje w plikach i wstrzykiwać model aplikacji do kontekstu przetwarzania skryptu. Teraz to już z górki!

IDE - wybór możliwości jest szeroki, od darmowych Eclipse i NetBeans po komercyjne IntelliJ IDEA, każdy z członków zespołu znajdzie coś dla siebie. Wymóg jest jeden, kod napisany za pomocą IDE musi się dać zbudować za pomocą narzędzia do zarządzania projektem klienta. Można to porównać do Mavena, który pozwala zarządzać projektem niezależnie od używanego IDE. Problemu nie ma, wszyscy kochają swoje zabawki ;-)

I gotowe, projekt rusza pełną parą, a że piszę o projekcie, który potrwa tak na oko z dwa lata, więc czasu mamy sporo. Jeśli nawet coś przeoczyliśmy, to będzie czas aby to naprawić, zmienić, dostosować. I znów zespół sam wprowadza się w błąd, zaczyna budowę na niesprawdzonych fundamentach. Nie ma pełnej wiedzy o problemach jakie mogę przysporzyć poszczególne elementy aplikacji - serwer aplikacyjny (zarządzanie wątkami), baza danych (wspierane typy indeksów), szkielet www (przechowywanie stanu w środowisku rozproszonym), szkielet persystencji danych (struktura tabel jest ważniejsza, niż łatwe mapowanie na encje), narzędzie zarządzania projektem (po dodaniu nowych zależności, należy zainicjować projekt od nowa).

Nie ma znaczenia, czy zespół sam wybrał dane rozwiązanie, czy zostało ono narzucone. Musi znać ograniczenia i wymagania każdego elementu, czas na początku projektu musi być temu poświęcony. To nie tylko skompletowanie "teczki z papierami", to również zaznajomienie się z tym "papierami" i ich zrozumienie. Temu właśnie ma służyć prototypowanie, poznawaniu możliwości i ograniczeń wybranych składowych aplikacji.

Najważniejszym kryterium pod względem którego należy sprawdzić każdy element to jak się zachowa w przypadku zmian, jedynej pewnej rzeczy, która na 100% wydarzy się w trakcie trwania projektu i to wiele razy. Wymagania zawsze będą się zmieniać.

Dość tych "wynurzeń", teraz trochę konkretnej wiedzy, która wynika z powyższych założeń. Skupię się na IDE i języku dynamicznym, gdyż oba są ze sobą połączone.

Użycie danego IDE powinno być przemyślane nie tylko pod względem łatwości użycia, czy znajomości przez członków zespołu. Również aspekt łatwości rozwiązywania problemów związanych z IDE i łatwość dostosowania do wymogów projektu musimy być rozważony. Dotyczy to wsparcia dla wybranych technologii - Hibernate , język dynamiczny, szkielet www. Podam prosty przykład: zmieniamy nazwę klasy Java za pomocą IDE, czy wszystkie odwołania, również z języka dynamicznego czy też z plików *.hbm.xml zostaną zmienione? Jeśli nie, to będziemy musieli wyszukiwać wszystkie przypadki użycia ręcznie i za każdym razem pamiętać o tym procesie. IDE zostanie sprowadzone do poziomu Notatnika.

W przypadku IDE dużą rolę odgrywa przyzwyczajenie członków zespołu, może dobrze jest je odłożyć na bok i nauczyć się obsługiwać nowe IDE, zwłaszcza jeśli będziemy go używać przez kilkanaście miesięcy? Szczególnie jest to istotne, gdy reszta zespołu używa wspólnego IDE a my jesteśmy wyjątkiem. Sprowadza się to do utrzymywania różnych plików projektu wymaganych przez dane IDE i przechowywanie ich w repozytorium. Z drugiej strony przechowywanie plików w projektowych IDE w repozytorium uważam za błąd. Do tego dochodzi rozwiązywanie różnych drobnych problemów związanych z danym IDE, jeśli jesteśmy wyjątkiem, to nie mamy za bardzo kogo zapytać.

Język dynamiczny - czy aby na pewno jest nam potrzebny? Łatwość dokonywania zmian i brak potrzeby kompilacji są zachęcające, ale co z poprawnością typów? co w przypadku gdy element na ścieżce (model.scenariusz.nazwa) jest nullem ? Jeśli wybraliśmy nasz język dynamiczny tylko ze względu na łatwość zmian w locie i braku kompilacji, możemy być w dużych tarapatach, zwłaszcza kiedy nasze IDE nie wspiera tego języka. I oczywiście takie problemy zaczynają się pojawiać, gdy projekt jest w bardzo zaawansowanym stadium i zmiana mechanizmu walidacji dotknie połowy aplikacji. Bez odpowiedniego rozpoznania we wstępnej fazie projektu, będzie to naprawdę dużą bombą z opóźnionym zapłonem. Pierwszym znakiem ostrzegawczym będzie brak wsparcia ze strony IDE. Reszta musi zostać wykryta w trakcie prototypowania.

Na końcu pasuje umieścić jakąś puentę, ale chyba tytuł tego wpisu robi za nią: trzeba myśleć i nie zdawać się na cudze opinie i przyzwyczajenia. Każdy projekt jest inny, jest procesem twórczym a nie produkcją samochodów na linii montażowej.

Pozdrawiam
--
Łukasz
http://www.lenart.org.pl