TheTarPit

koszmar na jawie

Dla projektanta systemu informatycznego Java to całkiem przyjemne narzędzie, złego słowa nie powiem... Wystarczy opanować kilka klocków, patternów czy innych patentów i można poskładać z nich dowolnie skomplikowane rozwiązanie. Uwzględniając jeszcze fakt, że większość narzędzi CASE obsługuje kod źródłowy w Javie (i to również w zakresie reverse engineering) można ulec wrażeniu, że da się to zrobić stosunkowo łatwo. Dodatkowo odwołując się do kilku popularnych sloganów, np. o „niezależności od platformy”, można decydentom różnego szczebla sprzedać pomysł wykorzystania technologii Javy z etykietką „dobre rozwiązanie”.

Jednak z punktu widzenia programisty Java może bardzo łatwo stać się koszmarem. Problemu nie stanowi oczywiście sam język, tak bardzo podobny do większości współczesnych obiektowych języków heterogenicznych, tylko środowisko, otoczenie i styki najróżniejszych elementów. To wszystko razem się „muli” i zachowuje nieprzewidywalnie, a styki iskrzą aż miło. I to nie tylko z powodu nieumiejętności, niewiedzy, czy zwykłej ignorancji projektanta i/lub programisty, chociaż te elementy niemal zawsze występują i zazwyczaj szybko powodują krach wizji „dobrego rozwiązania”. Po prostu świat Javy taki już jest — przeładowany technologiami o najdziwniejszych akronimach, z setkami plików konfiguracyjnych w najróżniejszych zakamarkach, tysiącami opcji i milionami nie zawsze oczywistych zależności. Misterna konstrukcja, która aż się prosi o użycie jej jako ilustracji drugiego prawa Weinberga^[1].

Fakt, że można ten cały burdel elegancko rozrysować niewiele pomaga.. :-/

Komentarze