Integracjonista

Wspomagam ostatnio hobbystycznie pewien nieduży projekt IT, w trakcie prac mam wrażenie (i to już nie jest pierwszy raz), że zamiast skupić się na tworzeniu „klu” rozwiązania, większość czasu poświęcane jest na rozgryzanie szczegółów integracji z systemami z którymi trzeba się komunikować. Jak wygląda interfejs, czy to REST czy SOAP (a czasem nawet FTP, TCPIP, itp.), jak się autoryzować, jaka jest struktura żądania i odpowiedzi, jak będzie wyglądała obsługa błędów, co kiedy i w jakiej kolejności wywołać? To mnóstwo pytań i potrzebnych odpowiedzi.

Ale to nie wszystko. Przecież każde narzędzie, każda technologia, której używamy, ma także swoją specyfikę i wymaga ustalenia sposobu użycia. Za każdym razem gdy korzystamy z zewnętrznego mechanizmu w postaci dowolnej biblioteki, czy bazy danych, czy np. serwera kolejek, za każdym razem stawiamy sobie te, podane wyżej i jeszcze inne, pytania. I za każdym razem ustalenie tego wszystkiego zajmuje ogrom czasu.

Ale to dalej nie wszystko. Przecież wszystkie te „zewnętrzne” twory mają niestety taką cechę, że nie działają w 100% i zawsze według specyfikacji. Wiadomo, we wszystkim są błędy, niedociągnięcia. Kolejną sporą ilość czasu zajmuje nam poznanie i opanowanie tych nietypowych zachowań.

Niestety to wciąż nie wszystko. Powyższe zjawiska są zmienne w dziedzinie czasu. Czasami trzeba zaktualizować wersje tego z czego korzystamy z czym współpracujemy. Czasem to jest nasza decyzja, np. kiedy podbić Hibernate do wyższej wersji, a czasem mniej nasza np. konieczność podbicia Log4J do wersji, która nie będzie miała tak wielkiego bug’a jak tu opisują. A czasem to jest decyzja kogoś całkiem innego, na kogo nie mamy wpływu, jak np. podniesienie wersji zewnętrznej usługi przez jej dostawcę ze zmianą interfejsu, bez wcześniejszej informacji, że to się stanie (a dlaczegóż by nie?), tak też się zdarza.

Konsekwencje są takie, że zawsze musimy być przygotowani na niekompatybilność ze strony wszystkich tych „zewnętrzności”. Przygotowani w jaki sposób? Głównie poprzez posiadanie automatycznych testów, które zweryfikują poprawność współpracy i integracji z praktycznie wszystkim. Brzmi dobrze, ale tu niestety napotykamy problemy. Testowanie jednostkowe systemów zewnętrznych np. za pomocą mock’ów nic nie daje w sytuacji gdy zmieniły się zachowania tychże systemów, a my o tym nie wiemy (trzeba by zaktualizować mock’i). Rozwiązaniem jest tworzenie testów End-to-End i to wydaje się całkiem sensowna metoda, choć nie prosta, bo np. nie zawsze mamy dostęp do systemów testowych, a żądania do systemów produkcyjnych zazwyczaj są kłopotliwe. Tak czy inaczej, jest to niemała praca do wykonania.

Idąc dalej w rozważaniach, zobaczmy jak wygląda procentowy podział czasu dla różnych deweloperów i w różnych projektach. Tworzenie głównego kodu biznesowego w stosunku do szeroko pojętego „integrowania”. Zbierając luźne „zeznania” kilku znajomych osób, wyszło mi coś takiego:

Wniosek? Panowie programiści i Panie programistki, czy my naprawdę jeszcze jesteśmy tym czym się nazywamy? Mam wrażenie, że rzeczywistość kolejny raz zrobiła nas w „jajo”, cichaczem i niepostrzeżenie transferowała nas z zawodu programisty do integracjonisty.

Czy to źle? Zdecydowanie nie, jednak warto mieć tego świadomość. Do czego niniejszym, mam nadzieję, się przyczyniam. Kończąc, pozdrawiam wszystkich Integracjonistów, przemycając życzenia wszystkiego dobrego w nowym 2022 roku.