Jak robicie apki w 2024

Pamiętam wątki w których ludzie pytali o to jakiego języka użyć żeby stworzyć aplikację A i zawsze dostawali odpowiedzi że użyj tego co znasz najlepiej.

Załóżmy że chcemy stworzyć aplikację (webową) która pozwala ludziom oceniać jedzenie w różnych restauracjach. Czyli np. mamy encję "posiłek" i rekord "carbonara", "pizza 4 sery". Te posiłki mają relacje z restauracjami - carbonara może być dostępna w różnych restauracjach. User musi mieć możliwość rejestracji/logowania przez FB, lub email/hasło.

Jak byście to Wy zrobili? Możecie to oprzeć o pierwszy akapit, czyli użyć znajomych technologii, a może byście nauczyli się czegoś nowego (załóżmy że macie na zrobienie apki 3, może 6 miesięcy, ale wydaje mi się że w 2024 roku takie coś powinno zająć 1 dzień), może to być gotowe oprogramowanie (jakie?) z modyfikacjami, lub bez, albo no-code/low-code.

Sam znam .NET i React, tylko ostatnio robiłem co innego i trochę mi się odechciewa jak sobie myślę o łączeniu tego od zera z Entity Frameworkiem, podłączaniem Auth0, stawianiem infrastruktury.

Użyj tego co znasz najlepiej.

A tak serio to nie bój się korzystać z pomocy, gotowych template'ów itp. Rób wszystko w standardowy i najprostszy sposób to będziesz mógł skorzystać z popularnych narzędzi. Możesz zacząć od szkieletu projektu w .NET z podpiętym Auth, dorobienie dwóch "encji" w entity frameworku nie brzmi strasznie. O jakiej infrastrukturze mowa pod taki projekt? Brzmi jakby nie miało to zająć więcej niż kilka godzin, najwięcej zejdzie na UI

Tak na prawdę wytwarzanie aplikacji nie zmieniło się specjalnie od chyba 1980. Takie super pomysły które były to chyba polimorfizm, FP, OO i to by chyba było na tyle.

Oczywiście że powstają nowe języki, nowe biblioteki, nowe toole, etc., ale w dużej mierze one się nie różnią koncepcyjnie jakoś specjalnie od swoich poprzedników. Zawierają w sumie te same pomysły i sposoby co poprzednie języki.

Jest bardzo duży wzrost możliwości hardware'u, ale software mniej więcej zostaje taki sam.

Ja zaczynam od wygenerowania bazy przez Ai a potem dopisuję reszte.

Riddle napisał(a):

Tak na prawdę wytwarzanie aplikacji nie zmieniło się specjalnie od chyba 1980. Takie super pomysły które były to chyba polimorfizm, FP, OO i to by chyba było na tyle.

Oczywiście że powstają nowe języki, nowe biblioteki, nowe toole, etc., ale w dużej mierze one się nie różnią koncepcyjnie jakoś specjalnie od swoich poprzedników.

Pominąłeś komponenty, te rozkwitnęły w latach 90 - ActiveX, COM, Delphi itp. A i teraz myślenie komponentowe jest bardzo silne np. w React, Vue, Angular itp.,

Z drugiej strony jak się tak zastanowić, to i wcześniej był Smalltalk, więc już wcześniej ktoś wpadł na to, żeby pisać GUI bardziej obiektowo. Czyli może jednak idea komponentów GUI już wtedy się narodziła.

debugariusz napisał(a):

Załóżmy że chcemy stworzyć aplikację (webową) która pozwala ludziom oceniać jedzenie w różnych restauracjach. Czyli np. mamy encję "posiłek" i rekord "carbonara", "pizza 4 sery". Te posiłki mają relacje z restauracjami - carbonara może być dostępna w różnych restauracjach. User musi mieć możliwość rejestracji/logowania przez FB, lub email/hasło.

Należy zacząć od najprostszego feature'a który ta aplikacja miałaby robić, czyli dodanie oceny do posiłku. Dobrze byłoby to zrobić najprościej i najszybciej jak się da (czyli np zacząć od prostej mapy "nazwa => ocena"), jednocześnie zachowując jakość (czyli np. pisząc testy), i pokazać osobie zlecającej żeby oceniła czy o to chodzi. Zebrać feedback, i zrobić kolejny najprostszy feature (np grupowanie po restauracjach).

Należy zaprogramować najprostszy feature, ale w taki sposób żeby nie zamykać się na przyszły rozwój.

Wymyślanie tego jakie encje mają być w aplikacji to jest na późniejszy etap.

debugariusz napisał(a):

Jak byście to Wy zrobili? Możecie to oprzeć o pierwszy akapit, czyli użyć znajomych technologii, a może byście nauczyli się czegoś nowego (załóżmy że macie na zrobienie apki 3, może 6 miesięcy, ale wydaje mi się że w 2024 roku takie coś powinno zająć 1 dzień), może to być gotowe oprogramowanie (jakie?) z modyfikacjami, lub bez, albo no-code/low-code.

Zły pomysł - nie zaczyna się od wyboru technologii. Najlepiej zacząć w samym języku programowania i bibliotece do testów, po to żeby zostawić sobie otwarte drzwi na wybór technologii w późniejszym etapie projektu - kiedy będziemy o nim wiedzieć więcej.

LukeJL napisał(a):

Pominąłeś komponenty, te rozkwitnęły w latach 90 - ActiveX, COM, Delphi itp. A i teraz myślenie komponentowe jest bardzo silne np. w React, Vue, Angular itp.,

Nie pominąłem, specjalnie ich nie wymieniłem, bo nie sądzę że one dodają cokolwiek. To po prostu sposób dzielenia kodu na kawałki, a to że nazwiesz sobie to "komponent" to jakby nic nie zmienia.