Wpis filozoficzny.

Na początek taki dobry news. devMedia uruchomiło serwis meta.devMedia, w którym można „obgadywać” różne pomysły czy zgłosić bugi. To ostatnie też i zrobiłem. W toku dyskusji i dzisiejszych wydarzeń w fabryczce zostałem natchniony do napisania tego posta.

Konfiguruj co się da

Ta stara prawda jest zawsze aktualna. Nie ważne czy robisz projekt dla siebie czy dla klienta. Musisz postarać się o maksymalną elastyczność aplikacji. Żadnych magicznych numerów, żadnych zaszytych tekstów czy opcji. Zignorowanie tego prowadzi do sytuacji w której przed zmianą systemu z testowego na produkcyjny musisz przerabiać część kodu by dokonać rekonfiguracji.
Przykład z życia. Dawno temu system, którym się opiekuję był sobie napisany w COBOLu. Jednym z elementów systemu jest podpisywanie plików oraz ich szyfrowanie. Dawno temu w tym celu używano dedykowanej biblioteki i infrastruktury. Czasy się zmieniły wszedł podpis w obecnej postaci, a w COBOLu podmieniono jedną jednostkę kodu. W jednostce tej zaszyto adres serwera z certyfikatami. Zmiana tego adresu była stosunkowo prosta, bo podmieniano flagę systemową. Trochę później całość została zmigrowana na Javę, a wartość flagi przeniesiono do javy w ten sposób, że na sztywno wbito adres w kod. Obecnie osoba odpowiedzialna za testy jak chce coś sprawdzić to podmienia kawałek kodu, kompiluje i wrzuca nowego jara na serwer. Czas operacji… do 10 minut jak uruchomi testy. I tak za każdym razem…
Ostatnio padła propozycja parametryzacji tej opcji. Pojawił się jednak trochę inny problem.

Gdzie trzymać konfigurację

Konfigurację można podzielić, moim zdaniem, na dwa niezależne zbiory. Konfigurację systemową i konfigurację roboczą.

konfiguracja systemowa

Jest to ta część konfiguracji, która określa środowisko pracy aplikacji. To tu definiujesz dane dla połączenia z bazą danych, adresy kluczowych usług zdalnych czy inne elementy ważne z punktu środowiska pracy aplikacji (strefa czasowa, kodowanie itp.).
Konfigurację tą należy przechowywać w miejscu łatwo dostępnym (dla zainteresowanych, a nie wszystkich!!!) i co ważne łatwo edytowalnym. Narzędzie obsługujące tą część konfiguracji powinno być wstanie dokonać rekonfiguracji systemu. Nie zawsze się to da zrobić. Względnie jest to trudne (np. rekonfiguracja JPA „w locie”). W każdym bądź razie ta część konfiguracji powinna zawierać elementy rzadko zmieniane. Najlepszym miejscem na tą konfigurację są pliki properties/xml. Baza danych odpada, bo tu siedzi m.n. konfiguracja połączenia z bazą.

konfiguracja robocza

W tej części konfiguracji umieszczamy wszystkie te elementy, które często się zmieniają, są opcjami systemu lub dostęp do nich powinien być realizowany przez bazę danych. Oczywiście należy zwrócić uwagę na sposób dostępu do tych danych. Najwygodniejsza jest baza danych we specjalnie przygotowaną tabelą, w której utrzymujemy możemy utrzymywać nie tylko aktualną konfigurację, ale też np. słowniki konfiguracyjne. Co nadaje się do tej konfiguracji? Język, formaty danych liczbowych i dat, konfiguracja pluginów jeżeli takie występują.

Świetnym przykładem jest takiej dwuelementowej organizacji jest WordPress, gdzie podstawowe informacje o połączeniu z RDBMS trzymane są w pliku, a cała reszta w postaci flag w bazie danych.

Pseudokonfiguracje

Pod tym pojęciem rozumiem elementy systemu, które choć są konfigurowalne to ich rekonfiguracja oznacza zazwyczaj tworzenie nowej aplikacji lub dostarczenie całkowicie nowej funkcjonalności.
Po pierwsze konfiguracja DI, czyli różne application-context.xml, ejb.xml i inne tego typu pliki. Powiedzmy sobie szczerze jeżeli zmieniamy jakąś klasę to chcemy mieć inną aplikację, a nie tą samą aplikację tylko inaczej skonfigurowaną. Przypomina to sytuację zmiany lakieru, silnika lub tapicerki w samochodzie. Jest to ta część konfiguracji, której zmiana powinna wiązać się z procesem wypuszczenia nowej wersji.
Po drugie konfiguracja słowników i i18n. To nie jest konfiguracja, a po prostu sposób dostarczenia wielu wersji językowych.

Konfiguracja użyszkodników

Jeżeli do aplikacji dopuszczasz szerokie grono użytkowników to pamiętaj, że będą oni chcieli mieć własne ustawienia. To też nie jest konfiguracja, ale pewna funkcjonalność serwisu, której implementacja jest zależna od tego na co chcemy pozwolić użyszkodnikowi.

tyle na dziś.