somekind napisał(a):
Przypominam, że teza główna brzmi, że backendowiec musi znać frontend, żeby zrobić dobry backend. Ja cały czas trzymam się tego tematu. I cały czas się z tym fundamentalnie nie zgadzam, bo to jest bzdura.
OK, moja hipoteza - Dobrze jest gdy backendowiec, projektując API swojego systemu, które ma wspierać frontend (w szczególności OPA) miał doświadczenie w dowolnej technologii forntendowej, oraz tym co i jak ten frontend ma robić żeby zaprojektować API lepiej dopasowane do potrzeb interface'u użytkownika.
Oczywiście, trzeba wiedzieć gdzie i po co jest używany nasz kawałek systemu. Tylko zupełnie nie wiem, jaki ma z tym związek znajomość technologii frontendowych.
Jeżeli istotną częścią tego systemu jest frontend, to moim zdaniem jest to przydatne.
Jeśli w banku mam napisać moduł, który ma cyklicznie codziennie o 8 rano pobierać kursy walut z NBP i wrzucić do jakiejś kafki czy service busa event z tymi danymi, aby można było prawidłowo obliczyć opłaty za przelewy zagraniczne, to muszę znać angulara, czy react wystarczy?
Nie jest to działka związana z frontendem. Tylko nie wszystkie systemy to systemy bankowe rozbuchane do iluś tam mikroserwisów.
To nie jest kwestia abstrakcji i słówek tylko meritum dyskusji. Rozmawiamy o frontendzie i backendzie, nie backendzie i backendzie.
OK, tylko to ty zepchnąłeś dyskusję na ten tor...
No właśnie, kiedyś nie było iluś narzędzi - o tym piszę od początku. Teraz jest więcej narzędzi, więcej technologii, i zamiast nauczyć się bazy, języka backendowego i frontendowego trzeba nauczyć się kilkunastu technologii backendu i okolic.
Ale te narzędzia ułatwiają, a nie utrudniają development. Zresztą kiedyś nie było wcale nacisku na UX, aplikację w webowym UI "projektował" programista, który później rzeźbił to wszystko w jakimś JSP, PHP, czy innym potworze, albo wyklikiwał w Delphi. Efekt był taki, że np. aplikacje desktopowe wyglądały tak:
Nie przeczę, że teraz łatwiej jest tworzyć złożone systemy, tylko te systemy wciąż tworzone są przez wielu ludzi, tylko ich rozkład wiedzy się zmienia na bardziej wyspecjalizowany. I to jest naturalny proces zachodzący w każdej branży.
Ja się z tym zgadzam, sam pisałem, że granicą skomplikowania systemu jest ludzie pojmowanie co i jak on ma zrobić. Dzięki modularyzacji można to pchnąć dalej, bo można ogarnąć zależności na różnych poziomach przedsiębiorstwa, rozwiązania, systemu i w każdym z tych ujęć dojść do granicy WTF. Tylko nadal, to jedynie ułamek produkcji oprogramowania a spora jego część to proste aplikacje gdzie zysk ze specjalizacji zniknie ze względu na to, że wszyscy obszarowi eksperci będą przez pół roku ze sobą rozmawiać jak to wszystko spiąć, a przyjdzie ogarnięty full stack i zrobi całość w 2 tygodnie, bo zwyczajnie dostał wymagania i zrobi jak mu wygodnie, w czym mu wygodnie. Albo w opisanym przez ciebie systemie bankowym trzeba zrobić stronkę do ustawiania jakichś tam parametrów, cyk i jest zrobiona, zamiast czekać aż zarząd banku zdecyduje się rozszerzyć budżet projektu, żeby było za co chociaż podyskutować. Czyli, używając analogii - czasami potrzebujesz specjalisty od stacji pomp, a czasami wystarczy złota rączka, żeby wymienić uszczelkę w kranie.
- screenshot-20211015192634.png (307 KB) - ściągnięć: 6
