Perl żyje dziś w miejscach, o których nikt nie pamięta, dopóki nie przestaną działać: w skryptach spinających systemy, w przetwarzaniu logów, w konwersji plików między formatami. Decyzja o nim rzadko dotyczy nowego projektu. Dotyczy tego, czy organizacja utrzyma to, co już na nim stoi, i czym miałaby to zastąpić.
Na skróty
Czego dowiesz się z artykułu:
- Jaki koszt organizacja ponosi na danych, których jej systemy nie rozumieją
- Jakie warunki muszą wystąpić razem, żeby język skryptowy do przetwarzania tekstu był właściwą odpowiedzią
- W jakich sytuacjach ten język nie odpowiada na realny problem
- Jakie alternatywy pozostają i jaką cenę niesie każda z nich
- Co organizacja podpisuje, oddając proces skryptowi, którego nikt nie czyta
Dla kogo ten artykuł:
- Kierownicy zespołów utrzymujących integracje i przepływy danych
- Administratorzy systemów odpowiadający za automatyzację zadań cyklicznych
- Menedżerowie decydujący o przepisaniu albo zostawieniu kodu zastanego
Ile kosztuje organizację format danych, którego żaden z jej systemów nie rozumie?
Rachunek zaczyna się od czynności, których nikt nie księguje osobno: eksport z systemu, który nie umie oddać danych inaczej niż plikiem, ręczna poprawka w arkuszu, import do systemu, który tego pliku nie przyjmuje bez przeróbki. Czynność trwa kwadrans i wraca co tydzień. Nikt jej nie zgłasza, bo jest za mała na zgłoszenie, a razem tworzy stałą pozycję w koszcie operacji.
Do tego dochodzi koszt widoczny dopiero przy nieobecności. Przeróbkę wykonuje osoba, która wie, w której kolumnie bywa pusta wartość i który wiersz trzeba pominąć. Ta wiedza nie jest nigdzie zapisana, więc jej zastępstwo odtwarza cudze decyzje na żywym procesie — zwykle wtedy, gdy nikt nie ma na to czasu.
Problem ma odmiany, a ich pomylenie kosztuje najwięcej. Pierwsza odmiana to przepustowość: przetworzenie jest wąskim gardłem, bo wymaga człowieka przy każdym przebiegu. Druga to poprawność: wynik bywa różny w zależności od tego, kto go przygotował, a błąd wychodzi na jaw dopiero po stronie odbiorcy. Trzecia to rozliczalność: nikt nie umie odtworzyć, co dokładnie zrobiono z danymi między eksportem a importem. Rozstrzygnięcie nie zależy od tego, jakim narzędziem posługuje się dziś zespół — zależy od tego, którą z tych odmian organizacja faktycznie ponosi.
Kiedy język skryptowy do przetwarzania tekstu jest właściwą odpowiedzią?
Język zbudowany wokół przetwarzania tekstu jest właściwą odpowiedzią wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno:
- Wejście jest tekstem o nieregularnej strukturze. Logi urządzeń, raporty drukowane do pliku, eksporty z systemów, które nigdy nie miały ze sobą rozmawiać. Gdy źródło oddaje dane w ustalonym schemacie, przewaga narzędzia tekstowego znika w pierwszym dniu.
- Reguła przekształcenia zmienia się częściej niż systemy po obu stronach. Dopisany wyjątek, nowy wariant formatu, kolejna wersja raportu. Gdy reguła jest stabilna od lat, zysk z języka, w którym zmienia się ją natychmiast, jest pozorny.
- Wynik jest krokiem procesu, a nie produktem. Przekształcenie zasila raport albo import, ale nie trafia do klienta i nie ma własnego cyklu wydawniczego. Gdy trafia — to nie jest już skrypt, tylko oprogramowanie, i obowiązują go inne reguły.
Dopiero gdy te warunki występują łącznie, sensu nabiera praca nad samym warsztatem: wyrażenia regularne prowadzone tak, żeby dały się przeczytać po roku, parsowanie formatów, które nie mają specyfikacji, i obsługa danych, które psują się przewidywalnie. Ten zakres — od zaawansowanych wyrażeń regularnych po automatyzację przetwarzania na rzeczywistych plikach — obejmuje szkolenie Manipulacja tekstem z wykorzystaniem PERL.
Kiedy tej technologii nie wybierać?
Najczęstszym błędem jest sięgnięcie po ten język dlatego, że „on już tu jest”, zanim ktokolwiek sprawdził, czy zadanie w ogóle jest zadaniem tekstowym. Organizacja dostaje wtedy kolejny skrypt konwertujący, a nie usuniętą przyczynę konwersji.
Poza tym są sytuacje, w których ten język nie odpowiada na realny problem. Logika, która ma trafić do produktu, potrzebuje testów, przeglądów kodu i cyklu wydawniczego; skrypt uruchamiany z harmonogramu żadnego z nich nie niesie, a dopisanie ich po fakcie kosztuje więcej niż napisanie całości od nowa. Dane, które mają schemat, nie wymagają parsera tekstowego — jeżeli źródło potrafi oddać strukturę, przetwarzanie po znakach jest krokiem wstecz i zamraża problem zamiast go usuwać. Zespół, w którym nikt tego języka nie czyta, dostaje kod działający do pierwszej zmiany wymagań; rekrutacja na tę kompetencję trwa dłużej niż na języki o szerszym rynku. Żadnej z tych sytuacji nie zmienia to, ile skryptów już powstało. Co realnie usuwa przyczynę konwersji po stronie systemów, rozkłada tekst o integracji systemów IT i barierach przepływu danych.
Jakie są alternatywy i ile kosztują?
Język ogólnego przeznaczenia — najczęściej Python — daje szerszy rynek kompetencji, czytelniejszy kod dla osoby z zewnątrz i biblioteki do formatów, które inaczej trzeba obsłużyć samodzielnie. Ceną jest przepisanie: reguły ukryte w wyrażeniach regularnych trzeba najpierw odczytać, a nieudokumentowany wyjątek wraca jako regresja na produkcji. Narzędzia powłoki są tańsze i wystarczają do prostego filtrowania, ale rozsypują się przy zagnieżdżonych formatach i nie mają miejsca na obsługę błędu; ich cena to brak testów i brak śladu po przebiegu. Platforma integracyjna przenosi utrzymanie na dostawcę i daje rozliczalność, kosztem licencji, czasu wdrożenia i granic, których nie da się przesunąć. Jak utrzymuje się takie przepływy narzędziami do zarządzania konfiguracją, rozkłada omówienie automatyzacji i narzędzi do zarządzania konfiguracją środowisk IT.
Ostatnia droga bywa najtańsza i najrzadziej rozważana: zostawienie działającego skryptu w spokoju i opisanie go — reguł, wyjątków i warunków uruchomienia. Bywa też jedyną uczciwą, bo pozostałe zakładają, że organizacja ma budżet na przepisanie czegoś, co dziś działa.
Co organizacja podpisuje, oddając proces skryptowi, którego nikt nie czyta?
Podpisuje przede wszystkim cudzą konwencję. Skrypt bez opieki nie przestaje działać z dnia na dzień — przestaje być rozumiany, a to wychodzi na jaw przy zmianie formatu wejścia albo przy migracji serwera. Wtedy okazuje się, że nikt nie wie, czy pominięty wiersz jest błędem, czy celową regułą.
Podpisuje też ryzyko kadrowe, którego nikt nie wycenia z góry. Proces prowadzony przez pojedynczą osobę zamienia każdą zmianę w kolejkę do jednego kalendarza, a każdą nieobecność w ryzyko operacyjne. Najdroższą pozycją nie jest jednak żaden konkretny skrypt, tylko brak kompetencji po stronie zespołu: bez niej organizacja nie ma wyboru między utrzymaniem a przepisaniem, bo nie umie ocenić żadnej z tych dróg. Kompetencją, która ten rachunek obniża, jest umiejętność czytania i utrzymania istniejącego kodu — czyli zakres szkolenia Programowanie w Perl: od podstaw do zaawansowanych technik. Bez tego organizacja płaci podwójnie: za działający proces i osobno za każdą jego zmianę.
FAQ — najczęściej zadawane pytania
Czy warto dziś rozpoczynać nowy projekt w tym języku?
Rzadko, i nie z powodu samego języka. Nowy projekt zwykle nie spełnia warunku o nieregularnym wejściu, a spełnia warunek o docelowym produkcie — czyli wpada w sytuację dyskwalifikującą. Wyjątkiem bywa zadanie czysto tekstowe w zespole, który tę kompetencję już ma.
Jak ocenić, czy przepisać skrypt zastany?
Nie po jego wieku, tylko po tym, ile razy w ostatnim roku ktoś musiał go zmienić i ile osób umie to zrobić. Skrypt niezmieniany i rozumiany przez zespół nie jest długiem. Skrypt zmieniany co miesiąc przez osobę, która akurat odchodzi, jest długiem niezależnie od języka, w którym powstał.
Co zrobić najpierw, gdy nikt już nie czyta tego kodu?
Opisać wejście i wyjście, zanim ktokolwiek zajrzy do środka. Przepisywanie zaczęte od kodu odtwarza cudze decyzje razem z błędami; zaczęte od kontraktu danych pozwala sprawdzić nowy przebieg wobec starego na rzeczywistych plikach.