Ostatnio coraz częściej używa się terminu full-stack developer. Szczególnie w dyskusjach na temat struktury zespołu, wymagań dotyczących rekrutacji lub wnioskowania o czystej wspaniałości jednostki.

Kiedy widzę tego rodzaju stwierdzenie w CV lub słyszę, jak ktoś określa się jako full-stack, przychodzi mi do głowy kilka pytań:

• Co rozumiesz przez pełny rozwój?
• Nad jakim stosem rościsz sobie prawo do mistrzostwa?
• Jak obszerna jest Twoja wiedza na temat każdego z elementów? Jak bardzo musi być pełny?

• Czy programista full-stack istnieje naprawdę? Czy one naprawdę istnieją?
• Jeśli istnieją, dlaczego są przydatne?
• Czy full stack to inny sposób na powiedzenie, że jest waletem wszystkich zawodów, mistrzem niczego?

Tło

Zanim przejdziemy do szczegółów, warto określić, co chcemy rozwijać i dostarczać.

Twierdzenie, że jesteś programistą full-stack dla PoC działającego na twoim laptopie, jest prawdopodobnie uczciwym opisem, ponieważ jesteś jedyną osobą opracowującą każdą część tego rozwiązania. Skala jest bardzo mała, a wpływ złego projektu lub rozwoju jest bardzo ograniczony. Zasadniczo udowadniasz, że koncepcja nie dostarcza usługi, o ile może działać przez godzinną demonstrację dla CIO, jest w porządku.

Jeśli zdefiniujemy rozwiązanie jako system produkcyjny obsługujący dane klientów na żywo i generujący spostrzeżenia/dane napędzające generowanie wartości biznesowej, sytuacja jest inna, a wpływ błędów kodowania lub złych praktyk jest znacznie większy.

Na potrzeby tego wpisu rozważymy system przetwarzający duże ilości (10 GB dziennie) rzeczywistych danych klientów (w tym PII) i zapewniający kluczowe usługi biznesowe z dostępnością co najmniej 2 9 sekund.

Dlaczego programiści full-stack są cenni?

Odkładając na bok istnienie takich osób, korzyści, jakie zapewniają, są oczywiste. Potrafią zaprojektować, zbudować i uruchomić rozwiązanie bez wsparcia z zewnątrz; oznacza to, że wszystkie te czasochłonne i podatne na błędy warsztaty projektowe, integracje komponentów, cykle testowe i przekazywanie operacji są w dużej mierze wyeliminowane. Nie ma potrzeby umawiania spotkania lub, co gorsza, serii spotkań między działem bezpieczeństwa, platformą, bazą danych, operatorami,… MŚP, ponieważ jesteś w stanie zaprojektować, zbudować i uruchomić rozwiązanie. Niewielka liczba tych boskich (małe g) programistów jest w stanie dostarczyć pracę dużego, wielofunkcyjnego zespołu, a ze względu na wyeliminowanie narzutu związanego z przekazaniem, dostawa jest również znacznie szybsza i mniej podatna na błędy.

Dlaczego więc, biorąc pod uwagę te oczywiste korzyści, we wszystkich organizacjach IT nie ma więcej zespołów składających się z tych osób? Dlaczego firmy nie rekrutują i nie szkolą aktywnie, aby budować te drużyny ninja? Czy to dlatego, że deweloperskie odpowiedniki Batmana czy Tony'ego Starka tak naprawdę nie istnieją?

Aby odpowiedzieć na te pytania, musimy przyjrzeć się, jak wygląda (bardzo) uproszczony stos.

Uproszczony stos

Pozostawiam infrastrukturę platformy w celu uproszczenia.

Patrząc na powyższe elementy, oczywiste jest, że bycie ekspertem w każdej warstwie będzie wyzwaniem. Jednak zakładając, że nie muszę znać WSZYSTKIEGO w każdej warstwie, czy mogę zmniejszyć wymaganą wiedzę i nadal być uważany za pełnego stosu? Biorąc aplikację Front-End jako przykładową domenę, moglibyśmy łatwo usunąć Androida i iOS i skupić się tylko na kanale internetowym, a może jeszcze bardziej udoskonalić i powiedzieć, że ogranicza się do React, jak to pomaga?

W oparciu o nasz ograniczony zakres, co muszę wiedzieć o aplikacjach internetowych React?

Po pierwsze, musisz zrozumieć, jak działają aplikacje jednostronicowe, w szczególności podstawowe zasady wymagane do budowania, debugowania i uruchamiania aplikacji internetowej oraz powiązane narzędzia, takie jak npm, webpack, zarządzanie treścią, narzędzia do reagowania, wytyczne UX,…

Będziesz także musiał bardzo dobrze znać funkcje zapewniane przez strony trzecie, np. Material UI, redux, bootstrap, … oraz rozwiązanie do zarządzania pakietami, takie jak npm (w tym zarządzanie lukami w zabezpieczeniach — zwykle kwestia DevOps, patrz dalsze uwagi).

A co z wydajnością, np. czas do pierwszego malowania treści, czas do interakcji, czas blokowania… Czy powinienem przyjąć progresywną architekturę aplikacji internetowej i/lub pomoc pracowników serwisowych? Będziesz musiał zrozumieć czynniki wydajnościowe i to, w jaki sposób różne podstawowe wzorce mogą pomóc w wykorzystaniu narzędzi wspierających analizę, np. React DevTools lub Lighthouse.

Dostępność jest koniecznością dla wszystkich aplikacji, niezależnie od tego, czy aplikacja jest dostarczana wewnętrznie, czy zewnętrznie. Jak zapewnić zgodność z wytycznymi WCAG?

Podsumowując, tylko w warstwie Front-End trzeba dużo wiedzieć i prawdopodobnie dzięki temu jest lekka. Pozostałe warstwy nie różnią się iw wielu przypadkach wzrasta złożoność. Co gorsza, wzorce i zasady architektoniczne, najlepsze praktyki i ramy NIE NAKŁADAJĄ SIĘ .

Więc zakładając, że udało mi się wcisnąć do głowy wzorce, standardy, najlepsze praktyki i praktyczne umiejętności dla każdej warstwy bez wybuchu, co jeszcze muszę wiedzieć? Czy wymagane są jakieś funkcje pomocnicze?

Możliwości wspierające

Oprócz stosu technologii istnieje szereg funkcji pomocniczych, które są potrzebne do zaprojektowania, zbudowania, dostarczenia i uruchomienia wszystkich komponentów rozwiązania.

Architektura i inżynieria SW

Podstawowy zestaw umiejętności wspierających projektowanie architektoniczne we wszystkich warstwach, tworząc dobrą implementację w dowolnym języku / frameworku

• SOLID (pojedyncza odpowiedzialność, otwarte/zamknięte, podstawienie, segregacja interfejsów, odwrócenie zależności)
• ponowne użycie, łatwość konserwacji, przenośność, rozszerzalność, …
• Skalowanie poziome i pionowe
• Struktura kodowania
• Logowanie
• Recenzje kodu
• …

Każda z warstw i komponentów w każdej warstwie (pomijając Front-End z perspektywy kanału internetowego, ponieważ jest on zaimplementowany przez przeglądarkę lub zazwyczaj poza naszą kontrolą, ponieważ jest po stronie klienta) w powyższym uproszczonym stosie wymaga starannego rozważenia z punktu widzenia bezpieczeństwa np

• API : TLS, DDoS, uwierzytelnianie i autoryzacja, COR, polityka bezpieczeństwa treści, …
• Mikrousługi : TLS (w tym MA), kontrola dostępu, zarządzanie tajemnicą, sprawdzanie poprawności danych wprowadzanych przez użytkownika,…
• Dane : kontrola dostępu, szyfrowanie w stanie spoczynku, zarządzanie kluczami, sieciowe grupy zabezpieczeń i podsieci…
• Platforma (dodatkowa) : bezpieczeństwo sieci, stałe konfiguracje komponentów np. ChefInspec

Wszyscy programiści potrzebują podstawowych umiejętności testowania, nie ma usprawiedliwienia dla braku możliwości przetestowania własnych funkcji. A w środowisku z pełnym stosem oznacza to każdy komponent na powyższym diagramie.

Zrozumienie i umiejętność zastosowania różnych rodzajów i faz testowania (bez oceniania własnej pracy domowej):

• Funkcjonalne i niefunkcjonalne
• Czarna skrzynka kontra biała skrzynka
• Jednostka, integracja, system, akceptacja użytkownika, regresja, dym, …

Opracowywanie i utrzymywanie potoków ciągłej integracji i ciągłego wdrażania

Podstawowe czynniki umożliwiające CICD są często tworzone przez scentralizowany / dedykowany zespół, ale każdy powinien przynajmniej mieć możliwość aktualizacji i utrzymania potoków. (Tak, wiem; jeśli masz zespół DevOps, nie zajmujesz się DevOps, ale robi to wiele organizacji)

Korzystając z narzędzi takich jak:

• Jenkins, TravisCI, Spinnaker
• GitHub, Bitbucket
• Sonarqube
• Zaproxy
• Veracode, Snyk
• Doker, kotwica, port
• …

Jeśli zignorujemy podejście „zbudujesz, uruchomisz”, wymagania stawiane programistom full-stack w zakresie operacji zostaną znacznie uproszczone

Skoncentruj się na budowaniu aplikacji, aby działała. Obejmuje wszystkie wymagane haki diagnostyczne, dzienniki zdarzeń i książkę przebiegu, dzięki czemu zespół prowadzący może segregować i potencjalnie rozwiązywać problemy bez konieczności korzystania z pomocy zespołu programistów

Oczywiście odpowiedzialność za powyższe możliwości będzie prawdopodobnie opierać się na sposobie zarządzania organizacją — być może programowanie dotyczy wyłącznie testów jednostkowych lub wszystkie testy są wykonywane przez zespół scrumowy, z wyjątkiem testów bezpieczeństwa. Ale jeśli jesteś w stanie zająć się tworzeniem API i zarządzaniem potokiem CICD bez potrzeby wsparcia ze strony innych, zaoszczędzisz dużo czasu.

Podobnie jak w przypadku warstw stosu technologii, zakres zdolności pomocniczych wymaganych do uzyskania statusu pełnego stosu jest ogromny.

Wniosek

Wierzę, że prawdziwy programista full-stack jest mitem (w dużej mierze) i był nim od czasu, gdy stos wyszedł poza uruchamianie asemblera na 6502 w latach 80-tych. Nie oszukuj się, myśląc, że uruchomienie front-endu i kilka interfejsów API napisanych w Node działającym na węźle K8 oznacza, że ​​jesteś programistą full-stack.

Osoby te są mityczne nie tylko ze względu na głęboką wiedzę i doświadczenie, które muszą posiadać w różnych dziedzinach technicznych, ale także dlatego, że zakres ten stale się zwiększa — każdego roku następuje ogromny rozwój technologii i wzorców w każdej z domen, nadążając za do tej pory jest bardzo, bardzo trudne.

Ponadto osoby te zazwyczaj proszą o więcej pieniędzy, niż większość organizacji IT może sobie na nie pozwolić, ale jeśli naprawdę mają pełny stos, są tego warte — jak głosi reklama.

Sugeruję, że najlepsze, co możesz osiągnąć, to opanowanie wybranej domeny (konkretnej warstwy z ograniczonym stosem technologii w ramach tej warstwy) oraz, co najwyżej, kompetencje i świadomość braku wiedzy w innych obszarach.

Lepszym sposobem na odniesienie sukcesu przez zespół nie jest próba rekrutowania lub szkolenia full stack developerów, ale zamiast tego tworzenie domen np. front-end, back-end, baza danych itp. stos będzie ograniczony) z nakładającą się/przechodzącą wiedzą do innych domen z bardzo przejrzystymi interfejsami, standardami, najlepszymi praktykami i ramami wspierającymi rozwój wysokiej jakości. Jeśli osoby są w stanie objąć wiele domen na poziomie eksperta, to świetnie, ale z mojego doświadczenia wynika, że ​​jest to naprawdę wyjątek.

Bonusowy komentarz:

Co musisz wiedzieć, aby odnieść „większy” sukces jako programista zajmujący się nauką o danych (zwróć uwagę na użycie słowa programista zamiast terminu naukowiec ds. danych — zakładam, że jesteś już dobrym naukowcem ds. danych? A jeśli nie, to ja nie mogę ci pomóc!). Jeśli zdefiniujemy tego programistę jako kogoś, kto może rozwijać się w każdym z tych obszarów, ale jest ekspertem w części Data Science*, tj. mój ograniczony cel powyżej, uprzemysłowienie szerszego stosu jest czymś, co zrobiłby inżynier uczenia maszynowego… ale ta dyskusja jest na inny czas.

*w naszym uproszczonym stosie możemy powiedzieć, że model idzie w stronę mikroserwisów… trochę