Przepisanie starej wersji aplikacji na nowe technologie

Cześć,
Będziemy przepisywać obecną apke w pracy robioną przez 2 developerów (front js i backend python) na nowsze technologie. Za frontend bede odpowiadał ja, a problem jest w tym ze jestem tylko mid developerem. Zaden ze mnie senior, zaden ze mnie architekt. Uważam się za osobe która jest dobra w tym co robi ale nadal mam swiadomość że mam nieco tylko ponad 3 lata doświadczenia.
Wczesniej pracowałem w korporacji, wiec jezeli były tworzone nowe system to ja jako zwykly developer dostawałem juz gotową dokumentacje stworzoną przez sztab ludzi. Nie mialem
wiekszej odpowiedzialnosc.

Do tego dochodzi to że w nowym stacku nie mam doświadczenia zawodowego, ani nigdy tak naprawde nic nie pisałem, jednak uzywałem podobnych bibliotek do tej pory i podobnych założeń tj. web komponenty, zarzadzanie stanem, observable pattern, streamy czy immutable data structures. Tylko robilem to nie za pomocą React'a który będzie teraz a za pomocą np. Mercury. Czy zamiast Rx'a miałem most.js albo zamiast Redux'a to mialem swoja implementacje tej biblioteki.

W biurze bede (a w sumie juz zaczalem) konsultowac pewne sprawy z kolegami ktorzy sa doswiadczeni w tych technologiach.

Mimo że mam plan, jestem nawet pewny siebie to ciągle mi siedzi w głowie to że takimi rzeczami powinien się zajmować ktoś kto ma np. 7 lat doswiadczenia i np. w przeszłości był tech leadem.
A nie pasjonat JS developer z ponad 3 letnim starzem w programowaniu.

Czy mam racje? Czy po prostu powinienem przestac plakac i wziaść sie do roboty :)

Pozdrawiam

Myślę, że może wyjść tak jak zawsze - zrobisz syf w projekcie, ale:

• dostaniesz miliony monet za swoją pracę
• dostarczysz jakąś wartość biznesową dla swojego pracodawcy
• oraz: wyciągniesz kupę nauki na przyszłość dla siebie (jak być lepszym programistą) i swojego zespołu (jeśli będziesz skłonny dzielić się wiedzą)

Tak zwykle jest - masę projektów jest pisana przez niedoświadczonych programistów i są brzydkie jak noc, a mimo to wszyscy są zadowoleni.

Będziemy przepisywać obecną apke w pracy robioną przez 2 developerów (front js i backend python) na nowsze technologie.

tu się rodzi pierwsze pytanie - czemu przepisujecie ją na "nowsze technologie"? (jak na ironię wczoraj tu na forum sobie jaja robiłem z takiego podejścia do tworzenia oprogramowania):

Wszystko jest takie samo, a jednak inne jest wszystko, bo wyszedł nowy framework i całą apkę trzeba przepisywać na nowo, bo w Angularze będzie lepsza niż w Backbone, w React lepsza niż w Angularze. Miotanie się bez celu xD

nie mówię, że to jest właśnie ten przypadek, ale tak mi się skojarzyło ;)

Będziemy przepisywać

Warto więc wyciągnąć naukę z tego co poszło źle w tamtym projekcie, że aż trzeba go przepisywać (nauka na błędach). BTW kto robił poprzednią wersję? Jeśli ty jej nie robiłeś, to masz większy problem niż wejście w nowy stack technologiczny. Wejście w rozwinięty już projekt, i zrozumienie go może być trudne (szczególnie jeśli zachodzi jeden albo więcej warunków: 1. projekt jest duży 2. jest słabo napisany 3. nie ma dokumentacji 4. nie ma testów 5. nie ma kogo spytać, bo np. ten kto to robił już tu nie pracuje). To może być ból.

Do tego dochodzi to że w nowym stacku nie mam doświadczenia zawodowego

no to protip: eksperymentuj zanim wrzucisz coś na produkcję. Róbcie spike solutions: http://www.extremeprogramming.org/rules/spike.html
Tylko na to musi być wydzielony czas, żebyś mógł np. przez kilka dni sobie eksperymentować z różnymi rozwiązaniami - co za tym idzie musi być w projekcie zrozumienie do takich praktyk. Bo inaczej będziesz eksperymentować na produkcji i będziesz wrzucał syfy do mastera, jak to się też często dzieje.

No i rodzi się pytanie: co to znaczy "w nowym stacku"? To znaczy wybraliście już cały stack technologiczny na starcie? Trochę moim zdaniem bez sensu decyzja. Lepiej jest nie myśleć w kategorii stacku jako całości od razu, tylko raczej kompletować stack wraz z potrzebami projektu.

No i warto pamiętać, że w programowaniu ważniejsze są ogólne zasady programowania (np. Single Responsibility Principle, Don't Repeat Yourself itp.), natomiast stack technologiczny to szczegół.

że takimi rzeczami powinien się zajmować ktoś kto ma np. 7 lat doswiadczenia i np. w przeszłości był tech leadem.

Sam musisz podjąć decyzję czy podjąć tę odpowiedzialność, czy może wydelegować kogoś innego do tej roboty, zgłosić potrzebę zatrudnienia seniora, whatever.

Ja mam 2 lata doświadczenia i niedawno sam się podjąłem czegoś takiego. No.. z tą różnicą że ja zdecydowałem się na przepisywanie inkrementalne.

Przepisywanie całej aplikacji na hura przypomina trochę waterfall i niesie za sobą wszystkie jego konsekwencje. Pol biedy jeżeli osoba, która brala udział w stawianiu fundamentów nadal z Wami pracuje. Jeżeli nie, a projekt jest duży i Wasza znajomość nowej technologii słaba to istnieje duże ryzyko, że powstanie taka sama kupa jak jest obecnie, tylko że z użyciem super modnego frameworka. No ale jak to mówią lepiej jest plakac w Porsche.

Poza tym klienta nie obchodzi, czy masz to napisane w reactjs, angularze, czy czymś innym. Jego obchodzi czy coś działa i i tak długo jak działa to jest szczesliwy. W dużych aplikacjach często są moduły, które powstały dawno temu, ten kto to spłodził już tu nie pracuje, ale odziwo wszystko działa. Na szczęście nie trzeba ich ruszać, bo wymagania się nie zmieniają, a jeżeli już to bardzo rzadko. W tej sytuacji praca włożona w przepisywanie takiego modułu może się szybko nie zwrocic.

Moim zdaniem lepiej jest przepisywać po trochu, a zacząć od modułów krytycznych. Legacy kod można ukrywać pod różnymi abstrakcjami (obiekt metoda, delegacja) i wracać do nich jak zajdzie taka potrzeba. Dzięki temu nie musisz zamrażać wdrażania nowych wymagań na czas przepisywania projektu. U nas się to sprawdziło. Część requetow jest przekazywana do nowej aplikacji. Tam wszystko jest ładne piękne i pachnące (jeszcze :)). W internecie jest sporo technik, które pomagają rozwiać problem współpracy tych dwóch aplikacji, tak żeby smród starej nie przeszedł do nowej.

Oczywiście miej na uwadze, że nie jestem jakimś senior architektem leadow. Po prostu mówię co się u mnie sprawdziło i dlaczego, ale nie mam porównania.

Zgadzam się z kolegą @Desu. Mam doświadczenie właśnie z takim sposobem przepisywania systemu. Pisanie na "hurra", ludzi którzy to pisali dawno już nie ma, nowa nie znana w zespole technologia. Potwierdzam w 100% to co napisał powyżej, wychodzi z tego niezła kupa. Dodatkowo dochodzi do tego ogromna frustracja w zespole i codzienna męczarnia z: nowym technologiami, brakiem doświadczenia i wiedzy o tworzonym produkcie. Nie polecam.
Podejście inkrementacyjne, jeśli jest możliwe może być rzeczywiście dobrym pomysłem.

Nowy system tworzysz początkowo tylko jako fasadę do starego, później przenosisz funkcje biznesowe (sugeruję zacząć od najłatwiejszych) ze starego do nowego. Jak przeniesiesz wszystkie, to stary nie jest już potrzebny.

Współczuję ludziom, który myślą że muszą wszystko przepisywać na nową technologię. Taka ironia... Jaki będziecie mieli z tego zysk ? A ile wam to zajmie ? Kiedy to się zwróci ?

Ja pracuję z aplikacją w która jest w 1/3 w technologii która nie jest rozwijana - i co z tego, są w niej moduły, które nie opłaca się przepisywać. Ticketów jest mało, zmian jako takich prawie wcale. Po pół roku prac może przepiszemy te moduły - a przez następne pół będziemy poprawiać jakieś głupoty po takich przenosinach.