Czy przepisać legacy code o czym pamietąc i jak to zrobić

Czy przepisać legacy code

Wcześniejsze wpisy o zastanym kodzie.
1. Jak zrozumieć legacy
2. Testy w legacy codzie
3. Usunięcie zależności w zastanym kodzie

Jeśli pracujesz z zastanym kodem, możliwe ze często zastanawiasz się czy nie przepisać legacy od nowa. Przecież wtedy będzie on lepszy, bardziej czytelny, używał najnowszych technologii. Przecież każdy się na to zgodzi i nie ma żadnych minusów. Ale czy naprawdę?

Nie zapomnij

Po pierwsze bardzo możliwe, że system powstawał przez kilka lat. Z tego powodu, jego przepisanie to co najmniej kilka – kilkanaście miesięcy pracy. Nie zapominaj, że przez ten okres stara aplikacja jest wciąż w użyciu. To kto będzie pisał nową aplikację? Cały team, jedna osoba, nowi ludzie? A może podział będzie taki, że przez połowę czasu rozwijasz nowy program a resztę utrzymujesz starą aplikację? Jeszcze jeden drobny szczegół – w starym kodzie jest na pewno mnóstwo logiki o której nie ma wzmianki w żadnym bug trackerze ani żadnej dokumentacji. No i najważniejsze z biznesowego punktu widzenia – czy taka operacja w ogóle się kalkuluje i czy starczy pieniędzy na przepisanie systemu zanim zacznie on zarabiać?

Delegacja

Często stare systemy są w takim stanie, że ich rozwój o nowe funkcjonalności jest bardzo trudny czy wręcz niemożliwy. Jednak w jakiś sposób funkcjonalność trzeba dostarczyć. Refactor staje się niezbędny. O ile ta funkcjonalność jest w niewielkim stopniu zależna od starej aplikacji to jesteś w dobrej sytuacji. Możesz użyć ddd, architektury hexagonalnej albo nawet oprzeć funkcjonalność o zasięg pakietowy i później w jednym miejscu się wpiąć do legacy kodu. Jeśli funkcjonalność mocno ingeruje w istniejący system, możesz wtedy delegować wywołania z nowego kodu do tamtych miejsc. Delegacja może odbywać się między innymi poprzez resta, wywołanie serwisów. Kiedyś pracowałem z jednym z BPMów. Podczas refactoringu aplikacji zmiany tam nie dawały takich korzyści jak w innych miejscach, więc w nowym kodzie za pomocą resta strzelałem do starej aplikacji i tam wywoływałem zdalnie zastany kod. Jednak takie podejście też wymaga refactoringu i testów dla przepisywanego legacy code.

Nowy klient

Innym przypadkiem jest nowy klient, który chce kupić Twoją aplikację. Jednak okazuje się, że chce tylko 20% funkcjonalności starej aplikacji albo jego wymagania po głębszej analizie nie są jeden do jeden z systemem. Taka sytuacja jest bardzo dobra z tego powodu, że istnieje ktoś kto zapłaci za to co zrobisz. Napisanie tych funkcjonalności od nowa będzie łatwiejsze i będzie dokładnie tym co chce klient bez dodatkowej ifologi. Bardzo możliwe, że ta praca będzie takim wstępem do wyodrębnienia cora aplikacji i wokół tego będzie można przepisywać legacy code do nowej wersji.

Mały krok

Istnieje jeszcze krok pośredni. Gdy szansa na przepisanie systemu jest mała a refactor jest zbyt skomplikowany, spróbuj podmienić jakiś widok wewnątrz aplikacji. Oczywiście, niech to nie będzie główny ekran ale może jakieś ustawienia, profil, coś mniej ważnego. Spróbuj stworzyć front oraz backend w taki sposób w jaki chciałbyś napisać wszystko od nowa. Dzięki takiemu prototypowaniu będziesz w stanie sprawdzić czy to w ogóle ma sens i czy warto iść w tę stronę. A nie dopiero po dłuższym czasie stwierdzić, że nowy system zanim będzie skończony już stał się legacy.