Nie, to nie tylko niewspierane starocie.

Propozycja definicji

Zacznijmy od definicji starszego oprogramowania. Właściwie istnieje wiele różnych definicji ale co powiesz na taką: legacy software to każde oprogramowanie, którego teraz nie piszesz. To usuwa negatywne skojarzenie wyłącznie z oprogramowaniem, które już nie jest wspierane albo zapomniane leży czternasty już rok na serwerze albo w sterowniku tej obrabiarki w tamtym kącie hali. Jeśli pull request został przesłany wczoraj i został włączony do produkcji, to tak, to też jest legacy code.

Czasami (zawsze) deweloperzy boją się zmienić starszy kod. To nie jest nierozsądne. Strach może wynikać z niewystarczającego pokrycia testów, braku dokumentacji, przestarzałej technologii lub skomplikowanej zależności między modułami. Zmiana tego stwarza duże ryzyko, ponieważ zmiana może skutkować nieprzewidzianym wpływem na cały kod, który jest od tej zmiany zależny.

Problemy legacy software

Jakbyśmy nie próbowali więc pozytywnie wypowiedzieć się o „starym” kodzie (choćby kilkudniowym) to niesie on z sobą pewne nieusuwalne wręcz problemy. Przede wszystkim jest on obsługiwany przez skończoną liczbę osób, które „wiedzą, jak to działa”, a wszelkim próbom wprowadzenia nowych osób do tego kręgu towarzyszy frustracja i wysokie ryzyko biznesowe. Firmę można więc złapać w bardzo niebezpieczną pułapkę, jeśli zewnętrzny sprzedawca utrzymuje stary kod a nikt w firmie nie wie, jak nim zarządzać lub nie ma do niego dostępu. Firma musi mieć jasny i skuteczny sposób zarządzania, zmiany i zrozumienia każdego elementu oprogramowania i technologii, na której polega.

Pierwsze symptomy nadchodzących problemów to:

• Niewystarczające pokrycie testu (lub brak testów)
• Brak dokumentacji projektowej, tylko niewielki podzbiór inżynierów wie, jak utrzymać kod
• Zastosowana technologia jest przestarzała
• Ryzyka biznesowe
• Dodawanie nowych funkcji lub zmiana istniejących funkcji staje się wolniejsze
• Wiedza jest skoncentrowana w małej grupie programistów

Stare nie jest złe gdy się je rozumie

Starsze oprogramowanie jest wszędzie. Nie można tego faktu postrzegać od razu negatywnie, wyobrażając sobie duży, przestarzały system lub rozwiązanie, które istnieje od ponad dziesięciu lat. Faktem jest, że oprogramowanie zmienia się tak szybko, że narzędzia, a nawet podejście używane do konstruowania oprogramowania mogą stać się przestarzałe w ciągu kilku miesięcy. W takim przypadku ważne jest, aby spojrzeć na oprogramowanie jako na coś, co ewoluuje, na coś, o co należy dbać i stale dbać o stan jego hmmmm zdrowia.

Sprawdź oferty pracy na TeamQuest

Owszem, trudno jest prosić o środki (czyt. pieniądze) na zatrudnienie nowych deweloperów wyłącznie w celu rehabilitacji systemu, który może nieco zaczynać trącić myszką. Najgorsze jest wyjaśnienie niektórych bardzo technicznych kwestii osobom nietechnicznym. Możesz usłyszeć „Dlaczego to nie jest OK? Zawsze działało więc czemu zmieniać?”.

Tymczasem każdy system w pewnym momencie potrzebuje pomocy. Tymczasem nowe potrzeby biznesowe są największym czynnikiem powodującym problemy z konserwacją starszego kodu, ponieważ często łatwiej jest znaleźć szybkie rozwiązanie, zamiast wracać, planować i przeglądać całą architekturę oraz szukać najlepszego sposobu dodania nowej funkcji do legacy code’u.

Dobra wiadomość jest taka, że jeśli starsze oprogramowanie wymaga ulepszeń, można zrobić naprawdę pozytywne postępy przy niewielkim budżecie. Można korzystać z narzędzi takich jak Code Climate, sprawdzać zależności i monitorować złożoność kodu. Ale najważniejszą rzeczą, jaką musisz zrobić, jest ciągłe upewnianie się, że systemowi poświęcana jest odpowiednia ilość czasu i wysiłku, aby był zdrowy i zdrowy. Cykliczne wysiłki są tu lepsze niż jednorazowy sprint a profilaktyka tańsza niż leczenie.

Zobacz też nasz artykuł o aktualizacji dużego systemu na przykładzie produktów Oracle’a.