"Reszta jest niczym więcej jak...złożeniem" - przemyśleń rozwojowych ciąg dalszy (na bazie szkolenia ZB300 o IBM WebSphere ILOG JRules V7.0)

Ucichło na moim polskojęzycznym blogu na rzecz aktywności na innym, angielskojęzycznym, gdzie przedstawiam swoją ścieżkę badawczą produktu IBM WebSphere ILOG JRules V7.0. Tam komercyjnie, tu raczej niekoniecznie. Dużo czytania, szkolenia, ale wciąż niewiele praktycznego poznania tematu, co może ma tę zaletę, że pozwala mi na chwilę zastanowienia nad sensownością stosowania jednej technologii nad drugą, albo sposobami na ich trafniejsze zastosowanie w projektach.

Obecnie zmagam się ze zrozumieniem reguł biznesowych i ich organizacji w projekcie. Jestem na poziomie nowicjusza, który opanował używane słownictwo (nomenklaturę) typu rule project, BOM, XOM, vocabulary, rule, ruleset, ruleflow, agenda, working memory i in. Wciąż czuję brak doświadczenia praktycznego i dostrzegam, że podobnie jak to ma miejsce w poznawaniu nowej technologii, albo czegoś niekoniecznie technologicznego, jak nauka języka obcego, poznawanie nowego nie będzie efektywne, jeśli nie idzie za tym praktyka. Ćwiczenia to podstawa dobrej nauki. Należę do tych osób, które często dopiero przez ćwiczenia są w stanie zrozumieć problem (empiryczne podejście) i rzadko zdarza mi się poznawać technologię począwszy od jej teorii. Najpierw dużo praktykuję, a dopiero czytam teorię, albo uzupełniam ją na bieżąco. Zawsze jednak to praktyka wyznacza u mnie zrozumienie tematu.

Ostatnio zauważyłem zmianę w swoim podejściu poznawania nowego - najpierw studiuję dostępną dokumentację - README, Release Notes, Getting started, 5-minute Tutorial, itp. Te dokumenty znane są z nazwy każdemu, ale niewielu ma na nie siły. Jest ich zbyt wiele, a ich jakość czy przystępność wyjaśniania problemu niekoniecznie odpowiednia. Tak czy owak, z takim sceptycznym podejściem skończyłem jakiś czas temu i dużo, bardzo dużo czytam - książki, podręczniki, instrukcje, dokumentacja produktowa, wpisy na blogach, własne oraz innych i tweety. Mnóstwo tego. Pozwoliłem sobie na nieznaczne usprawnienie procesu absorbowania wiedzy i jeśli tytuł jest nieodpowiedni w ogóle nie zabieram się za lekturę (kiedyś powiedziałbym, że wiele tracę, bo nieumiejętność dopasowania tytułu do treści jest sztuką samą w sobie, ale obecnie przy takim natłoku informacji jest to jeden ze sposobów na jej wstępne filtrowanie).

Wracając do mojej nauki ILOG JRules 7, wszedłem w skórę osoby, która jest kompletnym nowicjuszem i rozpoczyna swoją przygodę z produktem. Już dawno się tak nie czułem. Bardzo odświeżające doświadczenie. Zacząłem od czytania, później słuchania (szkolenie zdalne, bez instruktora, coś ala podcast ze slajdami, ale niestety nie jest to skrinkast - coś pomiędzy) i instalacji produktu z prototypowaniem. Kiedy się tak uczę tych wszystkich nowych technologii zaczynam dostrzegać pewne podobieństwa między nimi i nie piszę tutaj o podobieństwach funkcjonalnych, ale ich wewnętrznej reprezentacji, która nieprzypadkowo związana jest w moim mniemaniu z najprostszą reprezentacją jakiegokolwiek rozwiązania javowego - na klasie w Javie.

Kiedy tak sobie rozważam, jak mógłbym stworzyć dane rozwiązanie zaczynam rozumieć działanie produktu i nowe słownictwo staje się synonimem dla już znanego, co znacząco wpływa na moje szybsze zrozumienie problemu. Szukam w nim wzorców i problemów, które znam i dla których znam rozwiązanie. Bardzo pomocna technika. Wymaga to dużej znajomości alternatywnych rozwiązań, ale z każdym kolejnym jest coraz prościej. Czuję, że jest łatwiej.

I tak dzisiaj zmagałem się z regułami i ich parametrami wejściowymi i wyjściowymi, gdzie przypomniało mi się, że już gdzieś czytałem, że zaleca się wynosić poza wyrażenie if warunek, na którym działa. Ów warunek to w tym przypadku właśnie reguła biznesowa. Skoro wynieśliśmy warunek poza ifa, to najprawdopodobniej stworzyliśmy nową metodę, która przyjmuje parametry wejściowe i zwraca wynik typu boolean. Nic nadzwyczajnego. Ale czy, aby na pewno?! Ile wokół nas kodu, w którym umieszczamy skomplikowane warunki bezpośrednio w ifie (i dobrze, jeśli stosujemy stałe z dobrze dobranymi nazwami, aby zrozumieć ich sens), a możnaby pokusić się o ich wyniesienie poza? To powoduje, że kiedy warunek trafi do zewnętrznej metody, może również trafić do oddzielnej klasy, a to już krok od wdrożenia zewnętrznej usługi, która pozwoli na dynamiczną zmianę wartości, na której działa warunek, co z nadchodzącymi parametrami wejściowymi wyliczy wynik. Może trochę przesadziłem z wynoszeniem warunku poza ramy klasy do zewnętrznej usługi, ale jeśli nie potraktujemy usługi jako czegoś spoza JVM, a np. klasy ze wzorcem Strategia, mamy piękne rozwiązanie, którego sens przyszło mi zrozumieć, bo...chciało mi się poznać kolejny produkt z półki, na którą wcześniej nie chciało mi się zaglądać - rozwiązania klasy Business Rule Management System (BRMS). Wszystko jakoś samo składa się w spójną całość.

Coraz częściej nachodzi mnie myśl, że najważniejszymi składowymi naszej technologicznej edukacji powinna być ciągła nauka rzeczy niezwykle podstawowych z mojego punktu widzenia - wzorce projektowe czy algorytmy, ale z umiarem, bez konieczności zgłębiania algorytmów, których zastosowanie nie przyjdzie nam wcale zasmakować (z wzorcami - wszystkie i dogłębnie). Myślę tutaj raczej o podejściu do nauki, której być może wartość nie docenimy bezpośrednio w projektach, ale podczas przygotowywania się do nich. Możnaby przyrównać to do przygotowywania się do zawodów sportowych, gdzie praktykuje się technikę, która raz wyuczona procentuje podczas samego starcia (w naszym przypadku podczas projektu).

Pamiętam rozmowę z pewnym doktorem na Uniwersytecie Warszawskim, któremu zadałem pytanie o te wszystkie podstawowe elementy edukacji uniwersyteckiej, gdzie często wiedza nie idzie z wymaganiem rynku. Zarabiamy w końcu na realizowaniu ich w drakońskich warunkach - mało czasu, ludzi i wiedzy, często nawet i wymagań klienta. Zyskują Ci, którzy wiedzą jaki szkielet aplikacyjny zastosować i to mogłoby wydawać się, że jest najbardziej cenione na rynku pracy. Za to się płaci, bo to konkretna wiedza. Tylko, czy osoba znająca rozwiązanie X będzie przygotowana do poznania i zrozumienia rozwiązania Y? Tu nie wystarczy wyłącznie chęć, ale i umiejętność znalezienia wspólnego mianownika, którym są właśnie rzeczy podstawowe - zastosowanie wzorców projektowych do obsługi danego problemu projektowego, co powinno wpłynąć pozytywnie na zrozumienie czegoś bardziej skomplikowanego. Właśnie ta umiejętność rozłożenia problemu na czynniki pierwsze jest dla mnie wielce pożądaną umiejętnością u specjalistów, których dążeniem jest poziom eksperta.

Stąd też podoba mi się podejście Chlebika, które charakteryzuje się rozpoznaniem technologii przez budowanie kompletnych aplikacji. Mam jednak wrażenie, że w takim podejściu brakuje wyznaczania technologii i szkieletów aplikacyjnych przez cechy wymagań funkcjonalnych. Nie potrafię jeszcze konkretnie nakreślić, czego mi tam jednak brakuje. Mam wrażenie, że jest to jedynie krok ku czemuś większemu, czegoś co nazwałbym wiedzą ekspercką. Posłużę się czymś bardziej namacalnym. Czy poznanie kolejnej specyfikacji z Java EE 6, np. Contexts and Dependency Injection for the Java EE Platform (CDI) przysłuży się czemuś? Tak. Czy poznanie JBoss Seam będzie miało ten sam aspekt poznawczy? W dużej mierze tak. A może wartoby zerknąć na Spring Framework czy Service Component Architecture (SCA)? Również tak. Wymaga to jednak wiele czasu. Mimo, że porównuję technologie (specyfikacje) do gotowych rozwiązań (szkieletów aplikacyjnych), to znalezienie wspólnego mianownika jest odpowiedzią na pytanie "Dlaczego?" i znaczenie uprości zrozumienie ich wszystkich, mianowicie wzorca Inversion of Control (IoC) czy konkretnej jego realizacji Dependency Injection (DI). I to jest sedno sprawy - zrozumienie IoC/DI to zrozumienie działania pozostałych. Czyż to nie budujące?! Reszta jest niczym więcej jak...złożeniem w imię uproszczenia obsługiwanej problematyki (często jednak z mizernym skutkiem).

p.s. Smutny dzień dzisiaj, po wczorajszej katastrofie lotniczej, więc może mnie ten nastrój i spacer Nowym Światem natchnął?! Warto przystanąć i zastanowić się czasem, czy to, co robimy, ma dla nas wartość. Wielce prawdopodobne, że w tej pogoni, kilka rzeczy robimy bezwiednie i niepotrzebnie. Bardzo nieprzyjemne uczucie, kiedy się tego dowiadujemy, jednakże paradoksalnie każdemu życzę doświadczyć tego przynajmniej raz - po chwili refleksji przychodzi radość, a tej nigdy za wiele.