Legacy - decyzja o pisaniu od nowa lub przerabianiu istniejącego systemu.

Jestem ciekawy wniosków, bo podejście „napiszmy od zera” nie kojarzy mi się z niczym dobrym - może powstać kupa v2, którą ciężko ztimeboksować. Jestem zwolennikiem stopniowego wychodzenia z bagna, ale jestem ciekawy jak będzie w Twoim przypadku. Są firmy, które się przepisują kilka lat i wcale nie cały codebase.

Kiedyś byłem świadkiem sytuacji jak był przepisywany cały mikroserwis, nowy package v2 i ogień, jeśli dobrze pamiętam to v2 jeszcze nie zostało skończone, ale już pojawiła się paczka v3 :D

Nigdy więcej legacy.

Legacy innemu legacy nierówne. Mój obecny projekt jest od 25 lat na rynku i wiele jest takich fragmentów, które chodź dzisiaj przestarzałe, to w czasie w którym były pisane, zupełnie uzasadnione było by zrobić je tak a nie inaczej.

Tylko, że moje legacy było przez lata pisane przez domenowych ekspertów a nie bandę juniorów, no i "ojciec założyciel" wciąż jest w projekcie i kontrybuuje kod.

Przesłanki za przepisaniem systemu:

• stary system ma tyle błędów i sprawia notorycznie tyle problemów, że naprawienie ich wszystkich i tak spowodowałoby zmianę większości kodu źródłowego
• nowy zespół ma znacząco wyższe umiejętności i doświadczenie niż zespół, który oryginalnie tworzył projekt - np. odziedziczyliście system pisany przez studentów jako ich pierwszy projekt, albo system był rozwijany przez tanich kontraktorów branych z łapanki przez kolejne 10 lat
• technologia starego systemu wypadła z rynku i powoduje problemy użytkownikom (np. macie system oparty o Flash albo applety Javy, które nie są już wspierane) lub problemy z bezpieczeństwem
• technologia systemu była od początku dobrana źle, zmieniły się wymagania i teraz nie da się ich spełnić z powodu ograniczeń w technologii

Przesłanki za poprawianiem przyrostowym:

• system jest w nieco przestarzałej technologii, ale generalnie działa i nie sprawia większych problemów (przykład: jakiś głęboki backend w COBOLU, którego i tak użytkownicy nie widzą)
• przepisanie wiązałoby się np. z nową pełną certyfikacją i innymi problemami natury prawnej lub biznesowej (dot. np. lotnictwa)
• mamy multum użytkowników, którzy zostali przeszkoleni na starym systemie i zmiana działania systemu wymagałyby istotnych nakładów finansowych na ponowne szkolenie
• system jest napisany tragicznie, sypie się na każdym kroku, ale wszyscy lepsi programiści masowo odchodzą do konkurencji a w firmie została jedynie oryginalna ekipa, która stworzyła ten bałagan; nowy bałagan prawdopodobnie nie będzie dużo lepszy, chyba że jakoś uda się zrobić sensowną retrospekcję i trwale zmienić (wprowadzić?) procedury (w praktyce nigdy nie widziałem, żeby się udało - ktoś robi syf w PHP to zrobi też syf w Pythonie czy C++)

Jestem ciekawy wniosków, bo podejście „napiszmy od zera” nie kojarzy mi się z niczym dobrym - może powstać kupa v2, którą ciężko ztimeboksować

Bo nie można zaczynać pisać v2, dopóki się nie pozna przyczyn dlaczego v1 stało się kupą. A następnie nie wdroży odpowiednich zmian. Samo zaczęcie od nowa, czy nawet zmiana technologii to na ogół za mało. U nas jest kilku takich gostków, którzy dostali już chyba trzeci projekt i za każdym razem wychodzi im kupa, którą potem inni muszą poprawiać. I to niezależnie od technologii.

Wracając do hype na Rusta, który ma magicznie chronić nas przed błędami w zarządzaniu pamięcią, to trafiłem ostatnio na ciekawą stronę: https://rustsec.org/advisories/ Lista dziur bezpieczeństwa w ekosystemie Rusta rośnie w tempie wykładniczym z roku na rok. Jak widać, autorzy bibliotek Rustowych wolą zaryzykować https://en.wikipedia.org/wiki/Memory_corruption niż kopać się non-stop z borrow checkerem.

@Krolik:

Dzięki wielkie za merytoryczną odpowiedź.
Na tę chwilę jestem zachwycony decyzją. Z jednej strony człowiek sobie uświadamia ile dupereli, w tym graficznych trzeba napisać, ale z drugiej widać w jakim tempie praca idzie do przodu i jak łatwo łączyć ze sobą systemy, którą są dobre i napisane od samodzielnie. Co więcej pisanie od zera to dobry etap, żeby porozmawiać z biznesem, bo okazuje się, że niektóre rozwiązania zupełnie nie były używane i jest zgoda na ich likwidację, albo skrajne uproszczenie.

Aktualnie wszyscy są zadowoleni z decyzji, a tempo powstawania greenfieldów jest nieporównywalne z dłubaniem w nędznym legacy kodzie. Może to jest najmniej istotne, ale przez dobre praktyki i nowsze technologie, performance wzrósł o rzędy wielkości.

@renderme: I jak tam idzie? Ile % rzeczy już działa?

Hehe, idzie bardzo dobrze. Dopiero pare miesiecy, a system dziala sensownie i przede wszystkim jest nad nim kontrola.

Skąd wiesz że będziesz potrafił to napisać lepiej? Skąd wiesz że będziesz mieć czas i że nie pojawią się okoliczności wymuszające pójście na skróty gdy ty będziesz "pisał jak należy"?

Ty jako dev jesteś tylko KOSZTEM w firmie i nikogo nie obchodzi czy kod jest dobry czy zły jeśli zarabia więcej pieniędzy niż generuje kosztów.

Zatem często firma woli żebyś ty spędzał swoje życie na łataniu szamba niż pisać od nowa. Bo jednak taniej jest płacić tobie za pojedyncze godziny poprawiania niż poświęcenie pół roku na pisanie od nowa.

Skąd przekonanie, że to co napiszecie od zera będzie lepsze, od tego co dostaliście? Parę razy widziałem takie akcje i scenariusz z grubsza był taki:

• To co dostaliśmy to kompletne guano nosorożca, nie da się z tym pracować, przepiszmy to od zera
• Euforia, dyskusje o technologiach, bibliotekach, frameworkach, taby vs spacje w nowym kodzie i przepalanie czasu na decyzje pozbawione większego znaczenia
• Decyzja podjęta, paru członków zespołu odchodzi, bo oni chcieli pisać w X, a wybrano Y
• Powstaje szkielet aplikacji, nie robi jeszcze nic użytecznego, ale to przecież tylko kwestia czasu. Ostatecznie gramy w zupełnie innej lidze niż ta banda debili, która napisała guano nosorożca
• Udało się napisać pierwsze ficzery. Może trochę inaczej, może nie robią tego samego co guano, ale to poprawimy później. Teraz zaraportujmy, że się udało i projekt idzie zgodnie z planem
• Biznes zorientował się po roku, że niby mamy już przepisaną połowę projektu, ale ona nie robi tego co miała robić
• Trzeba szybko udowodnić, że jesteśmy w stanie usunąć "drobne niezgodności", pojawia się presja czasu, porzucamy na chwilę fetyszowe traktowanie clean code i dostawiamy parę if'ów
• Mija kolejne pół roku. Nauczeni doświadczeniami z usuwania drobnych niezgodności zaczynamy pytać "co ten system właściwie ma robić", bo jakiś ogólny zarys jest znany, ale jak przechodzimy do szczegółów, to okazuje się, że już nie jest tak prosto, a te wszystkie ify, które tak nas wkurzały w starym kodzie były po coś i część już jest w naszym, a druga część za chwilę będzie.
• Biznes patrzy na przepaloną kasę i osiągnięty efekt, nie dając sobie już więcej wciskać kitu, że to wymaga jedynie drobnych poprawek, projekt "zacznijmy od nowa" idzie do piachu.

Właściwie zawsze cała zabawa kończyła się w momencie, kiedy ktoś zadał pytanie "co ten system ma robić" i okazywało się, że instrukcji do poprzedniego brak, dokumentacji brak, kodu nie da się przeczytać, człowiek, który wiedział co robi jakiś ficzer i dlaczego właśnie znalazł nową pracę, po tej, którą miał po odejściu z naszej firmy. Oczywiście to jedynie moja wąska perspektywa, ale nie znam żadnego zakończonego sukcesem przypadku przepisania większego kawałka kodu w całości, bo zwyczajnie nikt nie wiedział co ten kawałek kodu robi.

Jeżeli chcecie mieć szansę, to można do tego podejść w następujący sposób:

• Pokryć całość znanej funkcjonalności testami integracyjnymi. Jeżeli mamy backend, to bierzemy jego endpointy, piszemy testy, sprawdzamy pokrycie kodu tymi testami, dopisujemy nowe. Wszystko po to, żeby wiedzieć i udokumentować "co robi ten system".
• Zastanawiamy się co robią kawałki kodu, które nie są pokryte testami i dopisujemy do nich testy.
• Stawiamy coś, co zintegruje "stary i nowy system", jakąś fasadę, niech to będzie np. API gateway, na początku przepuszcza wszystko jak leci do "starego", a w miarę postępu prac kolejne kawałki są obsługiwane przez "nowy". Warunek - wszystko musi ciągle działać, musicie być w stanie wypuścić takiego patchworka na produkcję (i wypuszczać)
• Te testy muszą być wykonywane regularnie (
• Nieustannie dbać o jakość "tego nowego". Tutaj nie może być żadnej tolerancji dla szybkich rozwiązań, przy okazji dopisujemy testy jednostkowe, tam gdzie to ma sens
• na koniec odłączacie stare i patrzycie, czy testy przechodzą.

Nowy system mozna wypuścić równolegle do starego i porównywać odpowiedzi.
Sa nawet toole do tego:
https://www.infoq.com/articles/tap-compare-diferencia/

tak dla informacji. Decyzja o przepisaniu calosci byla jedyna sluszna decyzja. Jedyne czego zaluje, to ze nie zapadla od razu.

Decyzja o przepisaniu systemu tez zmotywowala do zmian funkcjonalnych. Jedyne czego zaluje to wybor chmury azur przez biznes, szczegolnie azure sql ktore jest demonicznie drogie, jak za swoja jakosc, ale to detale.

Jesli projekt jest w miare maly, to znaczy przepisanie go zajmie max 1-2 tygodnie, to mozna przepisywac.

Jesli wiecej, to moim zdaniem "przepisywanie" legacy code'u jest skazane na porazke (jesli projekt nadal jest utrzymywany).

Jesli natomiast projekt nie wymaga zadnych zmian, i moze sobie pozwolic na zbudowanie calosci od razu, przez np 3-6 miesiecy, i nie musicie potem backportowac zmian z legacy systemu do nowego, to moze i by sie moglo udac.