Praca inżynierska - przepisanie aplikacji

Drodzy,

chciałem poprosić o radę dotyczącą wyboru technologii. W ramach swojej pracy inżynierskiej przygotowuję się do przepisania aplikacji napisanej 8 lat temu w .net framework 4.8 (MVC + Razor). Zastanawiam się pomiędzy nad użyciem Blazora (Server lub WebAssembly) lub ASP.NET CORE MVC.

Ważną informacją jest to, że jest to aplikacja która jest dostępna publicznie (nie jest to wewnętrzna aplikacja biznesowa). Korzysta z niej kilka tysięcy użytkowników (powiedzmy dwa-trzy razy w miesiącu użytkownik korzysta ze strony). Prawdopodobnie po przepisaniu do nowej technologii przez najbliższe 8-10 lat będzie utrzymywana w technologii z której skorzystam.

Widzę pewne plusy w pisaniu w Blazorze (przede wszystkich wszystko w c#), ale z drugiej strony nie przekonuje mnie to, że w przypadku np. WASM jest problem z początkowym ładowaniem. Do tego mimo wszystko nie jest to dojrzała technologia. Mam wrażenie, że co roku pojawia się nowy Blazor (pod koniec 2023 pojawił się United), który (zgodnie z nagłówkami blogów) zrewolucjonizuje świat pisania web aplikacji. Pytanie czy za 5 lat Blazor z którego skorzystam już dawno nie będzie już w odstawce. Potencjalnie największy plus MVC jest jego dojrzałość i stabilność. Minus to z pewnością konieczność korzystania z JS.

Waszym zdaniem z jakiej technologii lepiej jest skorzystać? Co w przypadku takiej aplikacji będzie lepsze?

Jeśli mogę Ci doradzić coś ze swojego doświadczenia - przepisywanie dużych aplikacji bardzo rzadko działa. Dużo lepszą metodą jest powolne "sprzątanie" małych kawałków istniejącej aplikacji.

Riddle napisał(a):

Jeśli mogę Ci doradzić coś ze swojego doświadczenia - przepisywanie dużych aplikacji bardzo rzadko działa. Dużo lepszą metodą jest powolne "sprzątanie" małych kawałków istniejącej aplikacji.

Może to źle określiłem, moim celem będzie napisanie tego samego w nowszej technologii

Lampart123123 napisał(a):

Riddle napisał(a):

Jeśli mogę Ci doradzić coś ze swojego doświadczenia - przepisywanie dużych aplikacji bardzo rzadko działa. Dużo lepszą metodą jest powolne "sprzątanie" małych kawałków istniejącej aplikacji.

Może to źle określiłem, moim celem będzie napisanie tego samego w nowszej technologii

Może ja też się źle określiłem - napisanie tego samego w nowszej technologii, prawie nigdy się nie udaje. To co się udaje, to po prostu zmienianie całej aplikacji kawałek po kawałku, update'y użycia kodu, aktualizacja zależności, etc.

Nie wiem co ludzie widzą w Blazorze. Każdy kto bierze pod uwagę Blazora używa tego samego argumentu - znam C#, a Blazor to C#... Problem polega na tym, że i tak, w którymś momencie będzie potrzebne @inject IJSRuntime JsRuntime, bo czegoś nie będzie się dało zrobić "w C#".

Ja też dawno temu przeleciałem prawie wszystkie frameworki, aby wybrać ten jedyny i padło na Angulara. To samo robiłem jak musiałem napisać mobilkę. Też jestem csharpowy, a mimo to Xamarin/MAUI do mnie nie przemówiło i wybrałem Fluttera.

Jeśli czas ciebie nie goni to zwyczajnie spróbuj czegoś JS'owego. Ja wybrałem Angulara, ponieważ składnia tego frameworka jest dla bardziej czytelna względem Vue lub React. Nawet Visual Studio ma dedykowany, gotowy szablon projektu pod Angulara, Vue i Reacta.

AdamWox napisał(a):

Nie wiem co ludzie widzą w Blazorze. Każdy kto bierze pod uwagę Blazora używa tego samego argumentu - znam C#, a Blazor to C#... Problem polega na tym, że i tak, w którymś momencie będzie potrzebne @inject IJSRuntime JsRuntime, bo czegoś nie będzie się dało zrobić "w C#".

Ja też dawno temu przeleciałem prawie wszystkie frameworki, aby wybrać ten jedyny i padło na Angulara. To samo robiłem jak musiałem napisać mobilkę. Też jestem csharpowy, a mimo to Xamarin/MAUI do mnie nie przemówiło i wybrałem Fluttera.

Jeśli czas ciebie nie goni to zwyczajnie spróbuj czegoś JS'owego. Ja wybrałem Angulara, ponieważ składnia tego frameworka jest dla bardziej czytelna względem Vue lub React. Nawet Visual Studio ma dedykowany, gotowy szablon projektu pod Angulara, Vue i Reacta.

Muszę przyznać, że napisanie dwóch osobnych aplikacji tzn. angulara + .net web api, byłoby bardzo ciekawym wyzwaniem, ale uważam że jednak zbyt dużym jak na pracę inżynierską i moje możliwości czasowe. Dlatego też rozważam .NET CORE MVC + Razor

Chcesz zrealizować dwa nie do końca idące w parze cele.

• napisać pracę inżynierską
• usprawnić istniejącą apkę długofalowo

Problem w tym, że w pisaniu pracy inżynierskiej jesteś zależny od promotora, który ci będzie marudził i próbował wpłynąć na ciebie, a w przepisywaniu istniejącej apki jesteś zależny od użytkowników, którzy też mają swoje wymagania i też będą próbowali na ciebie wpłynąć.

No i to wyzwanie technologiczne (pamiętaj, że apka to też dopracowane przez lata szczegóły, które nawet nie były planowane, jak np. niewielkie tweaki w interfejsie czy naprawienie bugów - robiąc od nowa, od początku będziesz musiał to robić. Fajnie o tym pisze Joel Spolsky https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ Artykuł sprzed ponad 20 lat, ale dalej aktualny).

Czyli moim zdaniem sam sobie stawiasz kłody pod nogi i podbijasz trudność, dorzucasz niepotrzebne ryzyko próbując zarówno przetestować sobie nową technologię, napisać pracę inżynierską jak i zrobić coś, co będzie używane przez kolejne 8 lat. Co może pójść nie tak?

A jakby oddzielić te sprawy?

• pod pracę inżynierską zrobić prototyp aplikacji (to bardziej realistyczny cel), ale stawiając sobie konkretne cele badawcze, czego chcesz się dowiedzieć w ten sposób. Przetestować również różne technologie i podejścia.
• następnie (po napisaniu pracy) wyciągając wnioski z prototypu dopiero przerabiać istniejącą apkę albo rozwijać prototyp w tym kierunku, żeby mógł on kiedyś zastąpić istniejącą aplikację (chociaż jak coś działa i ludzie z tego korzystają, to raczej trzeba będzie to stopniowo robić, a nie że jednego dnia ktoś się loguje i już jest inna aplikacja).