Czym zajmuje się backend Dev?

Ad1. Raczej konsolówki to nie... Chyba, że ma to być jakieś wewnętrzne narzędzie do "czegoś".

Ad2. To zależy od projektu. Można też np. robić API komunikujące się z urządzeniem i przesyłające dane do bazy.

Ad3. Nie koniecznie. Jeśli nie ogarniasz frontu to nie ma takiej potrzeby. Znam backendowców nie potrafiących dosłownie nic z frontu poza wstawieniem tabeli w HTML i mają się dobrze.

Java91 napisał(a):

Pytanie1: czy w pracy tworzy się w ogóle aplikacje konsolowe czy one służą głównie nauce programowania?

Dziwne pytanie. Czym jest "aplikacja konsolowa" i czemu zasługuje na odpowiednią kategorię? (tzn. faktycznie jest taka kategoria programów, ale dziwi mnie porównanie)

Jeśli aplikacja konsolowa to taka, która pisze tekst na standardowe wyjście (np. konsolę) i przyjmuje input ze standardowego wejścia (np. klawiatury), to idąc tym nazewnictwem można by powiedzieć na backendzie zwykle tworzy się aplikacje portowe :D ponieważ taka aplikacja zwykle komunikuje się ze światem i wewnętrznymi usługami po odpowiednich portach https://en.wikipedia.org/wiki/Port_(computer_networking) nawiązując i akceptując różne połączenia sieciowe.

Czyli ogarnij trochę networking, bo to się przyda, żeby zrozumieć, jak działają takie aplikacje.

@LukeJL: ok, chodziło mi o programy konsolowe Odpowiesz również na pyt2 i 3? Z góry dzięki

w jednej firmie jak w ogólnie webowej apce mieliśmy batch joby to wystawialiśmy je jako konsolówki odpalane przez harmonogram zadań w windowsie

Java91 napisał(a):

Pytanie1: czy w pracy tworzy się w ogóle aplikacje konsolowe czy one służą głównie nauce programowania?

Oczywiście ze się używa, praktycznie każde narzędzie z którym się pracuje ma interfejs konsolowy. Może nie działają one tak jak w szkole, typu "Podaj liczbę:", ale argumenty uruchomieniowe, opcje, statusty błędów, i wyjście standardowe wyjscie error, i stanard input jak najbardziej. Sam napisałem dziesiątki takich narzędzi do pracy. To najprostszy interfejs jaki możesz zaprojektować dla narzędzia, potem najpewniej będzie okienkowy, potem api, potem webowe, tak strzelam.

Pytanie2: czy to prawda, że najczęściej klepie się backend pod frontowe aplikacje? Jeżeli tak, to czy zwykle rola backendowca sprowadza się do stworzenia API z określonymi endpointami, zabezpiecza aplikacje i ogólnie robi z góry ustaloną logikę do webserwisu z której korzysta front?

Określenia "backend i frontent" z definicji odnoszą się do aplikacji webowych "web application back-end" oraz "web application front-end". Dodatowko, z takiego interfejsu serverowego mogą korzystać też aplikacje mobilne, tak naprawdę technologia klienta nie ma znaczenia.

Niestety 90% pracy na rynku programistycznym teraz, to są aplikacje webowe właśnie, z czego większość to crudy, więc zawód "backendowca" został sprowadzony własnie "tego co robi endpointy".

Pytanie3. Jezeli np. do portfolio się robi (przykład) projekt typu mini serwis społecznościowy czy np. internetowy komunikator online to poza backendem suma sumarum powinno się do portfolio również stworzyć frontend co sprowadza się również do tego, że trzeba ogarnąć HTML CSS JS chociażby na poziomie podstawowym?

Nie koniecznie. W mojej opinii do portofilio nadaje się cokolwiek, co wymaga jakiejś umiejętności do zrobienia, a nie faktyczny końcowy stan jakiegoś projektu. Jeśli ktoś zrobił tylko warstwę persystencji, i nic innego; ale w taki sposób, że zasługuje to na szacunek, to jaknajbardziej się nadaje do portfolio.

Jak tak naprawdę wygląda praca programisty backendu?

Nie tak jak prawdziwe programowanie, to na pewno.

Sporo pracy zostało sprowadzone do prostego algorytmu:

• wbij na SU o 9:00, powiedz który endpoint robisz
• dodaj endpointy, który nic nie robi tylko robi jednego calla do service'u, który nie robi nic oprócz jednego call'a do repozytorium, które nic nie robi, tylko kilka fetchy z bazy - nazwij to "onion architecture" (mimo że z architekturą nie miało to za wiele wspólnego)
• miej ochotę napisać testy, ale nie napisz ich
• odpal linter, popraw wszystko co sonar karze poprawić, bo on wie lepiej niż programista
• dodaj dokumentację w stylu GET /users - get all users.
• zrób commita który zawiera zero informacji oprócz ticketu w jirze, np FR-123 Added endpoint
• zrób PR'a, poczekaj aż koledzy na "review" znajdą wszystkie literówki, dostań approve'a, zmerguj.
• poczekaj aż QA strzeli z postmana w endpoint jeden raz i mu się nie wywali - dostałeś zielone światło na proda
• módl się żeby się nic nie wyywaliło na produkcji
• na każdym retro płacz jak bardzo dużo macie techdebt, ale nic z tym nie rób.

to tak w skrócie.

1. Niemal zawsze służą nauce programowania. Czasem jakiś tool bashowy lub wewnątrz firmowy tool jest w konsoli.
2. Jak logika apliakcji jest prosta to rzeczywiście praca polega na tym, żeby dodać endpoint i serwis i 'done'. Często trzeba jednak wykminić, o co właściwie chodzi w taksu. Jak ma się to do obecnego stanu kodu, czy da się to w ogóle zrobić lub w jakim stopniu. Czasem trzeba przeprowadzić analizę jak zmodyfikować funkcjonalność i trzeba sprawdzić co może ewentulanie wybuchnąć, a po zaimplementowaniu trzeba się modlić, żeby coś jednak nie wybuchło - często coś o czym nie mieliśmy pojęcia. Są też zadania z analizą i poprawą performance'u.

Fajnie gdyby to tak wyglądało, że analityk / architekt wszystko ogarnęli, a code monkey ma tylko zaimplementować. Rzadko kiedy analityk będzie na tyle ogarnięty, żeby to tak działało. Najczęściej to co może zrobić, to forward maila od klienta.

1. Zastanawiam się czy ktokolwiek patrzy w portfolio backendowca. Ale fajnie jak już zrobiłeś backend, żeby frontend nie wyglądał jak totalna kupa. Alternatywnie interaktynwy swagger do puszczania request'ów.