TheTarPit

parametryzacja

parametryzacja, a po co?

Problem jest stary, niemal tak stary jak systemy informatyczne w ogóle — użytkownik dla systemu czy system dla użytkownika?

Oczywiste jest, że każdy użytkownik systemu informatycznego ma swoje specyficzne wymagania. Im bardziej jakiś system "pasuje" jednemu użytkownikowi, tym bardziej "nie pasuje" innemu. Jeżeli użytkownik nie jest znany personalnie, system jest pisany "na półkę", czyli do sprzedaży komukolwiek, to można się łudzić, że przejdzie rozwiązanie "one size fits all". Jednak jeśli użytkownik = Klient Który Ma Nam Zapłacić, jeśli system jest robiony w odpowiedzi na zidentyfikowane, nazwane zapotrzebowanie, jeśli jest sprzedawany na podstawie konkretnych umów, a nie masowo w sklepie, to sytuacja zmienia się diametralnie. Wtedy Klient Ma Zawsze Rację^[1]. Jeżeli klientów (przynajmniej potencjalnie) jest kilku to niemal oczywiste jest, że każdy z nich ma inną Rację. A ponieważ każdy klient musi być szczęśliwy, to system musi być pisany równocześnie "pod" każdego z nich. Bez parametryzacji ani rusz.

to niby gdzie te parametry?

Parametryzacja oprogramowania może obejmować absolutnie wszystko i wyobrażam sobie, że można to podzielić na następujące poziomy:

1. rzeczy proste i stosunkowo niewielkie lub "personalne", dostępne jako opcje dla użytkownika aplikacji,
2. ustawienia bardziej globalne o zasadniczo poważniejszych konsekwencjach dla systemu jako całości, dostępne jako opcje administratora systemu,
3. ustawienia dokonywane raz (w zasadzie) na etapie wdrożenia systemu, np. dobór dostępnych modułów, wybór jednego z kilku alternatywnych algorytmów itp., dostępne dla ekipy wdrożeniowej, ale niezmienialne (wręcz nieistniejące) dla administratora systemu po wdrożeniu,
4. ustawienia istniejące tylko w czasie rozwoju aplikacji, np. różne konfiguracje kompilacji (DEBUG, RELEASE).

Z punktu widzenia projektu systemu najciekawsza wydaje się grupa trzecia, czyli konfiguracja systemu na potrzeby konkretnego wdrożenia/klienta.

parametryzacja systemu modułowego

Oprogramowanie modułowe jest dzisiaj standardem na tyle, że właściwie każdy duży a rozsądny system powinien się składać z "klocków" (że w praktyce tak nie jest, to w tej chwili nie jest istotne). Ich ilość i wzajemne interakcje zależą najczęściej bezpośrednio od tego, za co klient płaci — każde wdrożenie może przedstawiać inny zakres funkcjonalności i system w konfiguracji zawierającej wszystkie moduły może w praktyce nie występować nigdzie poza instalacją testową u producenta danego softu. Nie bez powodu zarządzanie konfiguracją jest osobną dziedziną inżynierii oprogramowania...

Jeszcze ciekawsze od samego włączania modułów systemu do konfiguracji docelowej wydaje się sterowanie ich specyficznymi zachowaniami. Skoro system ma być wdrożony np. u trzech różnych klientów, to nawet jeśli oficjalnie działają oni na podstawie tych samych wzorów, zasad czy przepisów, niemal na pewno znajdzie się kilka algorytmów, które u każdego klienta mają się zachowywać "lekko inaczej". Można oczywiście zrobić w takiej sytuacji trzy wersje danego modułu i podczas wdrożenia u każdego klienta zainstalować inną wersję. Jednak doświadczenie bardzo szybko uczy, że lepiej i bezpieczniej jest mieć zawsze jeden moduł, choćby parametryzowalny do granic możliwości, niż konserwować kod kilku "lekko różnych" wersji. Mimo, że nakład pracy na obsługę parametryzacji może się wydawać znaczny, to i tak jest o niebo mniejszy niż nakład na zachowanie spójności kilku wersji "prawie tego samego" kodu. W efekcie program obrasta w najróżniejsze warunki dodatkowe i ścieżki alternatywne. Zakładając, że tego typu parametryzacja jest określana na etapie wdrożenia systemu u danego klienta i nie podlega późniejszej modyfikacji (lub modyfikacja taka jest zmianą na tyle poważną, że uzasadnia zatrzymanie systemu), a równocześnie dobrze żeby nie wymagała rekompilacji, powinna być zapisana "z boku" i wykorzystywana na bieżąco w trakcie wykonania programu. Odpowiedź na pytanie "gdzie i jak zapisać takie parametry" jest w dzisiejszych czasach całkiem prosta — XML.

Wybór XML-a do parametryzacji szczegółowych zachowań systemu lub jego modułów może być dyskusyjny, ale najczęściej wygrywa z jednego, jedynego powodu — XML jest aktualnie najbardziej sexy. Jest to powód niemal irracjonalny, ale szczery. To zadziwiające jak banalny plik tekstowy, w jednym z miliarda możliwych formatów, może zrobić karierę Rozwiązania Na Każdą Okazję, ale faktem jest, że robi^[2].

łatwo przesadzić

W pewnym systemie portalowym, który znam, niemal wszystko zależy od zapisów w pliku o ładnej nazwie config.xml. W momencie kiedy weszliśmy w ten projekt, cała obsługa dostępu do danych była wykonywana przez tylko dwie strony aspx — jedna dla "prostej tabeli" z ewentualnymi relacjami "jeden do wielu" i druga dla relacji "wiele do wielu". Tymi dwoma stronami było obsługiwane 90% systemu składającego się z mnóstwa tabel i mnóstwa relacji — w XML-u było zapisane praktycznie wszystko — począwszy od menu, aż po zapytania SQL.

Taką sytuację właściwie trudno nazwać parametryzacją — XML zawierał nie tyle opis dostosowania systemu do specyficznych potrzeb danego klienta (chociaż to też), ale opis niemal wszystkiego, co system robi. Większości zapisów w takiej "konfiguracji" nie dało się zmienić bez szkody dla działania systemu jako całości. Zysk oczywiście jeden - kilka klas ogólnych zamiast mnóstwa klas specjalizowanych, oraz poczucie, że "potrafimy tutaj pokazać każdą tabelę w ogóle nie ruszając kodu". Wada - pewnie wolniej, niż mogłoby być, gdyby każda strona miała swoje konkretne przeznaczenie.

System ten w takiej postaci nie wytrzymał próby czasu. Powstało jeszcze kilka innych stron do obsługi innych przypadków ogólnych (okazało się, że jednak nie wszystko da się sprowadzić do pojęcia "jedna tabela" lub "relacja") oraz kilka stron ściśle przeznaczonych do konkretnego zadania. Niemniej jednak ten config.xml istnieje, ma się dobrze i ... puchnie. Aktualnie większość tego pliku to zapisy ważne dla całości systemu, zrównane praktycznie z kodem źródłowym, a tylko niewielka część dotyczy "dostrojenia" do specyfiki wymogów konkretnego wdrożenia. System bez tego pliku nie istnieje, a "konfiguracji domyślnej" nie może w ogóle być mowy.

Taki przerośnięty XML wydaje się już jakby mniej sexy...

Komentarze

Brak komentarzy do tego wpisu.