Dlaczego warto stosować standardy?

Wstęp

W dzisiejszym artykule odniesiemy się do naszych osobistych doświadczeń ze standardami, w szczególności standardem D4P (Dita 4 Publishers). Pokażemy na żywym organizmie, dlaczego standardy są przydatne i dlaczego wymyślanie koła po raz kolejny, choć satysfakcjonujące, z reguły nie jest najlepszym rozwiązaniem.
Jednym z flagowych produktów stworzonych przez naszą firmę jest system wydawniczy XMLOGOS, który organizuje, wspomaga i strukturyzuje treści tworzone przez wydawnictwo. W toku jego tworzenia wdepnęliśmy na każdą minę, na którą potencjalnie mógłby kiedyś wejść wydawca. W proces projektowania i tworzenia tego oprogramowania włożyliśmy wszystkie nasze doświadczenia zdobyte na rynku wydawniczym i obszerny feedback od wydawców.

Baza danych

Restrukturyzowaliśmy bazę danych dwadzieścia trzy razy, by wyjść naprzeciw kolejnym wyzwaniom, umożliwić dodawanie, usuwanie, edytowanie i zamienianie miejscami elementów po ich wyeksportowaniu. Powstała w efekcie baza jest dość skomplikowanym, ale wydajnym i oferującym szerokie możliwości narzędziem zdolnym do przechowywania treści w wielu formatach. Droga do jej stworzenia była usiana problemami, koniecznością zawieszania coraz większej liczby danych i metadanych na poszczególnych polach. Każda kolejna wersja pociągała za sobą konieczność dokonania zmian w interfejsie, testów ergonomii i kolejnych poprawek.
W efekcie, stworzenie centralnego elementu programu zajęło nam dużo czasu, wymagało bardzo dokładnej analizy i testów. Wraz z rosnącym poziomem skomplikowania, rosła też liczba zależności, czyli innych elementów, które odnosiły się do samej bazy danych. W związku z tym każda, nawet niewielka poprawka pociągała za sobą konieczność sprawdzania coraz większej liczby funkcji, żeby upewnić się, że wszystko działa poprawnie.

Eksporty i programy, które współpracować po prostu nie chcą

„Żaden plan bitwy nie przetrwa pierwszego kontaktu z przeciwnikiem” – ta wojenna maksyma sprawdza się idealnie w projektach informatycznych, zwłaszcza tych skomplikowanych. Nie mogliśmy wzorować się na żadnych wcześniejszych rozwiązaniach, ponieważ tworzony przez nas standard był całkowicie autorski. Ponieważ każda treść jest warta tyle, ile da się z niej wyciągnąć na etapie końcowego produktu, kwestia eksportorów i kompatybilności z maksymalnie dużą liczbą urządzeń i programów była dla nas aspektem kluczowym. I tu zaczęły się schody.
Okazało się, że cały szereg programów (w tym miejscu chciałbym w szczególności pozdrowić firmę Adobe) pod pewnymi aspektami nie jest zgodnych z własną specyfikacją, pod innymi z całego szeregu równorzędnych rozwiązań akceptuje tylko jedno, a pod jeszcze innymi po prostu nie akceptuje żadnego. Do dziś pamiętam konsternację zespołu, kiedy skończyliśmy proces przekształcania tabel w XML do postaci akceptowalnej przez InDesign. Tworzyliśmy go według specyfikacji Adobe i na podstawie plików eksportowanych przez sam program. W efekcie tabele za nic w świecie nie chciały się poprawnie zwizualizować. Okazało się, że dotyczyło to nawet tabel wyeksportowanych z samego InDesign.
Prace nad eksporterem trwały miesiącami i pod pewnymi względami trwają do dzisiaj, bo każda zmiana wersji któregoś z programów pociąga za sobą konieczność dostosowania przekształceń tak, by spełniały nowe, nierzadko zagadkowe wymogi.

Komunikacja podstawą sukcesu

Dopóki nie stworzymy AGI (Artificial General Intelligence) mamy do dyspozycji dwa rodzaje programów: te, które spełniają konkretną funkcję i te, które robią wszystko, czyli nic. Czasy, w których liczbę linii kodu poszczególnych programów liczyło się w tysiącach, przeminęły bezpowrotnie. Ogrom powiązań i wzajemnych oddziaływań pomiędzy poszczególnymi modułami i funkcjami programów sprawia, że rozwiązania, które w założeniu mają spełniać wszystkie potrzeby odbiorcy, w praktyce nie są dostatecznie elastyczne, za to z reguły zdecydowanie zbyt skomplikowane, żeby dało się z nich wydajnie korzystać. Dlatego programy stworzone w celu rozwiązania konkretnego, nieprzesadnie szerokiego problemu, dają znacznie lepsze rezultaty. Pod warunkiem, że potrafią się komunikować.
Tworząc XMLOGOS założyliśmy, że komunikacja będzie przebiegać za pośrednictwem konkretnych, popularnych protokołów, ale nie oparliśmy ich o żaden uznany standard. Można zatem powiedzieć, że rozmawiamy w popularnym języku, ale o autorskiej składni, więc stworzenie modułu komunikacji wymaga dodania odpowiedniego tłumacza. Kierowaliśmy się najlepszymi praktykami. Stworzyliśmy odpowiednią specyfikację i zastosowaliśmy najlepsze protokoły. W związku z tym można śmiało powiedzieć, że spełniamy wszystkie wymogi, a sam program można bardzo prosto skomunikować właściwie z czymkolwiek bez większych nakładów pracy. Wystarczy specyfikacja drugiej strony, kilka godzin pracy i wszystkie potrzebne informacje zaczynają płynąć.

I wtedy nagle…

Zainteresował nas standard D4P. Wcześniejsze podejścia do samego standardu DITA dawały mieszane rezultaty ze względu na to, że został stworzony raczej pod kątem przemysłu niż wydawców. Znacznie ładniej i szybciej układał instrukcje obsługi, katalogi czy cenniki, ale o wiele gorzej radził sobie ze skomplikowanymi projektami wydawniczymi. Okazało się jednak, że przy pewnej wytrwałości i odpowiednio dużym zespole, dało się z niego stworzyć rozwiązanie dedykowane rynkowi wydawniczemu.
W projektowaniu i tworzeniu XMLOGOS korzystaliśmy z naszego, całkiem niemałego doświadczenia. Trzydzieści lat istnienia na rynku wydawniczym stanowiło bardzo dobry punkt wyjścia. Dawało nam dostatecznie dużo wiedzy nie tylko o standardach, ale też wyjątkach i nietypowych sytuacjach, by stworzyć rozwiązanie odpowiednio elastyczne i przystosowane do potrzeb bardzo konkretnego odbiorcy, jakim jest dom wydawniczy.
W efekcie okazało się, że rozwiązaliśmy praktycznie wszystkie problemy, które rozwiązuje D4P, ale w wielu przypadkach w inny sposób. Na przykład problem układania elementów w obrębie publikacji i konieczności ich okazjonalnej zamiany rozwiązaliśmy systemem podwójnego szeregowania w bazie danych – każde pole jest układane według podwójnego klucza. Pierwszy jest nadwany przez system, a drugi pozostaje do dyspozycji użytkownika. Zatem jeśli trzeba wstawić jeden element miedzy dwa już istniejące, np. między trzeci i czwarty, wystarczy nadać mu numer 3.1. Dita 4 Publishers rozwiązuje ten problem inaczej – nie numeruje elementów w ogóle, za to do pliku dołącza mapę, która stanowi zewnętrzny spis treści. Ten spis można wygenerować na wyjściu, żeby ustrukturyzować dokument i później drugi raz, na wejściu, żeby uwzględnić wszystkie poprawki i zamiany wykonane poza bazą danych. Oba rozwiązania dają podobny efekt, ale trzeba uczciwie przyznać, że D4P rozwiązało ten problem w nieco bardziej elegancki sposób. Podobnych przypadków są dziesiątki.

Efekt końcowy

W efekcie postanowiliśmy przerobić XMLOGOS tak, by spełniał wszystkie wymogi D4P. Uważamy, że ten standard będzie się rozwijał i będzie przyjmowany przez kolejnych producentów oprogramowania skierowanego do wydawców. Dzięki temu komunikacja nie będzie wymagała dodatkowych narzędzi i specyfikacji. Ze względu na fakt, że standard będzie rozwijał się w oparciu o doświadczenie nie jednej firmy, lecz setek wydawców i innych podmiotów rynku wydawniczego korzystającego z niego na co dzień, można się spodziewać, że będzie odpowiadał na kolejne pojawiające się wyzwania.
W efekcie wymyśliliśmy standard, z którego jesteśmy bardzo dumni i uważamy, że spełnia wszystkie potrzeby domów wydawniczych, niezależnie od ich specjalizacji. W tym samym czasie powstało równorzędne rozwiązanie, które, przynajmniej naszym zdaniem, z czasem zdobędzie dominującą pozycję na rynku. Dlatego zamiast kontynuować i rozwijać własny standard, postanowiliśmy wdrożyć Dita 4 Publishers. Będzie się to wiązało z zasadniczymi zmianami w naszym oprogramowaniu i wielu godzin pracy zespołu programistycznego. Wierzymy jednak, że w efekcie powstanie rozwiązanie lepsze i bardziej kompatybilne od tego, które stworzyliśmy własnymi siłami w oparciu o własne doświadczenia.
Dlatego tak często podkreślamy, że przed wdrożeniem czy tworzeniem jakiegokolwiek oprogramowania należy sprawdzić, czy nie ma już gotowego rozwiązania o podobnych funkcjonalnościach. W naszym przypadku standardy powstawały równolegle, ale w wielu innych rozwiązaniach, niekoniecznie w postaci gotowego oprogramowania, są już dostępne na rynku. Każdy standard zawiera co najmniej specyfikacje w zakresie metod, procesów i komunikacji. Wiele standardów, w tym D4P, zawiera również szereg specyfikacji w zakresie komunikacji i metod importu z innych standardów. Stosując go można być pewnym, że każde inne rozwiązanie oparte o ten sam standard będzie z nim kompatybilne.
Naszym czytelnikom życzymy zatem zdrowego rozsądku i rzetelnych architektów oprogramowania, a my zabieramy się do pracy, by wzbogacić nasze oprogramowanie o nowe funkcjonalności.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *