Migracja legacy projektu do nowszych wersji języka, frameworka, biblioteki

Macie jakieś doświadczenia w kwestii związanej z podnoszeniem projektów do aktualnie zalecanych wersji języka, frameworka, biblioteki itd?

Przykładowo mam legacy projekt w PHP 7 ze starym Symfony - założmy niech będzie to wersja 2.8 LTS. Teraz chciałbym podnieść PHP do 8.1.6 a Symfony do 6.0 i tu pojawiają się pytania - jak się za to profesjonalnie zabrać? Co wiedzieć, na co zwrócić szczególną uwagę? Przypuszczam, że podnoszenie legacy projektów musi być koszmarem, ale przecież ktoś to musi robić.

Przy takim drastycznym przeskoku o kilka numerów i kilka(naście) lat to są duże szanse, że będzie to praktycznie pisanie tego od nowa.

witcher1 napisał(a):

Przykładowo mam legacy projekt w PHP 7 ze starym Symfony - założmy niech będzie to wersja 2.8 LTS. Teraz chciałbym podnieść PHP do 8.1.6 a Symfony do 6.0 i tu pojawiają się pytania - jak się za to profesjonalnie zabrać?

Przeczytać listę breaking changes każdej wersji, sprawdzić ile nieistniejących już fukcji/modułów/klas używasz w swoim kodzie.
Możliwe, że są jakieś instrukcje migracji, też je przeczytać.
A może jest jakieś narzędzie, które wspomaga ten proces? Poszukać nie zaszkodzi.
Nie pytać na 4p - tu sami juniorzy hipsterskich technologii, dla nich wszystko jest niemożliwe. ;)

Punkt pierwszy musisz wiedzieć co ten projekt robi. Musisz mieć rozpisane przypadki użycia praktycznie dla 100% funkcjonalności. Krok drugi, to sprawdzenie czy to wszystko działa. Zrobić testy funkcjonalne całości i możliwie duży porządek w tym co masz w tej chwili, usunięcie kodu, którego już nikt nie używa, wyizolować kod biznesowy od kodu frameworku. Dopiero wtedy podbijać biblioteki/frameworki. Jak ktoś wyżej napisał - w kompilowanych jest prościej, bo jakieś grubsze rzeczy wywali ci już sam kompilator, dlatego pewnie automatyzacja testów będzie dobrym pomysłem.

Przypuszczam, że podnoszenie legacy projektów musi być koszmarem, ale przecież ktoś to musi robić.

Jak już ktoś wspomniał - to zależy od platformy/języka. Generalnie w wielu przypadkach jest to dość proste zadanie.
Zasada numer jeden to podnosić często i nie czekać, aż będą 4 wersje do przeskoczenia.
Zasada numer dwa to nie używać PHP, ani żadnego innego języka, który nie kuma typów podczas kompilacji.

Profesjonalnie to wypadałoby mieć jakieś testy, które sprawdzają czy projekt dalej działa tak jak powinien. Ewentualnie używanie języków/platform, które nie mają takich problemów albo krzyczą głośno jak coś przestało działać

witcher1 napisał(a):

Macie jakieś doświadczenia w kwestii związanej z podnoszeniem projektów do aktualnie zalecanych wersji języka, frameworka, biblioteki itd?

Tak

Przykładowo mam legacy projekt w PHP 7 ze starym Symfony - założmy niech będzie to wersja 2.8 LTS. Teraz chciałbym podnieść PHP do 8.1.6 a Symfony do 6.0 i tu pojawiają się pytania - jak się za to profesjonalnie zabrać?

Jak już wspomniano profesjonalnie to jest mieć testy i nie być cztery wersje w tył. Ja bym podnosił po jednej dużej wersji do góry. Czyli 2.8 -> 3.x -> 4.x i tak dalej

Co wiedzieć, na co zwrócić szczególną uwagę?

Ogólnie że wszystko może się wywalić

Przypuszczam, że podnoszenie legacy projektów musi być koszmarem, ale przecież ktoś to musi robić.

Dla jednych koszmar, dla innych frajda. Pół roku nie musiałem gadać z biznesem :D

witcher1 napisał(a):

Macie jakieś doświadczenia w kwestii związanej z podnoszeniem projektów do aktualnie zalecanych wersji języka, frameworka, biblioteki itd?

Przykładowo mam legacy projekt w PHP 7 ze starym Symfony - założmy niech będzie to wersja 2.8 LTS. Teraz chciałbym podnieść PHP do 8.1.6 a Symfony do 6.0 i tu pojawiają się pytania - jak się za to profesjonalnie zabrać? Co wiedzieć, na co zwrócić szczególną uwagę? Przypuszczam, że podnoszenie legacy projektów musi być koszmarem, ale przecież ktoś to musi robić.

• Testy automatyczne pomagają, ale takie prawdziwe. Mockito-brandzlowanie tylko przeszkadza.
• Spróbuj posprzątać przed upgrade.
• Naucz się żonglować gitem i fixupami. Ja często odkrywam konieczność refaktoringu i wtedy się cofam do stanu sprzed upgrade.
• Wybierz strategicznie moment ataku. Tuż przed ważnym deadline to zły pomysł.
• Najlepiej pracować samemu.
• Nikt ci nie zrobi przydatnego code review. Działasz na własną odpowiedzialność.