Front end pierwszy lub back end pierwszy. Z tych dwóch, które są dobrą praktyką projektowania systemu?


30

Mam teraz klienta, który wymaga ode mnie opracowania szkolnego systemu rekrutacji. Teraz po raz pierwszy mam tego rodzaju wyzwanie. Większość wcześniejszego oprogramowania, które stworzyłem, nie jest tak skomplikowane.

Wiem, że większość z was stworzyła skomplikowane oprogramowanie, chcę tylko Waszej porady w tej sprawie. Czy powinienem zaprojektować najpierw przód czy tył?

dzięki!

Oto konkluzja artykułu, który jakiś czas temu znalazłem w Internecie. Po prostu chcę się podzielić

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Front-end vs. back-end developers (moja opinia)

Moje osobiste podejście

Znów jest to kwestia treningu, kilka ogólnych uogólnień:

Programiści front-end

  • Zazwyczaj nie masz dyplomu CS ani dyplomu CS ze szkoły trzeciego poziomu.
  • Pracuj w językach podobnych do podstawowego (patrz PHP is Basic)
  • Posiadaj umiejętności wizualne w konwertowaniu dokumentów z Photoshopa do CSS / HTML / itp.
  • Mają wysoką tolerancję dla programowania iteracyjnego, ze względu na języki wolne od typów

Programiści zaplecza

  • Mają stopień CS lub duże doświadczenie
  • Mają bardziej systematyczne podejście do rozwiązywania problemów
  • Nie przejmuj się spędzaniem dni na znajdowaniu jedynego przeciekającego obiektu
  • Spróbuj zbudować narzędzia do rozwiązywania problemów


2
smh, to jest powód, dla którego mówię ludziom, że jestem programistą kontra programistą.
pllee

10
Co te uogólnienia dotyczące deweloperów z przodu i z tyłu mają wspólnego z tym pytaniem?
Erik Reppen,

Front End Dev! = Back End Devs, chociaż przez większość czasu przejścia między nimi trwają.
Abhinav Gauniyal,

Myślę, że jedyną prawidłową odpowiedzią byłoby „To zależy ...”
Oliver Weiler,

Odpowiedzi:


43

Jeśli zaczniesz od tyłu i pójdziesz naprzód, ryzykujesz niezrozumienie klienta. Ponieważ będziesz tworzyć rzeczy, których nie mogą łatwo zobaczyć i zrozumieć, nie mogą oni bardzo łatwo uczestniczyć w sprawdzaniu, czy spełniasz wymagania. Oznacza to, że możesz zmarnować dużo pracy.

Jeśli zaczniesz od przodu i cofniesz się, ryzykujesz, że klient pomyśli, że jest prawie gotowy, gdy tylko narysujesz prosty formularz na ekranie. Mogą wtedy zapytać, dlaczego to trwa tak długo, skoro przeważnie skończyłeś w ciągu kilku dni. Ryzykujesz także zamalowaniem się w kącie, kiedy zdajesz sobie sprawę, że musisz wykonać skomplikowaną pracę, aby łączyć przód z tyłem, kiedy bardziej odpowiedni front byłby prostszy.

IMO, powinieneś najpierw nad tym pracować. Napisz razem przód i tył dla każdej funkcji w systemie. Daje to klientowi lepszą widoczność postępu i daje mu możliwość powiedzenia „nie, nie o to mi chodziło”, bez powodowania zbyt dużego stresu.

To powiedziawszy, jeśli jest to bardzo duży projekt, w którym musisz wziąć pod uwagę sprzęt serwera lub możliwości dowolnego oprogramowania, na którym się opierasz (np. Jakiej bazy danych używasz), prawdopodobnie powinieneś najpierw dobrze przemyśleć tę część.


Myślę, że to bardziej zwięzłe wyjaśnienie. Ale czy lepiej byłoby ustawić back-end jako pierwszy, ponieważ myślę, że łatwiej jest utworzyć front-end, jeśli masz dobrze skonstruowany back-end.
drexsien,

3
Jeśli uważają, że front to wszystko, możesz wspomnieć o Google ...
l0b0

1
Właśnie dlatego powinieneś zbudować makiety GUI, które pokazujesz klientowi i mówisz „Czy to jest to, co chcesz, aby program robił?”, A kiedy to zostanie ustalone, wyrzuć go i zacznij budować backend.
gablin

1
+1. @andsien: Jeśli masz już swoją opinię, dlaczego pytasz? Z mojego doświadczenia wynika, że ​​Paul ma rację, rozwój oparty na funkcjach jest prawie zawsze lepszą strategią.
Doc Brown

3
@andsien: „Łatwiej jest stworzyć interfejs, jeśli masz dobrze zorganizowany backend”. IMHO to niebezpieczne nieporozumienie. Problem polega na tym: nie wiesz, czy Twój back-end jest dobrze skonstruowany, dopóki nie użyjesz go do tworzenia funkcji dla interfejsu.
śleske,

9

Oprogramowanie ma wiele wymiarów, dlatego nadmiernie uproszczony front-back-back jest złym pytaniem i bardzo, bardzo trudno jest podać rozsądną, przydatną odpowiedź.

Jeden widok to statyczna struktura danych. W tym widoku istnieją co najmniej trzy wymiary: warstwy architektoniczne („od przodu do tyłu”), przypadki użycia i podmioty, a także koszty lub ryzyko wdrożenia.

Jednym z widoków jest dynamiczna struktura przetwarzania. Istnieją również co najmniej trzy wymiary tego widoku.

Trzeci widok to komponenty architektoniczne, które naturalnie dzielą się na warstwy, obsługują przypadki użycia oraz wiążą się z kosztami i ryzykiem.

Mógłbym kontynuować, ale o to chodzi.

Front-end vs. back-end developers (moja opinia)

To w przybliżeniu najmniej przydatny sposób spojrzenia na problem. Faktyczni programiści - i wasze opinie na ich temat - mają tutaj bardzo, bardzo małe znaczenie. Co się liczy

  • Używaj skrzynek i aktorów

  • Logiczny model danych do obsługi tych przypadków użycia

  • Proces wykonywany jako część przypadku użycia

  • Komponenty, których użyjesz do zbudowania logicznych i przetwarzających elementów przypadku użycia.

Dlatego większość ludzi mówi, że musisz rozłożyć system według historii użytkownika lub przypadku użycia.

Nie dokonuj ogólnych uogólnień na temat ludzi, którzy będą się rozwijać.


7

Ani. Co musi zrobić Twoja aplikacja? Upewnij się, że gorący zawór dostarcza ciepłą wodę, zimny zawór dostarcza zimną wodę, że woda przepływa przede wszystkim, że możesz przedłużyć rury tam, gdzie jest to potrzebne, a następnie martwić się wprowadzeniem rzeczywistej hydrauliki do wszystkich pomieszczeń domu lub tego, co będzie w domu właściwie wyglądają dokładnie tak.

Przedni koniec to tylko maska ​​z kilkoma przełącznikami i dźwigniami. Zaplecze to tylko rzecz, która odbiera żądania pobierania i przetwarzania danych. Przejdź do punktu, w którym możesz szybko wdrożyć oba w dowolnej pożądanej kombinacji.

Ale cokolwiek zrobisz, nie pozwól, aby projekt jednego dyktował projekt drugiego. W ten sposób leży szaleństwo.

Przygotuj narzędzia, które pozwolą Twoim deweloperom zbudować wszystko, czego potrzebują dla Twojego klienta, niezależnie od tego, ile razy zmieniają zdanie. Następnie zbuduj go zgodnie ze specyfikacjami i uruchom ponownie, aż małe guziki będą w końcu szczęśliwe.

Porównywanie deweloperów front-end do deweloperów back-end w 2008 roku jest dawno temu w latach internetowych. Dla zabawy chciałbym poprawić / dodać kilka rzeczy do tego starego kasztana, ponieważ połączyliśmy go w pytaniu, ale także (mam nadzieję) umieść kilka wskazówek w:

Programiści front-end

Zazwyczaj nie masz dyplomu CS ani dyplomu CS ze szkoły trzeciego poziomu.

Podniesienie rąk. Ile osób z dyplomem CS zostało nauczonych najlepszych praktyk z zakresu obsługi? Lub jak nie robić bałaganu za pomocą JavaScript? Lub jak radzić sobie z problemami CSS z IE6-IE9? Przemysł podręczników, który prowadzi akademię, jest zbyt gruby, leniwy i wzdęty, aby poradzić sobie z ciągle zmieniającymi się technologiami, dlatego bardzo mało uwagi poświęcił kolegiom. To było doskonałe dla późno kwitnących jak ja.

Pracuj w językach podobnych do podstawowego (patrz PHP is Basic)

Ponieważ PHP to technologia po stronie klienta? A może JavaScript, który został zainspirowany przede wszystkim przez Scheme, ma więcej wspólnego z Basicem niż Visual Basicem, który nie jest już dłużej dostępny w interfejsie i nigdy tak naprawdę nie był, ale jest nadal dostępny dla aplikacji webowych .NET? Blog porównuje samouków programistów internetowych typu open source z programistami klasy CS używającymi popularnej technologii w tym momencie. Po obu stronach tej konkretnej walki natrafiłem na niezrównane i kompetentne udziały w równych częściach, ale wciąż jest tam OT.

Posiadaj umiejętności wizualne w konwertowaniu dokumentów z Photoshopa do CSS / HTML / itp.

Więcej uwagi na szczegóły niż „umiejętność wizualna”, która jest nieco szeroka. Nie każdy z nas ma jakiekolwiek umiejętności w zakresie estetyki. Ale tak, większość z nas musi się tego nauczyć na poziomie Jr. i jest to naprawdę bardzo ważne, aby napisać dobry interfejs użytkownika, który nie używa młotów JS, gdy skalpele CSS to zrobią.

Mają wysoką tolerancję dla programowania iteracyjnego, ze względu na języki wolne od typów

Właśnie dlatego chcesz, aby utwory, o których wcześniej wspomniałem, były na pierwszym miejscu. Przekazujemy wciśnięte przyciski, a Ty produkujesz / odzyskujesz towary. Pakujemy je i dostarczamy. Nie ma powodu, aby te rzeczy były ściśle związane ze sobą. Również naprawdę ścisłe pisanie na klawiaturze nie powinno zakłócać iteracyjnego procesu, jeśli nie jest do bani w OOP, co większość ludzi, którzy lubią wyśmiewać się z języka, który technicznie nie ma zajęć, zazwyczaj tak robi. Ale nawet jeśli śmierdzą, interfejs potrzebuje tylko przewidywalnego punktu dostępu i możesz robić, co chcesz, na zapleczu, o ile nie robisz czegoś głupiego, jak dynamiczne pisanie JavaScript, który nie jest JSON lub ściśle powiązać udane zachowanie zaplecza ze strukturą HTML, która jest „po prostu”. * kaszel * java devs * / kaszel *


Żałuję tylko, że nie mogę dać +1 Twojemu pytaniu więcej niż raz. Szkoda, że ​​musiałem przewinąć w dół 2 odpowiedzi na to pytanie, aby w końcu znaleźć tę, w której stwierdzono, że pytanie o kolejność, w jakiej przód i tył powinny być rozwijane, jest niewłaściwym pytaniem. Zgadzam się również z twoją opinią na temat dyplomu CS. I ostatnia uwaga „późnych kwitnących”.
Shivan Dragon,

5

Nie ma jednej właściwej odpowiedzi na to pytanie. Każde podejście może być dobre (i złe) w niektórych sytuacjach.

Zalecam rozważenie podejścia TDD, w którym prowadzi się przez testy (akceptacyjne i jednostkowe).

Zacznij od złożenia szkieletu systemu: podstawowej infrastruktury z absolutnie minimalną funkcjonalnością. To tylko po to, aby pokazać, że twoja koncepcja działa, a różne komponenty mogą ze sobą współpracować. Obejmuje to również interfejs użytkownika z odkrytymi kośćmi (jeśli dotyczy), wystarczający do zrobienia i / lub pokazania czegoś minimalnego.

Następnie dopracowujesz szczegóły, funkcja po funkcji : napisz test akceptacji dla konkretnej cechy / scenariusza, spraw, by się nie powiódł, a następnie napisz kod, aby go spełnić. To sprawia, że pracujesz do wewnątrz z zewnątrz : system odbiera komunikat wejściowy, więc musisz obsłużyć / przekonwertować ten komunikat, zrobić coś z nim, a następnie propagować wyniki z powrotem do interfejsu użytkownika. Po drodze odkryjesz koncepcje domen i reprezentujesz je za pomocą nowych klas, od interfejsu użytkownika do warstwy domeny iz powrotem.

W przypadku tego podejścia zalecaną lekturą jest Rosnące oprogramowanie obiektowe, kierowane testami .


1

API pierwszy

Inżynierowie z obu zespołów powinni współpracować nad interfejsem API między front-endem a back-endem. Następnie oba zespoły mogą rozpocząć pracę w oparciu o zaprojektowany interfejs API. Ma to tę zaletę, że inny zespół front-end może również rozpocząć pracę (być może mobilny, po kliencie WWW), poza oczywistą zaletą, że zespoły mogą rozpocząć pracę równoległą.

Połącz z iteracyjnym podejściem i powinno to wyglądać tak:

  1. Zaprojektuj prosty interfejs API
  2. Oba zespoły opracowują i testują w oparciu o interfejs API
  3. Test integracyjny
  4. Pokaż klientowi i otrzymaj informację zwrotną.
  5. Ulepsz API i powtórz.

0

Zacznij od interfejsu, ale po pierwsze, dlaczego nie mogą znaleźć aplikacji, która już istnieje? Dałoby to więcej wglądu w ten projekt. Czy mają jakieś unikalne wymagania, czy uważają, że możesz budować taniej?

Dowiedz się, jakie są ich oczekiwania w zakresie bezpieczeństwa i jakie jest prawo. Nie jestem pewien, jaki to typ szkoły, ale informacje o uczniach zwykle wymagają pewnej poufności.

Jeśli potencjalni studenci wprowadzają dane na stronie internetowej, projekt graficzny będzie bardziej problemem.

Na podstawie ich wniosków narysuj makiety interfejsu. Jeśli uważasz, że gui nie jest proste, być może będziesz musiał stworzyć coś funkcjonalnego, aby mogli zobaczyć to w akcji. Mogą postrzegać rejestrację jako pewnego rodzaju „kreatora”, który rozgałęzia się w różnych kierunkach w oparciu o wprowadzanie danych.

Następnie możesz zacząć uzyskiwać informacje utrwalone w bazie danych.


1
problem z uruchomieniem interfejsu (w oparciu o doświadczenie) polega na tym, że gdy zapomnisz o niektórych funkcjach, może to popsuć twój zaplecze i może skończyć się próbą naprawy
drexsien

1
@andsien - mówisz o projektowaniu lub budowaniu? Nie zacząłbym budować interfejsu bez zaprojektowania backendu.
JeffO,

ops moja wina myślę o budowaniu ... dzięki za tego jeffa.
drexsien

0

Tak, zdałem sobie sprawę, że OP poprosił jakiś czas temu. Zacznij od zaplecza, ale ZABLOKUJ interfejs, aby użytkownik mógł zobaczyć, co sobie wyobrażasz. Front, mimo wszystko, co warte jest, to tylko dzwony i gwizdy. Na zapleczu znajdują się pieniądze, a gdy masz już to proste, FE jest po prostu sosem nad mięsem.


Niestety zazwyczaj tego chcą klienci, ale myślę, że takie zachowanie powinno być zniechęcane. Nie rozwieszaj ich na obrazie i trzymaj się swojego wyglądu prototypu, dopóki nie będą w stanie zweryfikować, że uzyskują pożądane podstawowe zachowanie. Klienci często nie są w stanie oddzielić cukierków od przydatnej funkcji i sprawią, że zmarnujesz dużo czasu na mniej ważne rzeczy, aby obwinić Cię, gdy aplikacja zawiedzie w ostatecznym zamiarze w dłuższej perspektywie.
Erik Reppen

@ErikReppen Miałem takie doświadczenie wiele razy - chciałem pokazać klientowi „użytkownik wprowadzi dane w polu tekstowym”, a klient zobaczy „pole formularza będzie miało dokładnie 400 pikseli szerokości, a strona będzie jasnoniebieska tło z tekstem Arial 11pt ... „Ale nadal uważam, że to lepsze niż nigdy nie demo interfejsu. W przeciwnym razie możliwe jest zbudowanie całego systemu, który jest sprzeczny z niektórymi nieokreślonymi założeniami w ich głównym przypadku użycia.
octu

Możesz demonstrować interfejs, ale zachowaj prostotę i prostotę. Odciągnij ich od głupoty dokładnie w Photoshopie, chyba że w ten sposób żądają ich sprzedaży. I na tym polega problem. Tego się spodziewali, ale najczęściej są aż tak cholernie głupi, aby nadać priorytet pikselom z „w rzeczywistości sprawia, że ​​nasi klienci robią to, co chcielibyśmy”.
Erik Reppen

errr, czy nie dlatego mamy CSS? (chociaż ja nie czuję bólu). I zawsze świadomie i mają brzydki, ale funkcjonalny, Fe i sprawiają, że zwykły mówimy przypadków użycia, workflow ... i można go upiększać później. (ale prawdziwą odpowiedzią są wymagania-> baza
danych-

0

Rozszerzając mój komentarz:

Najpierw zbierz wymagania, a następnie zmień je w Przypadki użycia i projekt.

Najpierw pojawia się szczegółowa definicja bazy danych. Nie dbam o to, czy klient nie do końca się zdziwi, zmuszam ich, aby usiedli i popatrzyli na to - i podpisali się na nim (być może wtedy zmuszali mnie, by zdać sobie sprawę, że kiedyś bardziej zaawansowani technicznie faceci powinni to zrobić ), przed kontynuowaniem.

Jak zacząć od FE bez BE? FE za co ??? Zdefiniuj swoją bazę danych !! To właśnie manipuluje FE.

Ok, nie będzie problemów i późniejszych poprawek, a ja zrobić zgadzają się, że jest dobry, aby uzyskać prosty, próbki GUI przed klientem ASAP, ponieważ szczególności wierzchołek góry lodowej tego, co jest najbardziej najbardziej zrozumieć.

Jednak 1) podkreślam, że jest to tylko makabryczna makieta do dyskusji morświnów, oraz 2) celowo czynię ją brzydką, ale funkcjonalną , aby ci, którzy nie rozumieją, mogli ją poderwać i kazać mi zrobić pole wprowadzania dokładnie 400px szerokie i jasnoniebieskie tło.

Doszedłem do wniosku, że większość odpowiedzi tutaj (i śledziłem je) ma tendencję do zbytniego skupiania się na kliencie, ale z czysto białego punktu widzenia twierdzę, że nie można zaprojektować FE do manipulowania BE bez wcześniejszego projektowanie tego BE.


„nie można zaprojektować FE do manipulowania BE bez uprzedniego zaprojektowania tego BE”. O tak, możesz - to się nazywa „prototyp”. Może to być cenny pierwszy krok przy uruchamianiu nowego systemu.
śleske,

co to jest prototypowanie? Żadnej wojny z płomieniami, po prostu wpadł mi do głowy. Rozumiem, czym jest prototyp, ale może dlatego, że pochodzę z innej dziedziny, po prostu zawsze widzę to jako: zdobądź wymagania, zmień je w przypadki użycia i projekt. Jeśli nie masz gwoździ do d / b, zrobisz dużo niepotrzebnych przeróbek, więc najpierw posortuj, a następnie wymyśl, jak nimi manipulować (zgodnie z wymaganiami). YMMV ... ciąg dalszy ...
Mawg

Prawdopodobnie nie jest czarno-biały, inaczej pytanie nie zostałoby zadane, ale BE najpierw, zawsze, IMO. W rzeczywistości robię to teraz w ten sposób dla klienów, którzy mają tylko niejasne, niewyraźne uczucie zamiast wymagań (nigdy nie powinienem ich dotykać, ale to cała inna historia :-)
Mawg 18'15

1
Z mojego doświadczenia wynika, że ​​wymagania użytkowników powinny być najważniejsze, a architektura powinna podążać. Ale oczywiście zależy to od szczegółów technicznych, niektóre rzeczy naprawdę trudno zmienić później. Przynajmniej ważne jest, aby zdawać sobie sprawę z kompromisów.
śleske,

Podejrzewam, że możemy mówić to samo na różne sposoby (+1)
Mawg
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.