Modernizacja przestarzałego oprogramowania bez rewolucyjnego przepisywania od zera

Niemal każda dojrzała firma ma taki jeden: kawałek oprogramowania, którego wszyscy po cichu nie znoszą. Jest powolny, brzydki, połowa zespołu zna obejście błędu, którego nikt nigdy nie naprawił, a jedyna osoba, która go rozumiała, odeszła w 2019 roku. Odruch jest zawsze ten sam — zburzyć wszystko i zbudować nowe. I właśnie ten odruch, częściej niż rzadziej, jest dokładnie tym, jak dobre firmy tracą rok i niemałą fortunę na nic.

Widziałem, jak wielkie przepisywanie idzie źle, na tyle razy, że mam już co do tego odruch. Założyciel pokazuje mi swój trzeszczący system zamówień albo swoje wiekowe narzędzie do grafików, wzdycha i mówi jakąś wersję zdania „musimy po prostu wymienić całość”. I może pewnego dnia tak będzie. Ale pełne przepisanie — wyrwać stary system, zbudować równolegle nowy, lśniący, a potem przełączyć — to jeden z najbardziej ryzykownych ruchów w całym świecie oprogramowania. Jest kosztowny, trwa znacznie dłużej, niż obiecano, i przez cały czas lecą Państwo na ślepo, licząc, że nowy twór pokryje każdy dziwny przypadek brzegowy, który stary po cichu obsługiwał przez piętnaście lat.

Dobra wiadomość jest taka, że rewolucyjne przepisywanie niemal nigdy nie jest jedyną opcją i rzadko bywa najlepszą. Istnieje spokojniejszy sposób modernizacji — przyrostowy, odwracalny i łagodny dla firmy, która wciąż musi zarabiać podczas pracy. To przewodnik po tym sposobie: jak rozpoznać, co naprawdę wymaga naprawy, jak wymienić bolesne fragmenty bez wyłączania całego systemu i jak poznać, kiedy pełne przepisanie faktycznie jest właściwym wyborem.

Dlaczego rewolucyjne przepisywanie tak kusi — i jest tak niebezpieczne

Pełne przepisanie jest kuszące, bo obiecuje czystą kartę. Koniec ze starym bałaganem, koniec z kompromisami, świeża baza kodu zbudowana właściwie, z użyciem nowoczesnych narzędzi. Na tablicy wygląda to oczywiście. W rzeczywistości podpisują się Państwo pod odbudową lat nagromadzonej logiki biznesowej — w dużej części nieudokumentowanej, częściowo żyjącej tylko w głowach osób, które już odeszły — podczas gdy zegar tyka, a rachunki przychodzą.

Głębszą pułapką jest problem równoległego wszechświata. Przez miesiące lub lata budowy następcy mają Państwo dwa systemy: stary, który wciąż musi prowadzić firmę, i nowy, który nie jest jeszcze gotowy. Każdą zmianę, której potrzebuje firma, trzeba wprowadzać dwa razy, inaczej nowy system odstaje od rzeczywistości, zanim w ogóle ruszy. Zespoły wypalają się, utrzymując oba przy życiu. A ponieważ nikomu nie wolno się przełączyć, dopóki nowy system nie robi wszystkiego, nie ma wczesnej wygranej, nie ma informacji zwrotnej, nie ma dowodu, że to działa — jest tylko długie, napięte oczekiwanie na jeden ogromny dzień startu typu „wszystko albo nic”.

Krąży tu znana branżowa opowieść i jest ona zasłużona: drugi system, ten wielki, przepisany od nowa, ma zwyczaj zajmować trzy razy więcej czasu, niż szacowano, i przybywać z mniejszą liczbą funkcji niż to, co zastępował. Szacunek jest błędny nie dlatego, że ludzie są niedbali. Jest błędny, bo nikt nie widzi na starcie wszystkich drobiazgów, które stary system po cichu robi dobrze.

Co naprawdę znaczy „legacy” (nie chodzi o wiek)

Rzucamy słowem legacy, jakby znaczyło po prostu „stare”. Tak nie jest. Mnóstwo oprogramowania działającego od dekady jest zupełnie w porządku — nudne, stabilne, opłacone, robi swoje. Sam wiek nie jest powodem, by czegokolwiek dotykać. Najkosztowniejszy błąd w całej tej dziedzinie to modernizacja czegoś, co po cichu działało, tylko dlatego, że wyglądało przestarzale.

Oprogramowanie zasługuje na etykietę legacy, gdy aktywnie wchodzi Państwu w drogę. Gdy nie można go bezpiecznie zmienić, bo nikt go w pełni nie rozumie. Gdy nie da się go połączyć z narzędziami, od których teraz Państwo zależą. Gdy jedna osoba jest jedyną zdolną utrzymać je przy życiu. Gdy jest tak powolne lub kruche, że zespół zbudował wokół niego całą folklorystyczną kolekcję obejść. To prawdziwa definicja — nie rok napisania, lecz koszt, jaki narzuca Państwu dziś, i ryzyko, jakie niesie na jutro.

Postaw diagnozę, zanim czegokolwiek dotkniesz

Zanim przepiszecie choćby jedną linię, potrzebują Państwo uczciwej mapy tego, gdzie naprawdę leży ból. Najczęściej system, którego wszyscy nienawidzą, jest w 80% w porządku. Kłopot skupia się w kilku konkretnych miejscach — jeden powolny ekran, jedna zepsuta integracja, jeden przepływ pracy wymuszający podwójne wprowadzanie danych — i te kilka miejsc generuje niemal wszystkie skargi. Znajdźcie je, a znajdziecie cały swój projekt.

Sposobem na ich znalezienie nie jest najpierw audyt techniczny — to rozmowa. Usiądźcie z ludźmi, którzy używają tego codziennie, i zapytajcie, gdzie boli. Gdzie czekają? Co przepisują ponownie? Czego unikają, bo jest uciążliwe? Gdzie prowadzą prywatny arkusz, by obejść oficjalny system? Te obejścia to złoto: każde z nich to precyzyjny rentgen problemu wartego naprawy.

• Ekrany i kroki, na które ludzie skarżą się najbardziej — nie w teorii, lecz w ich realnej codziennej pracy.
• Każde miejsce, gdzie dane wpisuje się dwa razy, bo dwa systemy ze sobą nie rozmawiają.
• Integracje, które się zepsuły lub nigdy nie powstały, zmuszające do ręcznego kopiowania-wklejania między narzędziami.
• Wszystko, co tylko jedna osoba potrafi obsłużyć lub naprawić — Państwa pojedyncze punkty awarii.
• Fragmenty, które są naprawdę w porządku, abyście mogli je chronić i zostawić w spokoju.
• To, czego firma będzie potrzebować w przyszłym roku, a w co obecny system po prostu nie potrafi się rozwinąć.

Kiedy robią to Państwo uczciwie, projekt zwykle się kurczy. Właściciel, który wchodził ze słowami „wymienić wszystko”, wychodzi z konstatacją, że musi naprawić trzy rzeczy. To nie rozczarowanie — to ulga. Trzy naprawialne rzeczy to projekt, który skończą Państwo w tym kwartale. Pełna wymiana to rok, którego być może nie przetrwacie.

Metoda strangler: wymieniaj kawałek po kawałku

Istnieje wzorzec, by robić to bezpiecznie, i ma nieco ponurą, ale zapadającą w pamięć nazwę: metoda strangler, od figowca dusiciela — pnącza, które rośnie wokół drzewa, stopniowo przejmując jego strukturę, aż w końcu nowy porost stoi o własnych siłach, a stary pień znika. W odniesieniu do oprogramowania pomysł jest pięknie praktyczny: nie wymieniają Państwo starego systemu w jednej heroicznej zamianie. Hodują nowy wokół niego, kawałek po kawałku, aż ze starego nie zostanie nic, czego ktokolwiek potrzebuje.

W praktyce działa to tak. Wybierają Państwo jeden bolesny kawałek — powiedzmy moduł fakturowania, którego wszyscy nie znoszą. Budują nowoczesny zamiennik tylko dla tego kawałka. Kierują fakturowanie do nowego modułu, podczas gdy cała reszta dalej działa na starym systemie, nietknięta. Obserwują przez chwilę. Gdy jest solidny, ta część starego systemu cichnie, a Państwo przechodzą do następnego kawałka. Stary system kurczy się stopniowo, jak świeca, zamiast być zburzonym za jednym razem.

To, co czyni to o tyle bezpieczniejszym od przepisywania, to fakt, że każdy krok jest mały, na żywo i odwracalny. Nigdy nie lecą Państwo na ślepo. Każdy nowy kawałek szybko trafia do realnego użytku, więc szybko dowiadują się, czy naprawdę działa. Jeśli coś pójdzie nie tak, zaryzykowali Państwo tylko jeden moduł, a nie całą firmę — i zwykle można wrócić na starą ścieżkę, gdy się to naprawia. Zdobywają Państwo wygrane po drodze, zamiast jednego przerażającego startu na końcu. A firma działa normalnie przez cały czas.

Jak naprawdę wygląda ten rytm

1. 1
   Wybierz najbardziej bolesny, najbardziej samodzielny kawałek

   Chcą Państwo dużego bólu i czystych krawędzi — modułu, który mocno boli i nie ma palców w całej reszcie. To Państwa pierwszy cel.
2. 2
   Postaw cienką warstwę przed starym systemem

   Mała warstwa routingu decyduje, które żądania idą do starego systemu, a które do nowego kawałka. To szew, który czyni resztę możliwą.
3. 3
   Zbuduj i wdroż tylko ten jeden kawałek

   Wymień jeden moduł, oddaj go w realne ręce i kieruj do niego tylko ten wycinek pracy. Tygodnie, nie lata — a reszta systemu nawet drgnęła.
4. 4
   Ustabilizuj, potem przejdź do następnego kawałka

   Gdy nowemu modułowi już się ufa, odpowiadająca mu część starego systemu zasypia. Powtarzaj z kolejnym bolesnym kawałkiem, ucząc się po drodze.
5. 5
   Wycofaj stary system, gdy będzie pusty

   W końcu przestarzały system nie robi nic, na czym ktokolwiek polega. Dopiero wtedy go Państwo wyłączają — po cichu, bez dramatu, bo wszystko, co ważne, już się przeniosło.

Proszę zauważyć, co odróżnia to od przepisywania: nie ma jednego dnia startu, którego trzeba się bać. Nie ma równoległego wszechświata do utrzymania. Nowy system jest na produkcji od trzeciego tygodnia, zarabia na siebie i czegoś Państwa uczy, zamiast czekać w laboratorium na start, który wciąż się przesuwa.

Czasem wcale nie trzeba go wymieniać

Zanim cokolwiek Państwo wymienią, warto zapytać, czy stary system wymaga wymiany, czy tylko przestania bycia wyspą. Zaskakująco wiele problemów typu „potrzebujemy nowego systemu” to w istocie problemy „nasze systemy ze sobą nie rozmawiają”. Stare oprogramowanie robi swoje dobrze — po prostu siedzi w silosie, zmuszając ludzi do ręcznego przenoszenia danych tam i z powrotem.

W takich przypadkach najtańszą, najszybszą naprawą nie jest nowy system. To most. Opakowują Państwo stare oprogramowanie połączeniem — integracją, która pozwala mu automatycznie wymieniać dane z innymi narzędziami — i nowoczesną warstwą na wierzchu dla części, których ludzie faktycznie dotykają. Przestarzały silnik dalej buczy pod spodem; zespół dostaje czystą powierzchnię i koniec kopiowania-wklejania. To nie jest efektowne, ale często daje najwyższy zwrot z każdego euro w całym przedsięwzięciu.

Kiedy pełne przepisanie faktycznie jest właściwym wyborem

Przez cały ten przewodnik odwodziłem Państwa od wielkiego przepisywania, więc bądźmy uczciwi: czasem naprawdę jest ono odpowiedzią. Bywają fundamenty tak zgniłe, że żadna ilość łatania, mostkowania ani wymiany kawałek po kawałku ich nie uratuje, a udawanie, że jest inaczej, tylko odwleka nieuniknione, podczas gdy wydają Państwo pieniądze na podpieranie trupa.

Uczciwe sygnały są konkretne. Technologia, na której zbudowano system, jest martwa lub umierająca — brak wsparcia, brak aktualizacji bezpieczeństwa, nikogo, kto mógłby przy niej pracować. Firma zmieniła się tak fundamentalnie, że stary model w ogóle nie odwzorowuje już rzeczywistości. Albo system jest tak splątany, że nawet małe zmiany rutynowo psują rzeczy w niepowiązanych miejscach, co zwykle oznacza, że w ogóle nie ma czystych szwów, by zastosować metodę strangler. Gdy dwie lub trzy z tych rzeczy są prawdą naraz, praca przyrostowa przestaje być bezpieczniejszym wyborem.

A oto cicha nagroda za wykonanie najpierw pracy przyrostowej, nawet jeśli ostatecznie odbudują Państwo system: zanim tam dotrą, będą rozumieć system znacznie lepiej niż na starcie. Każdy wymieniony moduł nauczył Państwa czegoś, czego pierwotni autorzy nigdy nie spisali. Przepisanie zasilone tą wiedzą to zupełnie inne, znacznie bezpieczniejsze zwierzę niż to wystrzelone na optymizmie pierwszego dnia.

Część, o której nikt nie wspomina: chodzi głównie o ludzi

Oto coś, co techniczne przewodniki pomijają. Najtrudniejszą częścią modernizacji starego oprogramowania zwykle nie jest kod — to ludzie, którzy latami się do niego dostosowywali. Znają jego dziwactwa. Mają pamięć mięśniową do jego osobliwych skrótów. Nowy moduł, obiektywnie lepszy, przez pierwsze dwa tygodnie może i tak wydawać się gorszy, po prostu dlatego, że jest nieznany. Jeśli to zignorują Państwo, nawet idealna techniczna migracja może się nie powieść.

Podejście przyrostowe pomaga i tutaj, niemal przy okazji. Ponieważ zmiana przychodzi kawałek po kawałku, ludzie wchłaniają ją stopniowo, zamiast być proszeni o przeuczenie wszystkiego w jeden poniedziałkowy poranek. Włączcie codziennych użytkowników wcześnie. Pozwólcie im współkształtować zamiennik, zanim będzie gotowy. Zespół, który pomógł zaprojektować nowy ekran fakturowania, będzie go bronił; zespół, na którego głowę go zrzucono, będzie go nie znosił, nawet jeśli jest identyczny. Modernizacja to projekt zarządzania zmianą przebrany za oprogramowanie.

Najczęstsze pytania