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.