Programista Java

Początki Javy to proste projekty uczelniane. Jako ciekawostkę mogę podać, że podczas zajęć kursowych z Javy na trzecim roku po raz pierwszy usłyszałem o Extreme Programming. Pisałem projektu hobbistycznie, także udzielałem korepetycji z języka.

Język Java wykorzystywałem po raz pierwszy komercyjnie podczas pracy w firmie DNet. Opracowałem tam aplikację współpracującą z systemem Workflow firmy S.E.R. Nadbudowywała ona funkcjonalność formularzy i podpisu elektronicznego (biblioteki w C++ od firmy Unizeto) nad "surowym" systemem workflow.

Kolejną okazją do wykorzystania Javy był projekt dla dużej firmy ubezpieczeniowej. Odpowiadałem tam za utworzenie warstwy prezentacji dla aplikacji korzystającej poprzez CORBĘ (CORBA) z systemu bazowego (utworzonego w Delphi). Jako biblioteka MVC został wybrany JSF, warstwa prezentacji opierała się na HTML-u (HTTP). Wtedy pierwszy raz na tak dużą skalę wykorzystałem weryfikację statyczną - w tej implementacji opartą o skanowanie wyrażeniami regularnymi poprzez język zewnętrzny (AWK). Nie mogłem zastosować typowego, dynamicznego sprawdzania ze względu na wykorzystanie JSP (kompilacja na serwerze aplikacyjnym). W tym momencie już jestem pewien, że Weryfikacja Statyczna to jedyna rozsądna droga w takim przypadku.

Weryfikację statyczną warstwy prezentacji rozwinąłem pracując nad projektem dla banku. System napisany został w Struts i korzystał z bazy danych Oracle poprzez Hibernate. Jako serwer aplikacyjny posłużył Weblogic, a do testów był wykorzystywany Tomcat. Tu już zastosowałem weryfikację opartą o język bazowy (Java) i o parsery SAX. Pozwoliło to całkowicie wyeliminować pewną klasę błędów z aplikacji.

Podobną konfigurację wykorzystałem w projekcie dla firmy telekomunikacyjnej (Baza MSSQL, Struts, Hibernate, Jboss). Dzięki mechanizmowi refleksji Javy możliwe było zakodowanie bardzo złożonych sprawdzeń. Dzięki takiej konstrukcji bardzo rzadko pojawiały mi się błędy po zainstalowaniu aplikacji na serwerze aplikacyjny. Cała weryfikacja wyglądała jak ogromny kompilator z dowolnie definiowanymi błędami.

(...) Nie ma bowiem łatwych odpowiedzi. Nie istnieje nic takiego jak najlepsze rozwiązanie - zarówno jeśli chodzi o narzędzia, jak i języki czy systemy operacyjne. Są jedynie systemy, które mogą być bardziej odpowiednie w konkretnych okolicznościach.

I tu właśnie do gry wchodzi pragmatyzm. Nie należy przywiązywać się do żadnej określonej metody, ale mieć na tyle rozległą wiedzę i doświadczenie, by w danej sytuacji wybrać dobre rozwiązanie. (...)

Andrew Hunt, David Thomas "Pragmatyczny Programista"