Artykuł sponsorowany
Nowoczesny rynek usług cyfrowych i telekomunikacyjnych rozwija się dziś błyskawicznie. Niemal każdego dnia pojawiają się nowe aplikacje chmurowe, platformy komunikacji czy zaawansowane panele klienta. Pod ich powierzchnią nierzadko działają jednak programy tworzone wiele lat temu. Z czasem ich dalszy rozwój staje się niezwykle uciążliwy, a wprowadzanie kolejnych opcji zaczyna wywoływać niespodziewane błędy w innych miejscach. Przedsiębiorcy stają wówczas przed poważnym dylematem: nieustannie łatać wysłużone mechanizmy czy spróbować zbudować wszystko od zera?
Dlaczego przepisywanie systemów od podstaw budziło opór ekspertów?
W branży inżynierii oprogramowania budowa istniejącego narzędzia od nowa przez długi czas uchodziła za pomysł obarczony ogromnym ryzykiem. Znani praktycy tworzenia kodu, tacy jak Kent Beck, Robert C. Martin czy Martin Fowler, wielokrotnie ostrzegali przed tego typu projektami. Nie twierdzili oni, że takich operacji absolutnie nigdy nie wolno podejmować, ale wskazywali na konkretne zagrożenia biznesowe.
Najważniejszym problemem było ryzyko pominięcia tak zwanych ukrytych reguł biznesowych. Starsze oprogramowanie po latach pracy zawiera setki drobnych wyjątków i zabezpieczeń przed nietypowymi problemami użytkowników. Często nikt już o nich nie pamięta, a przy próbie odtworzenia kodu od zera bardzo łatwo te detale pominąć.
Drugim wyzwaniem był długi czas budowy, podczas którego użytkownicy nie otrzymywali żadnych widocznych korzyści ani nowych funkcji. Trzeci problem polegał na konieczności ciągłego doganiania starego rozwiązania. W czasie powstawania nowego wariantu dotychczasowy system nadal pracował i musiał być dostosowywany do bieżących zmian na rynku. Nowy projekt musiał więc stale ścigać ruchomy cel. W efekcie kosztowna inwestycja mogła zakończyć się wdrożeniem produktu, który działał gorzej niż stary.
Co wnosi spec-driven development w parze ze sztuczną inteligencją?
Pojawienie się generatywnej sztucznej inteligencji samo w sobie nie rozwiązało tych kłopotów. Jeśli algorytmy wykorzysta się wyłącznie do modyfikacji zagmatwanego, wieloletniego oprogramowania, pisanie kodu przyspieszy, ale narzędzie nie podpowie, które funkcje są wciąż potrzebne. Przełom przynosi dopiero połączenie AI z metodyką spec-driven development (SDD).
Zasada SDD jest wyjątkowo prosta: zanim programiści napiszą choćby jedną linijkę kodu, najpierw szczegółowo opisują oczekiwane działanie systemu oraz jasne kryteria poprawności. Przy istniejącym produkcie zespół ma tę przewagę, że doskonale zna jego faktyczne zachowanie. Zamiast odtwarzać dawny program linijka po linijce, tworzy się przejrzysty opis reguł, a sztuczną inteligencję wykorzystuje dopiero do wygenerowania nowej bazy.
Przykład Pragmatic Meet: krótszy czas i sprawne wdrożenie
W praktyce udane przepisanie starego systemu pokazuje historia narzędzia Pragmatic Meet. To aplikacja do zarządzania wydarzeniami: jedna osoba zakłada spotkanie, a inni mogą się zapisać. Pierwsza wersja bazowała na gotowym programie open source, który z biegiem czasu stał się główną barierą rozwojową.
Gdy zaplanowano prostą opcję, w której uczestnik podaje imię i nazwisko, a organizator zaznacza obecność na liście, prace zajęły aż sześć tygodni mimo korzystania z AI – a funkcja wciąż działała wadliwie. Twórcy postanowili więc napisać program od nowa. Znali go doskonale, bo sami go używali. Po zmianie podejścia czas pracy zespołu nad podobną funkcją spadł z około 60 do mniej niż 20 godzin. Poprzednia wersja działała stabilnie aż do chwili płynnego przełączenia.
Jeden sukces nie oznacza oczywiście, że każde starsze oprogramowanie należy natychmiast pisać na nowo. Połączenie metody SDD i AI udowadnia jednak, że przy odpowiednim planie taka zmiana może być przewidywalna i opłacalna.