Programista RAD czy nierad?

Nowe narzędzia eliminują ręczne kodowanie aplikacji. Czy wyeliminują programistów?

Nowe narzędzia eliminują ręczne kodowanie aplikacji. Czy wyeliminują programistów?

W ciągu ostatnich kilku lat dokonała się duża zmiana w podejściu do tworzenia oprogramowania. Wysiłki zmierzały w stronę znacznego ułatwienia kodowania, czyli pisania kodu źródłowego programu i tworzenia interfejsu, tak by programista mógł skupić się tylko na wdrożeniu pewnych zagadnień i projektowaniu aplikacji. Z upływem czasu stało się jasne, że należy także w maksymalnym stopniu wyeliminować konieczność kodowania znanych algorytmów czy procedur realizujących złożone operacje. Było to możliwe dzięki oswojeniu się programistów z technologią obiektową, która znacznie ułatwia łączenie w projekcie elementów pisanych przez różne osoby, a także dzięki rozwiniętemu rynkowi komponentów - czyli pewnego rodzaju gotowych półfabrykatów, które można było wykorzystywać w innych programach.

Tak więc wydaje się, że informatykowi zostało już tylko projektowanie aplikacji (a przecież istnieją narzędzia, ułatwiające analizę projektu).

Czy za pewien czas nie okaże się, iż programistą może być każdy, a tylko nieliczne grupy będą tworzyć komponenty dla innych? A może w ogóle rola człowieka zostanie ograniczona tylko do postawienia wymagań co do programu, a resztę wykona pracowity komputer?

Jednak patrząc na dzisiejszy stan narzędzi typu RAD, można nie obawiać się, że rola "koderów" i informatyków będzie ograniczona lub będą oni zastąpieni nisko wykwalifikowanymi "technikami".

Początkowo narzędzia RAD miały ułatwiać tylko tworzenie interfejsu. Bez nich była to operacja dosyć żmudna i czasochłonna. Jednak po pewnym czasie okazało się, że narzędzia, które najpierw były prostymi generatorami kodu stały się złożonymi pakietami, których nauka trwała znacznie dłużej niż języków programowania. Proszę przyjrzeć się chociażby liczbie właściwości i metod dowolnego niemal komponentu czy całej hierarchii obiektów w MFC, Visual Basicu, Javie czy Delphi. Natychmiast pojawiły się oczywiście specjalne programy - przeglądarki klas czy możliwość automatycznego wyświetlania listy metod obiektu; jednak nadal należy poświęcić dużo czasu, by poznać i efektywnie wykorzystywać dowolny pakiet narzędziowy RAD.

Równocześnie okazało się, że narzędzie narzuca sposób tworzenia aplikacji i jej działania. Tak więc programista stawał często przed następującym problemem: w jaki sposób zmusić narzędzie, by powstały program odpowiadał jego potrzebom (proszę spróbować utworzyć niestandardowy interfejs użytkownika w narzędziu RAD: wymaga to znacznie więcej wysiłku niż tworzenie go w C).

Drugą rewolucją, jaką przyniosły narzędzia RAD (głównie narzędzia bazodanowe i VB), technologia obiektowa i korzystanie z komponentów, jest fakt, że są coraz większe wymagania sprzętowe do środowiska, w którym program jest pisany, a także dla końcowego użytkownika. Sporo jest tu winy samych programistów. Trudno znaleźć osobę, która zastanawiałaby się, jak np. zrealizowana jest kolekcja, czy jaki jest algorytm haszowania w danym komponencie. Także prawie nikt nie zastanawia się, jak oszczędzać pamięć. A przecież źle dobrany algorytm w zdecydowanie większym stopniu wpłynie na prędkość działania programu niż to, czy dany RAD generuje lepszy czy gorszy kod. Można tu w pewnym sensie usprawiedliwiać programistę, bo gdy stosunek ceny do szybkości procesora maleje, a pamięć (zarówno operacyjna, jak i dyskowa) jest coraz tańsza, to takie rozważania po prostu nie opłacają się - najważniejsze jest to, że program musi być napisany w krótkim czasie.

Trzecia sprawa jest związana z poprawnością narzędzia. Dowolny pakiet RAD jest bardzo złożony (i chyba nie ma bezbłędnego programu). Równocześnie RAD musi przechowywać wiele informacji związanych z wyglądem aplikacji, obsługiwanymi zdarzeniami itp. Co stanie się, gdy w razie awarii narzędzia ta informacja zostanie utracona? Tylko w niewielu pakietach zdecydowano się na to, by te informacje były przechowywane w całości w oddzielnych plikach. Zwykle (dotyczy to zwłaszcza narzędzi RAD dla C++, Javy czy Pascala) w kodzie programu były umieszczane specjalne znaczniki (w formie komentarzy), które pozwalały działać środowisku IDE. Dobrym przykładem jest tu Blue Sky's Visual Programmer, który, oprócz specjalnych komentarzy, tworzy złożoną hierarchię wzajemnie dołączanych plików. Wszystkie te zmiany w kodzie powodowały, że to co RAD tworzył było niezbyt czytelne. Ponadto programista musiał być bardzo ostrożny w modyfikacji kodu - wystarczyło przecież przez pomyłkę usunąć kluczowy komentarz.

Dopiero niedawno zaczęły pojawiać się narzędzia RAD (np. JBuilder), które miały na tyle wyrafinowany (początkowo, niestety, niezbyt szybki) analizator kodu, że nie wymagały dodatkowych plików i na bieżąco na podstawie plików źródłowych określały np. wygląd okna dialogowego.

Narzędzia RAD nie ułatwiają tworzenia interfejsu użytkowego w językach narodowych. Jednym z nielicznych "spolszczonych" narzędzi RAD jest Visual Fox Pro w wersji 3.0. Natomiast w innych narzędziach rola kreatorów, które automatycznie tworzą interfejs, jest ograniczona - potem programista musi pracowicie tłumaczyć wszystkie teksty, sprawdzać, czy na pewno postać daty lub sposób sortowania będzie zgodny z wymaganiami polskiego klienta.

Przyszłość

Na pewno nie ma już odwrotu od technologii obiektowej. Nie ma ona konkurencji, jeśli chodzi o wygodę i porządkowanie programu. Co prawda program obiektowy jest zwykle trochę wolniejszy i większy niż jego odpowiednik "strukturalny", ale obecnie nie ma to już większego znaczenia. Równocześnie okazało się, że w modelu obiektowym można bardzo łatwo projektować - pojawiły się nawet narzędzia, które symulują projektowanie przy użyciu kart CRC (Class Response Collaborator) lub pozwalają utworzyć projekt bazy danych, a następnie tworzą szkielet programu (w dowolnym języku). Potem pozostaje już tylko zaprojektować interfejs i napisać program. Wydaje mi się, że z czasem nastąpi silna integracja między narzędziem do projektowania a narzędziem RAD. Na razie pewna trudność wynika z faktu, że bazy danych mają różne właściwości i czasami, przy wyspecjalizowanych przypadkach, warto do danego motoru bazy danych nieznacznie zmodyfikować projekt.

Trzeba też zastanowić się, czy nastąpi dalszy rozwój języków programowania. Obecnie dominują różne języki bazodanowe (część zgodna jest nawet z Clipperem), np. C++ i Java. Java jest chyba najlepszym językiem programowania, teoretycznie zapewniającym nawet przenośność. Jednak do działania potrzebuje maszyny wirtualnej, a co więcej, łatwo napotkać na program, który do poprawnej pracy będzie wymagał specyficznej maszyny. Równocześnie producenci kompilatorów Javy dodają własne niewielkie rozszerzenia do języka. Spowodować to może kłopoty przy próbie ich uruchamiania w innym środowisku.

Jako idealny pakiet RAD wyobrażałbym sobie taki program, który miałby przejrzystą i dobrze udokumentowaną strukturę obiektów (najlepszy byłby typ obiektów Javy z możliwością definiowania operatorów z C++), automatyczny (i łatwy) podgląd metod obiektu, który właśnie występuje w pisanym kodzie programu, a także prosty dostęp do bazy danych.


TOP 200