Czy to jest wspólne rozdzielanie zaplecza i interfejsu użytkownika na dwie pozycje w projektach internetowych?

Czy przy uruchamianiu przez Internet częściej jest, gdy inżynier pracuje nad interfejsem i zapleczem funkcji (w zasadzie za całą funkcję)? A może inżynierowie oddzielili zaplecze od interfejsu?

Które są bardziej korzystne i w jakich sytuacjach?

Zauważyłem, że wadą związaną z posiadaniem jednego inżyniera odpowiedzialnego za całą tę funkcję jest to, że osoba ta może być szczególnie silna w rozwoju frontendów lub backendów, ale nie w obu przypadkach, co czasami powoduje spadek prędkości i jakości.

Posiadanie frontendów i programistów backendów w jednej funkcji zwiększa szybkość funkcji i jakość ORAZ zachęca do współpracy. Obawiam się jednak, że 2 inżynierów pracuje nad jedną funkcją, co może być słabym wykorzystaniem zasobów, ponieważ 1 inżyniera można ustawić na inną funkcję, nad którą będzie pracować.

Jaka jest powszechna / najlepsza praktyka dotycząca alokacji zasobów zaplecza / inżynierii frontendu w małym początkowym etapie uruchamiania? A jak to się zmieni w miarę wzrostu?

Oto moja mądrość z 14-letniego doświadczenia:

• jeśli masz startup, nie przypisuj ról. Lepiej mieć nadzieję, że zgromadziłeś dobry zespół samoorganizujący się. Jeśli wszyscy się znają, wszyscy wiedzą, kto robi to, co najlepsze. Kierownik projektu będzie przeszkadzał.
• później rozróżnienie między front-endem a back-endem ma sens. W backendie jakość jest na pierwszym miejscu. Kod musi być wydajny, bezpieczny i bezpieczny dla transakcji. W interfejsie czas wdrożenia ma znaczenie. Musisz być w stanie polegać na dobrym zapleczu. Różne cele interfejsu i zaplecza nie działają dobrze razem.
• zaplecze powinno już istnieć, zanim koder frontonu zacznie działać. W przeciwnym razie koder frontonu zostanie zbyt spowolniony.
• backend musi być w stanie szybko reagować na wymagania frontonu, aby ich nie spowalniać

Najlepsza odpowiedź pochodzi z @Shark, ale tylko ostatnia część „To zależy”. Z mojego doświadczenia wynika, że ​​około 16 lat widziałem obie opcje próbowane w różnych konfiguracjach. Będąc programistą z pełnym stosem, oto, czego się dowiedziałem:

* (BE = zaplecze, FE = przód)

Ogólne zastrzeżenia dotyczące rozwoju podziału stosu:

1. Zwinne praktyki programistyczne (obecnie popularna strategia) zalecają opracowywanie funkcji, w których cecha ta stanowi jeden cenny element funkcjonalności z punktu widzenia klienta. Z tego punktu widzenia programista powinien wdrożyć oba.

2. Rozdzielenie stosu wzdłuż granicy serwera tworzy punkt integracji między dwoma programistami. Jeśli nie będą się skutecznie komunikować i nie będą dobrze ze sobą współpracować, spowoduje to sporo błędów, gdy obie funkcje się połączą.

3. Zastosuj zasadę komunikacji n (n-1) / 2 z Mitycznego Miesiąca Człowieka, a zobaczysz, że podział funkcji na dwie części między dwie osoby zwiększy twoje ogólne obciążenie pracą. To prawda, że ​​ta reguła dotyczy również funkcji, ale podział stosu podwaja ilość komunikacji.

4. Projektant rozwiąże problemy deweloperów BE, którzy nie są w stanie stworzyć atrakcyjnych interfejsów od zera. Zakłada się, że przynajmniej znają HTML i CSS i mogą stworzyć interfejs, który pasuje do zrzutów ekranu stworzonych przez projektanta.

5. Funkcje są zwykle izolowanymi komponentami, które bardzo mało współdziałają z innymi funkcjami. Nie zawsze tak jest, ale zazwyczaj punkt interakcji jest na niskim poziomie, jak baza danych lub system plików. Tak więc niewiele jest przeszkód, aby programista z pełnym stosem wdrożył ich funkcję. Ale jeśli programista FE musi poczekać na programistę BE, aby ukończył zadanie, spowoduje to jeszcze większe opóźnienie oprócz straty produktywności w punkcie 3.

6. Web2.0 jeszcze bardziej zaciera rozróżnienie między FE a BE. Ponieważ frameworki MVC i całe aplikacje są budowane po stronie klienta, do implementacji bezpiecznych i wydajnych aplikacji FE wymagana jest duża wiedza BE.

7. Moją największą wadą tej praktyki jest to, że ogranicza ona możliwości wszystkich osób zaangażowanych w projekt. Chociaż była to powszechna praktyka na początku 2000 roku, zrobiono to z konieczności, ponieważ znalezienie programistów, którzy mogliby zrobić jedno i drugie, było dość trudne (wyłącznie z powodu nowości, a nie z powodu pewnych wewnętrznych trudności w nauce obu.) Pozostała część praktyki dekadę później nadal mamy „programistów”, którzy nie znają CSS.

8. Moim drugim największym problemem jest to, że może łatwo segmentować zespół programistów. Deweloper FE tworzy błąd po zmodyfikowaniu kodu BE, a zespół głosuje za hurtowym ograniczeniem rozwoju wielu stosów. Podczas gdy przeglądy kodu i edukacja mogą rozwiązać problem, ludzie stają się terytorialni.

Korzyści / przypadki użycia podziału stosu:

1. Interfejsy API RESTful są idealne do tego wyznaczenia, ponieważ nie ma FE. Często firma najpierw będzie pracować nad RESTful API, a następnie opracuje swoje aplikacje internetowe. W tym przypadku istnieją mocne argumenty za utrzymaniem zespołu BE skoncentrowanego na następnej głównej wersji, gdy FE kończy aplikację. Ale nadal istnieje niebezpieczeństwo odejścia - zwłaszcza jeśli nowe informacje odkryte w fazie projektowania FE wymagają nietrywialnych modyfikacji interfejsu API BE.

2. Niezrównoważone obciążenia między FE i BE są również dobrym powodem do stworzenia zespołu tylko FE. Ponownie jest to bardzo sytuacyjna sytuacja, w której być może główny rozwój odbywa się za pomocą aplikacji komputerowej, a firma próbuje opracować „lite” interfejs sieciowy.

3. Szkolenie nowych / młodszych programistów. Jeśli zatrudniasz stażystę lub młodszego programistę i obawiasz się wyrzucenia ich na osobę zależną, dobrym rozwiązaniem jest zainwestowanie części tych kosztów komunikacji / integracji w system rozwoju rówieśników.

Obawy dotyczące zaakceptowanej odpowiedzi @ Ralfa na tej stronie:

1. Pierwszy punkt jest dość odważny - i szybko się nie powiedzie, jeśli nie będziesz miał jednego z tych „dobrych, samoorganizujących się zespołów”. Nawet jeśli masz ten zespół, w jego i ich interesie jest przekraczanie granic. A dobre zespoły samoorganizujące się nie zawsze mają do tego motywację.

2. Twój drugi punkt jest po prostu zły. Nowoczesne tworzenie stron internetowych wymaga wydajnego, bezpiecznego, asynchronicznego, bezpiecznego kodu, odpornego na XSS, działającego w różnych przeglądarkach i rozwijanego szybko. Cele po prostu nie konkurują z BE, są w rzeczywistości równe.

3. Trzeci punkt jest również złym założeniem - rozwój FE można rozpocząć od czystego html / css / js bez żadnych prac fundamentowych BE. Stamtąd tylko trywialny wysiłek dzieli go na szablony do renderowania BE. Często najlepiej jest zacząć od pracy z FE, ponieważ zapewni interesariuszom ciepłe i rozmyte wrażenie, widząc postępy wizualne z góry.

Wniosek:

Jeśli jesteś startupem i nie masz dużo czasu ani pieniędzy na spalenie, nie zatrudniaj programistów FE ani BE. Zatrudnij programistów internetowych na wysokim poziomie i dobrego ux / projektanta, a oni jak najszybciej rozpoczną twoją aplikację. Kosztują więcej, ale są znacznie bardziej wydajne i będziesz potrzebować ich mniej.

Myślę, że pytanie jest złe.

Wszystkie startupy, w których brałem udział, nie miały architektury FE-BE.

Większość startupów, które znam, ma:

• Rdzeń - rzeczywisty produkt, który udostępnia interfejs
• UI - BE i FE. BE używa interfejsu API rdzenia.

Interfejsy API są bezpaństwowe i łatwo się z nich kpić - nawet bez potrzeby głównego programisty. Do diabła, gdybym musiał rozpocząć projekt od zera, mógłbym zacząć od pełnego interfejsu użytkownika, który działa wyłącznie na próbach - co będzie świetne do prezentacji. Większość opinii pochodzi z interfejsu użytkownika. Klienci zauważają, że więcej - (zależy od grupy docelowej).

Na przykład - wyszukiwarka Google ma podstawowy komponent, który indeksuje sieć, indeksuje ją itp., A interfejs użytkownika Google to zupełnie inny świat. Ten rdzeń może z łatwością obsługiwać wyszukiwania inne niż WWW, podczas gdy interfejs użytkownika nie.

W ten sposób twój interfejs użytkownika jest „wtykany” i masz oddzielne obawy.

Odwołałeś się do wiedzy programistycznej, ale przeoczysz aspekty zarządzania projektami. Podczas gdy zespół podstawowy może potrzebować 2 tygodniowego sprintu, zespół interfejsu użytkownika użyje CI - wszystko jest przesyłane przez cały czas. Zespół podstawowy będzie potrzebował kompatybilności wstecznej, podczas gdy interfejs użytkownika nie.

Język się różni. Prawdopodobnie będziesz chciał deweloperów C dla komponentu Core - i wszystko będzie dobrze, jeśli działa na jednym systemie operacyjnym, gdzie interfejs użytkownika będzie napisany w języku wielu systemów operacyjnych.

Testy się różnią. Świat testowy interfejsu użytkownika jest jednym z najbardziej złożonych, jakie znam w tworzeniu oprogramowania. Większość startupów lekceważy to i później żałuje tej decyzji. Podczas testowania nie można oddzielić BE i FE. Musi to być pojedyncza jednostka, która sobie z tym poradzi.

Interfejs użytkownika typu open source - jedną z największych korzyści z rozdzielenia tych dwóch elementów jest to, że można otworzyć interfejs użytkownika typu open source. Projekt interfejsu użytkownika wymaga wsparcia typu open source.

Nie wyobrażam sobie programisty interfejsu użytkownika, który nie rozumie całej session funkcji. Wiesz - gdzie się logujesz i pozostajesz zalogowany między różnymi żądaniami. To prawda, że ​​mogą znać PHP, a nie Javę, ale koncepcja BE powinna być jasna (np. Użyć zaszyfrowanego pliku cookie). Określona bariera językowa jest błędna - każdy programista powinien być gotowy do pracy w dowolnym języku. Kto by pomyślał, że kilka lat temu napisze BE w JavaScript?

Jeśli nadal będziesz mieć 3 zespoły: Core, BE i FE, to marnowanie zasobów, imho. Co z DB? powinieneś mieć DBA? Dlaczego programista BE powinien znać DB, a deweloper FE nie znać BE i DB? Nie ma limitu.

Jeśli potrzebujesz ekspertów, a będzie to konieczne, outsourcing ich działa całkiem dobrze. Zazwyczaj dostarczają kod jakości i robią to dość szybko. Niekoniecznie chcesz ich w domu, ponieważ zgubisz się, jeśli odejdą. Poza tym dzisiaj możesz uzyskać świetne porady online. Najnowocześniejsze rzeczy mogą wymagać innego podejścia.

Rezultatem jest więc bardzo cienki BE w interfejsie użytkownika, który każdy programista FE może opracować. Jeśli masz gruby BE w interfejsie użytkownika, najprawdopodobniej masz pewne funkcje API wymagane w Core.

Zawsze jest co najmniej jeden programista, który wyróżnia się spośród pozostałych. Biorąc pod uwagę tak cienki FE, może on / ona udzielać wsparcia (nie rozwijać) innym programistom w kodzie BE. Moim zdaniem ten programista jest na bardzo dobrej pozycji i powinien być odpowiednio nagradzany (choć nie w wynagrodzeniu, coś innego). Ufam również, że będą w stanie obsłużyć proces kompilacji i poprawnie budować.

Ten model zapewnia dużą elastyczność w zakresie rozwoju BE. Świat BE doświadczył kilku zmian w ciągu ostatnich kilku lat, więc i tak nie zalecam zbytniego polegania na stabilności BE. Rdzeń to inna historia.

Pozostaje pytanie - czy FE i BE powinny być tym samym projektem ? Należy zwrócić uwagę na następujące kwestie

• Zasoby statyczne najlepiej podawać z serwera frontowego. Ponieważ serwery Front-End (np. Nginx) są bardzo wydajne i ponieważ można używać pamięci podręcznej dla zasobów statycznych, można zarządzać za pomocą pojedynczego wdrożenia zasobów statycznych (powinna to być cała zawartość HTML, JS, CSS, obrazy).
• Kod zaplecza nie ma takich samych luksusów, więc musisz mieć system rozproszony - który jest również zarządzany przez serwer frontowy.
• Kod FE powinien zostać ponownie wykorzystany we wszystkich nowych technologiach obsługujących JavaScript. Możesz teraz pisać aplikacje komputerowe i mobilne z JavaScript.
• Proces kompilacji jest zupełnie inny - i może obejmować nawet dostarczanie łat, aktualizację, instalację itp.

Mogę kontynuować, ale mam nadzieję, że jest jasne, że uważam, że BE i FE powinny być tym samym zespołem, ale może różnymi projektami.

Myślę, że pomyślne wdrożenie może obejmować kilka rzeczy. Jeśli istnieje jedyny programista, który ma silne zaplecze, ale także ma przyzwoitą znajomość interfejsu użytkownika i wszystkich elementów „front-end”, prawdopodobnie może się to udać. Jednak zazwyczaj tak nie jest (z mojego osobistego doświadczenia). Na przykład uważam się za programistę zaplecza. Ale pracuję sam nad wieloma projektami. Czy pracuję nad prezentacją i elementami po stronie klienta? Pewnie. Czy wyglądają tak dobrze, jak by to zrobił prawdziwy utalentowany projektant i programista po stronie klienta? Absolutnie nie.

Wszystko daje i bierze. Ale nie pozwól, aby współpraca dwóch programistów cię zawahała. Istnieją wypróbowane i prawdziwe sposoby na maksymalizację produkcji między deweloperem a projektantem.

Innymi słowy ... to zależy