Zmienność - istota systemu informatycznego

4. Zmiana technologii

Na przykład klient wcześniej miał działającą aplikację na sieci Novell, a teraz chciałby mieć ją na Unixie, bo wdrożył go przy okazji zastosowania innego produktu i chciałby zmniejszyć koszty sprzętu oraz szkoleń. Zmiana technologii wiąże się z przeniesieniem źródeł programu do nowego środowiska i przebudowaniem ich w nim z użyciem nowych narzędzi. Nie można na tym etapie wskazać, jak trudne miałoby być takie przeniesienie, bowiem wszystko zależy od tego, na ile pokrewna jest stara i nowa technologia. Czasem zmiana technologii oznacza napisanie produktu od nowa, a czasem wymaga tylko napisania make i przeniesienia pliku wykonywalnego na docelowy komputer.

Zmian technologii najczęściej dokonujemy sami, aktualizując wersję środowiska programistycznego, bazy danych czy biblioteki komponentów graficznych. Zapewne każdy wie, że o złożoności takiej zmiany niewiele konkretnego da się powiedzieć: może ona wymagać zarówno jednej chwili, jak i długich tygodni. Zanim więc wprowadzi się zmianę technologii w aplikacji, należy dokładnie poznać konsekwencje, najlepiej poprzez projekt pilotażowy (czyli małe zadanie, które zmieni tę technologię w małym, wybranym fragmencie systemu).

5. Zmiana komunikacji

Ze zmianą komunikacji mamy do czynienia wtedy, gdy klient jest zadowolony z funkcjonalności i wydajności aplikacji, chciałby jedynie zmienić dialog z użytkownikiem. Wiele osób przeżyło już taką zmianę, przenosząc swoje aplikacje w ostatnich latach na systemy okienkowe. Jeżeli analizując zakres modyfikacji w systemie związanym ze zmianą komunikacji dojdzie się do wniosku, że należy zmienić komponenty zajmujące się logiką aplikacji (nie zaś prezentacji), to znaczy, iż system był źle zaprojektowany. Jeżeli został zaprojektowany porządnie, tj. z użyciem paradygmatu MVC, to zmiana komunikacji powinna mieć znikomy wpływ na logikę aplikacji. Generalnie zmiana komunikacji w dobrej aplikacji powinna być prosta.

Jak przewidywać nieprzewidziane?

Świat jest pełen jasnowidzów, telepatów, chiromantów, astrologów i innych szarlatanów, którzy twierdzą, że potrafią przewidywać przyszłość. Jakoś nie słyszałem, aby któryś wziął się za grę na giełdzie, co niewątpliwie przyczyniłoby się do najefektywniejszego wykorzystania jego talentów; bardzo chętnie za to doradzają innym, wykluczając wcześniej explicite jakąkolwiek odpowiedzialność za nietrafne przepowiednie

Dobrą wiadomością jest to, że informatycy znają się na dziedzinie, której przyszłość muszą przewidywać. Złą, że sami ponoszą konsekwencje swoich błędów w przepowiedniach. Zaczynając tworzyć system informatyczny, szczególnie gdy jest on rozbudowany i prace nad nim mogą zająć miesiące czy wręcz lata, trzeba zabawić się w jasnowidza. W chwili zakończenia systemu rzadko będzie bowiem można stosować te same technologie, które były stosowane w chwili rozpoczęcia pracy. Z bardzo dużym prawdopodobieństwem można się spodziewać, że:

będą dostępne szybsze komputery

będzie dostępna większa pamięć operacyjna i masowa

standardy komunikacji z użytkownikiem będą szły w kierunku przyjazności i ergonomii

będzie się rozszerzać znaczenie współpracy komputerów w ramach sieci lokalnych i rozległych.

Można być za to pewnym, że:

praca informatyka nie stanieje gwałtownie

informatyka pozostanie dziedziną trudną i nie pojawi się żadne cudowne narzędzie ani technologia tworzenia doskonałych programów

programy nadal trzeba będzie rygorystycznie konstruować, rzetelnie programować i solidnie testować.

Reszta jest niewiadomą. Jednak istnieje coś takiego jak trendy na rynku informatycznym. Jest wiele czasopism przeznaczonych dla naszej profesji, które publikują badania analityków rynku. Warto się im przyjrzeć i spróbować określić swój produkt w ich kontekście. Na przykład, jeżeli IBM ogłasza, że udało mu się upakować gigabit na niemożliwie małej powierzchni, to wypada zastanowić się, czy warto dziś inwestować w zmniejszenie wymagań pamięciowych aplikacji, czy raczej w chwili wprowadzenia produktu na rynek te dodatkowe (tu wpisać jednostkę pamięci obowiązującą w chwili czytania tej książki) będą miały jakiekolwiek znaczenie. Jeżeli zapisane jest, że - zdaniem IDC - nowy system operacyjny Microsoftu będzie faktycznie miał tzw. load balancing, czyli optymalne dystrybuowanie aplikacji po komputerach połączonych w sieć, w celu osiągnięcia maksymalnej wydajności, to warto dobrze się zastanowić, czy zamiast centralnego serwera zastosować klaster komputerów PC.

Nie muszę chyba przekonywać, że opinie pochodzące z firm w jakiś sposób zainteresowanych sukcesem danej technologii, produktu czy rozwiązania są bezwartościowe. To oczywiste, że IBM zawsze będzie twierdził, iż będą liczyć się tylko "wielkie" komputery, a Microsoft, że tylko architektura PC i system Windows odniosą sukces. O przyszłości decydują jednak odbiorcy produktów informatycznych, nie ich producenci.