Projekty IT starzeją się szybciej niż produkty w innych branżach technologicznych. Wpływ na to ma zawrotne tempo rozwoju różnych rozwiązań, podejść, metodyk pracy, sposób projektowania, trendów i innych rzeczy, z których słynie świat informatyczny oraz specyfika pracy w tym miejscu. Jednak, pod "starzeniem się" niekoniecznie rozumiemy tutaj to, że systemy dostępne od wielu lat stają już nie do używania - owszem, tak się zdarza, ale pamiętajmy, że oprogramowanie cały czas jest aktualizowane. Upływ czasu dotyka bardziej struktury kodu źródłowego projektu i jego architektury. Osoby rozpoczynające projekt bywają inne i mające inną wiedzę niż zespół pochylający się nad danym oprogramowaniem po wielu latach. Tego typu kod nazywamy "legacy code" i mówimy o nim głównie w kontekście przejmowania go przez innych programistów czy nawet firmy.
Jednak dzisiaj nie będziemy zajmować się tym tematem od strony software house'u (choć być może kiedyś przyjdzie na to czas). Jeśli ktoś jest bardziej zainteresowany tym zagadnieniem z tej perspektywy, polecam tekst znajdujący się na blogu firmy Britener, a my tymczasem podejdziemy do tematu od drugiej strony - od klienta.
Przez lata pracy i zabawy jako programista widziałem różne zlecenia, z którymi przychodzą klienci. Przynoszą oni często swoje pomysły na projekt, który chcą wspólnie tworzyć i rozwijać - to podstawa działania software house'ów i radości obu stron z dobrze wykonanej pracy. Jednak są również sytuacje, w których pojawia się potrzeba kontynuowania prac nad oprogramowaniem, jakiego oryginalnie firma nie zaczynała. Powody są bardzo różne i dzisiaj omówimy, natomiast ten tekst ma przede wszystkim uświadomić Wam, drodzy klienci, co wiąże się z takimi projektami od strony wykonawcy, których powinniście zrozumieć.
Jaka jest charakterystyka projektów "legacy"?
Z tworzeniem każdej aplikacji wiążą się jakieś ustalenia i założenia dotyczące pisania w nim kodu - zazwyczaj mówimy o tym w kontekście architektury oprogramowania, ale czasami dotyczy to też bardziej szczegółowych kwestii, jak schematy tworzenia ekranów, nazewnictwo itd. Osoby, które są w projekcie od początku, zwykle znają te wytyczne i starają się do nich stosować. Niekiedy pomija się przy tym tworzenie dokumentacji, gdyż uznaje się, iż nie jest potrzebna - "bo wszyscy wiedzą, co się dzieje" (co ciekawe - czasami ten argument rzeczywiście ma sens, ale o tym może przy innej okazji). Cóż...
Tego komfortu nie mają programiści, którzy wchodzą do projektu później, nie mówiąc już o firmie, która przejmuje kod po innej. Pół biedy, jeśli aplikacja napisana została zgodnie z zaleceniami danego frameworku lub ogólnie dobrymi praktykami - wówczas można się w niej zorientować trochę szybciej z uwagi na to, że będą zgadzać się kwestie polecane w dokumentacji silnika. Często jednak powodem przenoszenia projektów jest niezadowolenie z pracy poprzedniego zespołu, co nie musi, ale może być związane z innymi niezbyt sympatycznymi kwestiami, w tym z bałaganem w kodzie.
Frameworków i języków jest tak dużo, że trzeba mieć świadomość, iż firma, która ma przejąć projekt po kimś, zwykle nie będzie zaznajomiona z bibliotekami użytymi już w oprogramowaniu - wymagają one poznania, przeanalizowania i dostosowania się do nich. Przykładowo, kod napisany w PHP nie oznacza, że automatycznie wskoczy do niego każdy programista, który w tym języku programuje na co dzień. Owszem, będzie mu łatwiej, ale nierzadko trzeba gruntownie poznać konkretny silnik i jego specyfikę. Istnieją też bardziej ekstremalne sytuacje, jak te, w których projekt nie jest pisany w żadnej popularnej technologii i wszystko to własna inwencja oryginalnego autora - od struktury aplikacji do sposobu uwierzytelnienia. Może to być czasem dobre podejście (szczególnie ze względu na wydajność), ale dużo częściej jest przeszkodą stojącą przed programistą przejmującym oprogramowanie.
Abyście lepiej zrozumieli, o co chodzi, podam przykład z zupełnie innej branży - warsztat samochodowy. Mechanik pracujący w takim miejscu dobrze się zna na samochodach i z radością zajmie się Waszym wozem, gdy podjedziecie nim do takiego specjalisty z prośbą o pomoc. W dodatku raczej nie będzie miał problemu, aby zorientować się w tym, jak się zbudowany pojazd. Dlaczego? Dlatego, że wszystkie są skonstruowane mniej więcej w taki sam sposób i (tutaj wybaczcie mi, bo ekspertem nie jestem) zwyczajnie wiadomo, gdzie co jest, jak działa lub powinno działać itd. A teraz wyobraźcie sobie, że nie ma żadnego "standardu" projektowania samochodów od strony mechanicznej i każdy buduje je po swojemu, we własnym garażu z części i instrukcji znalezionych w Internecie. Niby jakieś wspólne schematy istnieją, ale tak naprawdę w dużej mierze osoby realizują szczegóły na własną rękę. Mało tego - nie wszyscy wykorzystują ten sam rodzaj silnika, bo pojawili się śmiałkowie opierający swoje samochody na energii elektrycznej. I teraz wyobraźcie sobie mechanika, do którego przyjeżdżają takie "skastomizowane" pojazdy i w których musi się odnaleźć oraz jeszcze je naprawić lub zamontować dodatkowe mechanizmy. Pewnie da radę to zrobić, jednak droga do tego jest dłuższa, gdyż musi poznać każdy wóz od podstaw (zapewne bez dokumentacji) i dostosować do niego swoje procedury. Tak właśnie czuje się programista, który dostaje do rozwijania projekt, w którym nic nigdy nie robił - niby aplikacje powinny być zbudowane podobnie, ale zwykle nie są, gdyż jest wiele ścieżek pozwalających osiągnąć dobre oprogramowanie i ludzie mogą skorzystać z którejkolwiek. Albo wydeptać swoją...
Kiedy zachodzi potrzeba przekazania projektu?
Sytuacje, w których klienci przychodzili do nas ze swoimi istniejącymi aplikacjami, były naprawdę różne. Można je jednak podzielić na trzy kategorie:
- rezygnacja ze strony wykonawcy - jest to bardziej "pozytywne" rozstanie, wynikające z zaprzestania świadczenia usług przez poprzedniego wykonawcę, np. z uwagi na problemy kadrowe lub wręcz zmianę branży. Przy tego typu przekazaniach częściej jest szansa na nawiązanie kontaktu nowego zespołu IT z dotychczasowym i dopytywanie o różne szczegóły lub nawet okresowe konsultacje.
- rezygnacja ze strony klienta - tego typu rozstania mają związek zwykle z niezadowoleniem z dotychczasowego wykonawcy. Powody znów mogą być przeróżne - od wyższej ceny, po wyraźne obniżenie jakości, aż do niesnasek na drodze ustaleń biznesowych. W takich wypadkach klient jest bardziej zdeterminowany do znalezienia nowej firmy opiekującej się jego projektem, za to dotychczasowy wykonawca z oczywistych względów jest niezadowolony i może nie chcieć współpracować na początku.
- projekt rozpoczęty przez klienta - zdarza się, że sam klient własnoręcznie zabrał się za oprogramowanie, jednak to go przerosło lub np. zabrakło na niego czasu, a zapowiada się obiecująco. Wówczas nowy wykonawca może zwykle liczyć na pełne wsparcie klienta, gdyż ten jest nie tylko pomysłodawcą, ale też pierwotnym twórcą aplikacji.
Słowem - przekazanie projektu nigdy nie dzieje się bez powodu. Najczęściej źródłem jest rozrastające się oprogramowanie, z którego utrzymaniem (już po opublikowaniu) problem ma pierwotny wykonawca. Nie zawsze jest to faktycznie z jego winy - należy tutaj rozważyć faktyczną jakość programistów i infrastruktury, ale też budżet oraz ambicje klienta. Nie jest to jednak temat, który chcę tutaj poruszać. Faktem jest jednak to, że przenoszenie projektu do innego wykonawcy wiąże się z pewnym czasem adaptacji i nigdy nie dzieje się "ot tak".
A jakie projekty są przenoszone? Tutaj również mamy dwie główne kategorie:
- projekty jeszcze nieukończone, wymagające dopracowania lub doimplementowania brakujących funkcji
- projekty już uruchomione produkcyjne, które są rozwijane
Oba przypadki niejednokrotnie widzieliśmy w naszej firmowej karierze. Czy którekolwiek z nich są łatwiejsze do przejęcia? Teoretycznie te pierwsze z uwagi na to, że nie znajdują się jeszcze na serwerze i ewentualne poprawki oraz wdrożenia aktualizacji (które za pierwszym razem zawsze są trudne) nie zablokują czasowo użytkowników. Wszystko jednak zależy od sytuacji i konkretnego projektu.
Jak przygotować projekt do przejęcia?
Innymi słowy: o co zapyta software house w momencie, kiedy pojawisz się u niego z prośbą o dokończenie bądź przejęcie opieki nad programem? Tutaj trzeba mieć świadomość, że podobnie jak to ma miejsce przy rozpoczynaniu kompletnie nowej aplikacji, koniecznie jest zapoznanie wykonawcy z wymaganiami i specyfikacją projektu. Jest to nawet ciut łatwiejsze z uwagi na to, że niektóre rzeczy programiści mogą "doczytać" w kodzie lub samodzielnie "przeklikać", jeśli są już gotowe. Jednak dodatkowo, istnieje tutaj szereg kwestii, którymi klient powinien dysponować wybierając nowego wykonawcę i chcąc przekazać mu wiedzę.
- aktualny stan projektu - dotyczy szczególnie oprogramowania, które wymaga dokończenia i opisuje, jak daleko zostały posunięte prace.
- dostęp do kodu źródłowego - bardzo istotny punkt, szczególnie w aplikacjach nie-PHP-owych. Klienci rzadko zdają sobie sprawę z tego, że dostęp do wynikowych plików na serwerze zwykle nie wystarcza do rozwoju aplikacji (napisanej np. w Angularze). Potrzebny jest materiał źródłowy, którym dysponuje dotychczasowy wykonawca, jednak powinien podzielić się nim z klientem (który na mocy większości umów ma prawa do dysponowania tym kodem). Pamiętajcie - bez źródeł nikt nie przejmie Waszego projektu. Nawet w języku PHP warto go mieć, gdyż nie wszystkie pliki potrzebne przy rozwoju oprogramowania trafiają na serwer, skąd można je pobrać.
- dostęp do serwera (jeśli istnieje) - związane z poprzednim punktem. Często jest to pierwszy krok ku poznaniu nowego projektu i rozeznania się w jego kodzie (jeśli jest tam dostępny).
- dokumentacja projektu - wspomniałem o tym już wcześniej i tutaj zwykle jest największy problem. Specyfikacje i opisy techniczne zwykle są przygotowywane dla większych systemów IT, które nie tylko po zmianie wykonawcy, ale także dla oryginalnej firmy mogą być na tyle złożone, że wymagają opisania. Jednak problem z dokumentacją jest taki, że ich przygotowanie wymaga czasu, którego nikt nigdy nie ma wystarczająco dużo. Stąd metodyki zwinne w swoim manifeście wprowadzają zasadę "działające oprogramowanie ponad szczegółową dokumentacją" {}, która jest słuszna, choć wiele osób może wpaść w pułapkę i stwierdzić, że w takim razie w ogóle nie potrzebują dokumentacji. To jednak temat na inny artykuł.
- czas - to może trywialne, ale poza samym przystąpieniem do prac, wykonawcy potrzebny jest początkowy (opłacony) czas na analizę i zapoznanie się z projektem, w co zazwyczaj wlicza się również konfigurację oprogramowania na komputerach lokalnych oraz konsultacje.
W odniesieniu do ostatniego punktu, musicie mieć świadomość, że niezależnie od tego, ile czasu zostanie poświęcone na zapoznanie się z projektem, zawsze po tym czasie pojawią się rzeczy, które będą budzić wątpliwości i utrudniać następne, konkretne zadania. To normalne - błędem jest zakładanie, że podczas pierwszego etapu programiści poznają każdy zakamarek kodu i aplikacji. Często nie jest to możliwe, gdyż nie zawsze po prostu wiadomo, czego szukać - tutaj trzeba wykazać się wyrozumiałością.
Czy ma sens przepisywanie projektu od nowa?
Czasami słyszy się takie zdanie, że "ten projekt łatwiej napisać od nowa niż przerabiać". Z punktu widzenia programistów jest to często słuszne podejście, szczególnie jeśli kod nie jest napisany dobrze. Jednak z biznesowego punktu widzenia taka droga zwykle nie ma sensu, ponieważ lepiej przemęczyć się nawet ze źle napisanym projektem i go po kawałku refaktoryzować (zmieniać, modyfikować bez zmiany funkcjonalności), aniżeli pisać wszystko od nowa.
Ponownie - wszystko zależy od kontekstu. Rzadko się zdarza, żeby przejmowana aplikacja była tak mała, aby opłacało się ją tworzyć od nowa, a poza tym przy takim rozmiarze oprogramowania dość łatwo wprowadzić potrzebne korekty. Dużo częściej projekt "legacy" jest duży, rozbudowany i rozpoczynanie go od zera wiąże się z bardzo dużą liczbą godzin. Są jednak sytuacje, w których klienci się na to decydują, np. gdy przejęcie projektu oznacza przy okazji odświeżenie UX (ang. User eXperience) i mechanizmów na stronie - wówczas tworzenie tak naprawdę nowej aplikacji na wzór dotychczasowej ma sens.
Ta kwestia zależy od konkretnej sytuacji, projektu, klienta oraz wykonawcy. Zazwyczaj jednak projekt "legacy" jest utrzymywany, a nie "rimejkowany".
Podsumowanie
Zmiana wykonawcy dla istniejącego oprogramowania zwykle nie jest łatwym procesem, ale czasami potrzebnym. Pamiętajcie, że utrzymywanie kodu i działającej aplikacji jest często niedocenianym, ale najbardziej zajmującym czasowo etapem rozwoju projektu. Obie strony - zlecający i realizujący - muszą się z tym pogodzić i wiedzieć, że prędzej czy później zetkną się z tworem typu "legacy". Grunt to dobre przygotowanie do takiego przedsięwzięcia i zrozumienie ze strony klienta, że procedura takiego transferu wymaga czasu i odporności na wiele niespodzianek, które wydarzą się po drodze.
Pozdrawiam i dziękuję - Jakub Rojek