Mam na myśli to, że nowy serwis tworzą Ci sami ludzie którzy tworzyli stary. Spodziewacie się zrobić coś super, ale wyjdzie wam to samo co wcześniej.
Nie, nie. Starta appka jest napisana glownie przez 3 gosci. Zaczeli ta apke 2015 rok. Teraz kazdy z nich ma 40 albo grubo sa po 40tce. Wydaje mi sie, ze oni nie nadazaja juz nad technologia. Teraz firma zatrudnila 3 nowe osoby. Z czego jestem tez ja. I wydaje sie, ze ludzie dosc kumaci. po prostu chcemy zrobic wszytko, zeby juz przestac pisac niskiej jakosc kod. I druga sprawa chcemy zabrac troche tej aplikacji od tych wyjadaczy, zeby nie czuli sie tacy wazni i potrzebni. Bo taka jest prawada.
I pomyślałeś że ogromną rewolucja w której tworzycie projekt od nowa to jest dobry pomysł na to? To się na pewno nie uda.
Jeśli na prawdę chciałbyś zacząć pisać dobrej jakości kod, to przede wszystkim musisz wiedzieć jaki kod jest wysokiej jakości a jaki nie. I tutaj przykra informacja: każdy zawsze myśli że jego kod jest wysokiej jakości, nie ważne czy jest tak w istocie czy nie.
Po drugie, takie rewolucje prawie nigdy się nie udają. Żeby zrobić coś takiego musiałbyś mieć bardzo dobrą wiedzę na temat tego jak ten system działa, a z tego co piszesz, to nie masz jej.
To wygląda tak jakby ktoś Ci kazał pisać w aplikacji bardziej starej, Tobie się to nie podoba, ale też nie jesteś w stanie jej jakoś szybko naprawić, więc żeby zminimalizować swoje prywatne cierpienie stwierdzasz że lepiej będzie dla całego produktu jak stworzycie nowy projekt i tam będziecie kontynuować pracę. Tymczasem to jest głównie lepsze dla Ciebie, bo nie musiałbyś poprawiać shitcode'u, co wyjaśnia czemu tak bardzo chcesz to zrobić.
Jeśli chcesz na prawdę zrobić coś co jest dobre dla projektu, to:
- jeśli masz testy które trwają za długo, powiedzmy dłużej niż 5 minut, to poszukaj sposobów żeby je przyspieszyć
- jeśli nie ma testów, to napisz jakieś
- znajdź miejsca w kontroli wersji gdzie jest najwięcej bugów i najwięcej czasu schodzi i spróbuj zrefaktorować albo przepisać to miejsce
- usprawnij proces deploya, tak żeby wdrożenia trwały krótko i były najbardziej zautomatyzowane jak się da, najlepiej całkiem
- usprawnij proces wytwarzania oprogramowania , tak żeby jeśli chcesz poprawić literówkę to żeby dało się dodać commit , review I deploy np w ciągu jednego dnia nie powinno być problemem
- znajdź najczęściej edytowane klasy i refaktoruj je
- spróbuj zaktualizować stare zależności
To byłby faktyczny wkład w rozwój tego projektu.
Jak zrobisz nowy projekt to tylko skomplikujesz wszystko, bo teraz będą dwa projekty , dwie wersje php, wszystkiego po dwa. Tobie będzie łatwiej pisać w php8 przez chwilę, ale produkt stanie się jeszcze bardziej mniej utrzymywalny niż teraz jest.