[mirko_anonim]

✨️ Jak uniknąć problemów przy aktualizacji frameworka PHP? Ⓘ
Opiszę, w jaki sposób straciłem pracę w jedynej mającej oparte na PHP własne produkty (nie software house) firmie w moim mieście. Znalazłem już inną pracę, ale moje pytanie to: co następnym razem przy zadaniu typu aktualizacja frameworka muszę robić inaczej niż robiłem, żeby nie powtórzyła się taka sama lub podobna sytuacja?

Kilka lat temu dostałem w pracy (programista PHP) zadanie: uaktualnienie Laravela (frameworka PHP) w dużym projekcie z wersji 4 do 7.

Mój plan realizowania tego zadania był taki:
- uaktualnię samego Laravela, po czym przejdę do dostosowywania kodu aplikacji
- stworzę na podstawie changelogu Laravela listę rzeczy, których warto poszukać grepem i poprzerabiać, żeby działały z nowym Laravelem (powstała ogromna lista)
- stworzę na podstawie konfiguracji routingu listę wszystkich podstron (aplikacja nie jest typu SPA, tylko z tradycyjnymi podstronami), żeby je przeglądać w poszukiwaniu niedziałających funkcji

Doprowadziłem projekt do takiego stanu, żeby w ogóle coś innego niż biała strona było widoczne w przeglądarce i żebym mógł się zalogować.

I później przez jakiś miesiąc naprzemiennie robiłem dwie rzeczy:
- brałem kilka punktów z listy rzeczy do zmiany stworzonej na podstawie changelogu i je zmieniałem, żeby działały z nowym Laravelem
- brałem kilka podstron z listy podstron i je ręcznie w całości przeklikiwałem, naprawiając każdy znaleziony problem, których było pełno

Każde swoje rozwiązanie oczywiście od razu testowałem, czy działa w pełni dobrze.

Z tego co pamiętam, zmieniałem około 300-500 linii kodu na dzień, w różnych częściach projektu.

Po w przybliżeniu miesiącu przerwano mi pracę nad tym zadaniem, bo "skoro zajmuje tyle czasu, to nie ma sensu, zostaniemy przy starej wersji". Szacuję, że zrobiłem około połowy wszystkiego, co było do zrobienia, tzn. gdybym dostał jeszcze drugi miesiąc na robienie tego, wszystko by się udało.

Teraz niedawno, czyli wiele lat później po tej "nieudanej" (przerwanej mi z powodu zajmowania za dużo czasu) aktualizacji Laravela, jeden z kluczowych klientów zażyczył sobie czegoś, co można prosto w kilka dni zrobić przy użyciu jednego z gotowych dostępnych w internecie pakietów dla nowszych wersji Laravela, ale nie dla starszych, a zrobienie tego samodzielnie od zera zajęłoby więcej czasu niż klient jest w stanie czekać.

Klient ten zrezygnował z oprogramowania (aplikacji SaaS) mojego pracodawcy i przeszedł do konkurencji oferującej potrzebną mu rzecz.

Mój przełożony jakiś tydzień później stwierdził, że okłamałem go kilka lat temu, że uaktualnienie projektu do nowej wersji Laravela zajmuje tyle czasu, a nie mniej, bo pobawił się tym w weekend i niby od początku soboty do końca niedzieli zrobił to, czego połowę ja robiłem w miesiąc. Wyniku swojej pracy nie pokazał, twierdząc że nie ma kodu przy sobie, na pytanie co robił inaczej niż ja odpowiedział że używał wyrażeń regularnych do masowego edytowania kodu (co ja w sumie też robiłem, ale udało mi się w przypadku mniej niż 1% rzeczy, poza tym i tak trzeba sprawdzać ręcznie działanie tego wszystkiego, co np. sed na podstawie wyrażenia zmienił) i że pomijał sprawdzanie działania rzeczy, co do których domyślał się, że działają (co wydaje mi się absurdalne).

Ja powiedziałem, że moim zdaniem nie dało się tego robić znacznie szybciej niż ja robiłem, że w odpowiedniej gałęzi repozytorium widać, co podczas tej próby aktualizacji robiłem którego dnia i ile kodu dziennie zmieniałem, że mogę coś powyjaśniać, powiedzieć w jaki sposób doszedłem do tego, że zmiany wymagało akurat to co zmieniłem, co by źle działało bez konkretnej mojej zmiany w kodzie itd. ale nie chciał ze mną rozmawiać.

Firma krótko po tym zdarzeniu "zlikwidowała moje stanowisko" (co jest w sumie dla mnie lepsze niż np. jakieś bzdury o mojej wydajności wpisane w świadectwo) i chwilę później druga spółka z o.o. mająca biuro w tym samym miejscu zaczęła szukanie kogoś innego na moje stanowisko.

Tak więc, co następnym razem przy zadaniu typu aktualizacja frameworka muszę robić inaczej niż robiłem, żeby nie powtórzyła się taka sama lub podobna sytuacja?

#programowanie #pracait #php #webdev

〰〰〰〰〰〰〰〰〰〰〰〰〰〰〰
▶︎ Obserwuj nasz tag #mirkoanonim
〰〰〰〰〰〰〰〰〰〰〰〰〰〰〰
· Akcje: Odpowiedz anonimowo · Więcej szczegółów
· Opublikuj swój własny wpis: Mirko Anonim
· Zaakceptował: mkarweta

👉 Z Twoją pomocą możemy działać dalej! Wspomóż projekt

[blackredwhite]

@mirko_anonim: zacząć używać AI, w dobie dzisiejszych narzędzi to głównie bardzo rozbudowany dobrze skonstruowany prompt który należy kilka raz sprawdzić po

[TurboDynamo]

@mirko_anonim: nie mogłeś zrobić nic lepiej. Po prostu manager zwalił na ciebie odpowiedzialność za utratę klienta bo gdyby tego nie zrobił to pewnie sam by poleciał.

[Jare_K]

@mirko_anonim: przy złożonym projekcie robiłbym raczej migracje o jedną wersję do przodu, po kolei. Odpalasz piątkę i masz listę deprykacji dla szóstki. Odpalasz sztóstkę i to samo dostajesz dla siódemki. Nagły skok o kilka wersji wywala działanie i bywa ciężko dojść do źrodła problemów. Natomiast z drugiej strony nie wiem, czy larwa stosuje takie podejście jak Symfony co do deprecated i zaleceń zmian podczas migracji.

[Diabl0]

@mirko_anonim: zaczął bym od aktualizacji inkrementalnej - nie z 4 od razu do 7, ale stopniowo. Mniejszy jednostkowy changeset i breaking changes do ogarnięcia, łatwiejsze testowanie, mniej blokowania bieżącego rozwoju aplikacji, częstszy update zespołu i pokazanie mierzalnych efektów pracy.

z version history widzę:
→ Laravel version 4.0
→ Laravel version 4.1
→ Laravel

[MacDada]

@mirko_anonim: Metoda „małych kroków” – zamiast zrobić duży upgrade z 4 do 7 i tym samym od razu MASA zmian, lepiej zrobić mniejszy upgrade z 4 do 5, itd. Przy tym raportować na jakim etapie się jest.

Najwyżej np zatrzymasz się na wersji 5 i już to będzie „coś do przodu”. A nie, że projekt wraca na wersję 4 i cała Twoja praca poszła na marne.

[Jare_K]

@Diabl0: masz niemal identyczną propozycję. Natomiast ja nie bawiłbym się w zmianę o wersję minor, skoro nie ma breaking changes. 4.0 -> 5.8 -> 6.3 -> 7.1 itp.

[preseed42]

@mirko_anonim: dobrze, ze znalazłes nowa robote ;)

mnie kiedyś wywalono, bo raczyłem wspomnieć, że publicznie dostępne serwery na systemach EOL od 6 lat to nie to czego się oczekuje w IT , klient zrobił audyt, wyszło wszystko (a nie miał dostępu do środka)

manager z mordką do mnie dlaczego to nie załatane i jak to możliwe, żeby tak było zaniedbane, ja przytoczyłem korenspondecję, z zeszłego roku, włącznie z odpowiedzią, że "mamy

[Diabl0]

@Jare_K:
Od lat nie siedzę w PHP (a nawet wtedy nie używałem laravel) po prostu wskazałem na podstawową praktykę.

Na pewno na początku trzeba było by przeprowadzić jakąś wstępną analizę jakie zmiany w międzyczasie zachodziły, jaka jest wiarygodność changelogów czy trzymanie się zasad minor/major release i na tej podstawie zaplanowanie wstępnej strategii ale to już jest zależne od konkretnego przypadku.

Edit: Widzę że pisaliśmy w tym samym czasie, bo jak

[Saly]

@mirko_anonim: najlepiej napisać testy. Jak ich nie masz to:
* postawić apkę w sposób hermetyczny np. z pustą bazą w dockerze
* prosisz AI o wygenerowanie requestów/responsów na bieżącej wersji, które testują mniej więcej wszystko co się da
* patrzysz czy wszystko jest deterministyczne. Szum (np. inny output, ale robi to samo) możesz wyfiltrować przy użyciu bardziej złożonych asercji niż ma być to samo
Po czy każesz AI zrobić migrację. Napisane testy regresyjne w

[Desseres]

@mirko_anonim: z tego co opisujesz to nic nie zrobiłeś źle.
Miałeś spłacić ~7 lat długu technologicznego najlepiej w 2 godziny? Manager przyjął c-----ą estymatę.

Podczas migracji zawsze coś się w-----e, podszedłeś do zadania odpowiedzialnie, na daily lub weeklu manager powinien statusować Twój progres prac i szybciej podjąć decyzję o zbyt dużym tasku, lub braku zasobów na tak duże spłacenie długu technologicznego.

Testowałeś zmiany, tj. projekt nie miał napisanych testów? Jak nie to

[cufse]

Projekt od początku powinien być pokryty testami, ale pewnie nie było tam żadnego testu. Przeczytałem, w chatgpt, że Laravel jest do prototypowania i nic poważnego się w tym nie robi.