RedCrescent

Vladislav Avdeev: zrozumienie starszych systemów

Jeden z liderów społeczności IT mówił o starszych systemach

 7:53

NAUKA.

Obecnie legacy-code jest palącym tematem w świecie IT. Czym jest, jakie jest jego miejsce w branży, jak z nim pracować i jakie wyzwania stawia przed najlepszymi programistami? Vladislav Avdeev, jeden z liderów społeczności IT, który ma ponad 10-letnie doświadczenie w branży fintech, przemyśle kosmicznym i nauce, pomógł nam zrozumieć te pytania.

- Co stanowi "dziedzictwo" i jak je postrzegasz?

- Branża dość jasno definiuje główne kryteria legacy: przestarzały stos technologii, niespełnianie przez legacy nowoczesnych wymagań, przestarzałe podejście do rozwoju oprogramowania, słaba dokumentacja lub jej brak.

- Pojawia się jednak również szereg pytań natury filozoficznej: kiedy dokładnie nowoczesne oprogramowanie staje się starsze, być może po upływie określonej liczby lat? Jeśli system informatyczny jest kompetentnie napisany w starym, niewspieranym języku programowania, ale spełnia wszystkie wymagania - czy jest to legacy? A jeśli jutro grupa hakerów znajdzie poważną lukę w najnowszej wersji systemu operacyjnego, czy system ten z dnia na dzień stanie się starszym produktem ze względu na niezgodność z wymogami bezpieczeństwa?

- Uważam, że legacy to proces, któremu podlega każde oprogramowanie od samego wydania, a czasem nawet na etapie rozwoju. Dlatego zadania związane ze spuścizną są bardzo zróżnicowane: od "zaktualizuj kilka linijek kodu, ponieważ framework został zaktualizowany" do "ostatni raz programista był tutaj 20 lat temu".

- Dziedzictwo naprawdę ma swoją własną filozofię! Jak często spotykasz się z nią w swojej pracy?

- W takim czy innym stopniu - w prawie każdym dużym projekcie, ponieważ często jestem głęboko zanurzony we wszystkich aspektach rozwoju. Od czasu do czasu mam bardzo duże projekty, których celem jest albo całkowite przepisanie systemu o krytycznym znaczeniu dla biznesu, albo jego refaktoryzacja - aktualizacja.

Z reguły takie projekty należą do najtrudniejszych. Czasami mamy do czynienia ze starym kodem w przestarzałych językach sprzed 30 lat, który, sądząc po jego objętości, oblicza inflacyjny model wszechświata. Wtedy trzeba zebrać zespół doświadczonych programistów. Ale wszelkie problemy związane z dziedzictwem można rozwiązać przy odpowiednim podejściu. Wierzę, że poważne, udane doświadczenie z dziedzictwem jest znakiem rozpoznawczym starszego programisty.

- Czy to prawda, że deweloperzy starają się unikać pracy związanej z dziedzictwem i dlaczego? Czy ty unikasz takich projektów?

- Tak jak ty wolisz pracować na nowoczesnym komputerze, tak programiści wolą pracować z nowoczesnym stosem. Ponadto praca ze starszymi rozwiązaniami jest poważnym wyzwaniem, które wymaga specjalnych umiejętności. Są to główne powody, które mogą powodować odrzucenie wśród deweloperów. Jednocześnie złożone projekty legacy są często możliwe tylko dla bardzo wybitnych profesjonalistów, ale tacy profesjonaliści mogą sobie pozwolić na wybór spośród wielu innych projektów i często nie poprzestają na legacy. Podczas gdy młodsi, średni, a nawet niektórzy starsi programiści nie mają niezbędnej wiedzy i doświadczenia.

Jeśli chodzi o mnie - nie unikam projektów związanych z dziedzictwem, ale podchodzę do nich selektywnie: niektóre z nich mogą stanowić wyzwanie dla mojego doświadczenia lub dać mi możliwość wdrożenia innowacyjnego podejścia lub pomysłu, który chciałem wdrożyć od dawna. Unikam projektów o niepewnych wymaganiach i takich, które naruszają normy etyczne, ale nie mają nic wspólnego z dziedzictwem jako takim.

- Czym różni się proces rozwoju w przypadku legacy i jakich metod używasz?

- Ogólnie rzecz biorąc, każdy proces tworzenia oprogramowania jest iteracyjny i wygląda podobnie, ale każdy kierunek ma swoje osobliwości. Praca ze starszymi systemami poprzedzona jest dokładną analizą bazy kodu, a także zebraniem istniejącej dokumentacji i jej uzupełnieniem. W niektórych przypadkach część rozwoju może odbywać się w języku używanym przez starszy system: na przykład w celu pokrycia go testami, jeśli z jakiegoś powodu inne opcje nie są odpowiednie. Wiele zależy od zadania: zawsze trudniej jest całkowicie przepisać legacy, ale w niektórych przypadkach jest to najbardziej odpowiednie rozwiązanie niż refaktoryzacja.

Mówiąc o metodach, preferuję nowoczesne zautomatyzowane podejścia wszędzie tam, gdzie jest to możliwe. Najczęściej dla każdego dużego projektu tworzę osobne narzędzia do autoanalizy bazy kodu, które są parserami i zestawami skryptów do tworzenia schematycznej reprezentacji projektu, jego poszczególnych części i ich wzajemnych zależności. To samo podejście stosuję w przypadku przepisywania kodu, ale tutaj sprawa wygląda o wiele bardziej skomplikowanie, ponieważ tak naprawdę mówimy o tworzeniu translatorów kodu z jednego języka programowania na inny. Tworzenie takich narzędzi do automatyzacji wymaga sporo czasu, ale takie podejście wielokrotnie przyspiesza pracę nad dużym projektem. Ponadto taka praca jest inteligentna i angażująca. Ponadto uważam, że zastosowanie technologii sztucznej inteligencji jest najbardziej obiecującym podejściem w takich zadaniach i od czasu do czasu eksperymentuję z trenowaniem modeli sieci neuronowych. Podejście to wciąż ma jednak nierozwiązane problemy, które czynią je nieefektywnym.

- Jak złe jest podejście manualne i dlaczego nie można skorzystać z gotowych rozwiązań lub doświadczeń z innych projektów?

- Podejścia manualne są możliwe i niestety nadal często się do nich uciekają - jest to również powód, dla którego programiści nie lubią legacy. W niewielkim stopniu ręczne podejście jest nieuniknione niezależnie od stosowanych metod, ale jeśli mówimy o moich najbardziej "ciężkich" projektach legacy liczących 200-250 tysięcy linii kodu, całkowicie ręczna praca zajęłaby wiele miesięcy i żaden kompetentny specjalista po prostu nie podjąłby się zrobienia tego w ten sposób. Jest to sprzeczne z samą istotą programowania: wszystko, co można zautomatyzować, musi zostać zautomatyzowane.

Oczywiście istnieją gotowe translatory kodu i już dostępne rozwiązania z innych projektów. Ale wszystko to rzadko może być z powodzeniem wykorzystane ze względu na wspomnianą różnorodność dziedzictwa, które może być kodem napisanym w dziesiątkach języków i mieć wiele unikalnych cech architektonicznych. W tym miejscu jeden projekt legacy różni się od drugiego. Jest to również jeden z powodów, dla których wykorzystanie technologii sieci neuronowych wciąż nie jest wystarczająco wydajne, ponieważ wymagają one rozległego i, co najważniejsze, wysokiej jakości próbkowania danych, co z definicji rzadko może zapewnić starszy kod.

- Jak widzisz przyszłość starszego kodu?

- Tak szybko, jak rozwija się branża, tak szybko "rośnie" spuścizna. Ale spuścizna jest nie tylko obciążeniem, ale także cennym dziedzictwem branży. Pomimo faktu, że nowoczesne podejścia do rozwoju zmniejszają jego negatywny wpływ, a kod starzeje się teraz znacznie wolniej, nie możemy łatwo odrzucić tej spuścizny, ponieważ pod wieloma względami jest ona podstawą naszych osiągnięć. Znajdujemy coraz skuteczniejsze sposoby radzenia sobie ze spuścizną, a technologie sztucznej inteligencji wkrótce sprawdzą się również tutaj. Dziedzictwo jest nieuniknionym elementem naszej branży i uczymy się na nim, aby stać się jeszcze bardziej wydajnym i innowacyjnym.