Spirale, iteracje, przyrost

Tradycyjne metody wytwarzania oprogramowania, dobrze zilustrowane modelem kaskadowym i (pojedynczym) modelem "V", nie radziły sobie z projektami zbyt wielkimi ani ze zmiennością wymagań, ani z koniecznością bardzo szybkich dostaw choćby zrębów nowej funkcjonalności.

Stąd pojawiły się różne metodyki (spiralna, iteracyjna, przyrostowa - przy czym określenia te nie są ani precyzyjne, ani rozłączne), pozwalające budować systemy i aplikacje niejako "po kawałku". Wprawdzie sprawiają one wiele kłopotów (komplikują organizację projektów, narzucają konieczność rozbudowanych testów regresji, czyli wielokrotnego ponownego testowania funkcji już przetestowanych), ale pozwalają skuteczniej niż metodyki tradycyjne wykorzystać elastyczność materii oprogramowania, która - pod warunkiem stworzenia odpowiednio elastycznej architektury - pozwala majstrować przy fundamentach nawet wtedy, gdy na górze położony jest już dach.

Metodyki przyrostowe pozostaną i rozpowszechni się ich zastosowanie. Zapewne zaczną pojawiać się narzędzia, ułatwiające dobór odpowiedniej metodyki do założeń projektowych, oraz narzędzia wspierające przekład wymagań (opisanych w formie modelu) na architekturę, tak, by architektura wspierała przyrostową organizację projektu. Nie można wykluczyć, że pewne narzędzia umożliwią automatyczne generowanie zarysu wstępnej organizacji projektu na podstawie wymagań dotyczących produktu.

Szybko, zwinnie, ekstremalnie

Słowa rapid, agile oraz extreme pojawiają się dziś wszędzie. Jaskrawym przykładem był wykład na konferencji EuroSTAR 2004 pt. Agile Inspections, co może się kojarzyć z "demokracją socjalistyczną": z definicji albo coś jest "zwinne", albo jest "inspekcją".

Podobnie jak Japończycy odkryli w latach 60. i 70., jak produkować to samo, co przemysł amerykański, tylko szybciej, elastyczniej i taniej, tak metody "zwinno-ekstremalne" usiłują znaleźć antidotum na wszelkie prawa Murphy'ego: rozrastanie się dokumentacji i zawiłych procedur, celebrowanie czynności, szukanie poczucia bezpieczeństwa w nadmiernie dokładnej analizie, niechęci do wystawiania się na ryzyko przez podejmowanie decyzji, dostarczanie kolejnych prototypów zamiast konkretnych produktów itd.

Wszystko to jest bardzo słuszne i należy mieć nadzieję, że te tendencje nie zanikną, lecz okrzepną i dojrzeją. Na przykład metodyka XP (eXtreme Programming) składa się dziś z całej serii bardzo dobrych metod, ale jednocześnie prozelici XP objawiają w swych publikacjach niemal religijne zacietrzewienie. Gdyby zastąpić tę nieco dziecinną zajadłość opisem sposobów, jak z korzyścią wdrażać wybrane elementy XP i jak dostosować poziom "ekstremalności" do wymogów produktu i projektu, zachowałoby się to, co w XP wartościowe, jednocześnie czyniąc metodykę łatwiejszą do zastosowania w praktyce. Tak więc znów powracamy do wcześniejszego wątku "metaprocesów": za 10 lat powinniśmy mieć do dyspozycji metaprocesy, pozwalające na wybór lub dostosowanie procesów wytwarzania do rodzaju produktu i wymagań projektu.

Języki programowania

"Język myślom kłamie" - w pewnym sensie niezmienne od 50. lat problemy programistów przypominają odwieczne kłopoty pisarzy i poetów - jak trafnie oddać za pomocą słów to, co gra w duszy, tak, by odbiorca trafnie rzecz zrozumiał?

Z programowaniem były i są trudności jeszcze większe niż z pisaniem wierszy: odbiorca (procesor) jest pozbawiony intuicji i jakichkolwiek informacji uzupełniających. Dlatego program sterujący jego działaniem musi być kompletny i jednoznaczny, nie zezwala na żadne luki i niejasności, na które możemy sobie pozwolić w słownej komunikacji z innymi ludźmi.

Z kolei programowanie jako działanie inżynierskie różni się od inżynierii "tradycyjnej" tym, że produkt jest niewidzialny, a jego funkcje nie dają się łatwo zilustrować planami czy schematami.

Z tymi problemami od dawna borykają się konstruktorzy języków programowania. Można tu wyróżnić kilka równoległych trendów.

Oddalanie programu od zestawu instrukcji mikroprocesora, a przybliżanie do zagadnienia, które ma rozwiązywać. Droga prowadziła od asemblerów, poprzez języki wyższego rzędu, języki strukturalne, a potem języki 4. generacji i języki obiektowe.

Nie brakowało ślepych uliczek: kto dziś pamięta "COBOL", który miał umożliwić pisanie programów dających się czytać i rozumieć niemal niczym języki naturalne, a zaowocował rozgadanymi, mętnymi potworkami? Kto pamięta "Modulę", mającą uporządkować interfejsy i umożliwić kontrolowany eksport i import informacji? Kto pamięta modę na języki "4. generacji", będące raczej językami do opisu specyfikacji działania, z których kod właściwego programu był generowany automatycznie, co miało stanowić skuteczną ochronę przed chronicznymi błędami implementacji?

Wszystkie te efemerydy zostały najpierw wyparte przez bałaganiarski i niebezpieczny, ale za to elastyczny język "C", a z drugiej strony skuteczne natarcie przeprowadziły języki obiektowe i cała idąca ich śladem ideologia "obiektowego" projektowania systemów.

Niektóre cechy języków obiektowych są niewątpliwie korzystne (dziedziczenie, ukrywanie informacji, dynamiczne łączenie), inne kłopotliwe (dynamiczne łączenie ogranicza możliwości testów statycznych, dziedziczenie stwarza niejasne, ukryte zależności i zwiększa zakres wymaganych testów regresji), inne nie mają nic wspólnego z obiektowością (np. niezależność Javy od platformy dzięki JVM), jeszcze inne wreszcie są wątpliwej wartości "psychologizowaniem" (myślenie "obiektowe" ma jakoby być bardziej "naturalne" dla ludzi).

Trudno w tym wszystkim znaleźć jakiś wyraźny trend, pozwalający przewidywać, jak potoczy się ewolucja języków programowania.